Hi hpa,
Ping.
Do you have further plan or idea on this issue? Or could you
please merge this patch to fix reported bug for now?
Thanks
Baoquan
On 09/30/14 at 03:08pm, Baoquan He wrote:
> Function handle_relocations() is used to do the relocations handling
> for i686 and kaslr of x86_64. For 32
On 10/15/14 at 11:37am, Baoquan He wrote:
> On 10/14/14 at 08:49am, Vivek Goyal wrote:
> > On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
> > > Agreed. On x86_64, we should be able to randomize virtual address space
> > > and physical address space independently. And in that case wh
On 10/16/14 at 07:55am, Baoquan He wrote:
> On 10/15/14 at 01:32pm, H. Peter Anvin wrote:
> > I don't see why we can't randomize anywhere in physical space. We already
> > handle the kernel above 4 GB and it wouldn't be hard to do the equivalent
> > for the decompress/relocation code, using a #P
On 10/15/14 at 01:32pm, H. Peter Anvin wrote:
> I don't see why we can't randomize anywhere in physical space. We already
> handle the kernel above 4 GB and it wouldn't be hard to do the equivalent for
> the decompress/relocation code, using a #PF handler. Not all CPUs support 1
> GB pages.
>
I don't see why we can't randomize anywhere in physical space. We already
handle the kernel above 4 GB and it wouldn't be hard to do the equivalent for
the decompress/relocation code, using a #PF handler. Not all CPUs support 1 GB
pages.
On October 14, 2014 8:37:01 PM PDT, Baoquan He wrote:
On Wed, Oct 15, 2014 at 11:37:01AM +0800, Baoquan He wrote:
> On 10/14/14 at 08:49am, Vivek Goyal wrote:
> > On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
> > > On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
> > > > On 10/13/2014 08:19 AM, Vivek Goyal wrote:
> > > >
On 10/14/14 at 08:49am, Vivek Goyal wrote:
> On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
> > On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
> > > On 10/13/2014 08:19 AM, Vivek Goyal wrote:
> > > >>>
> > > >>> This really shouldn't have happened this way on x86-64.
On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
> On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
> > On 10/13/2014 08:19 AM, Vivek Goyal wrote:
> > >>>
> > >>> This really shouldn't have happened this way on x86-64. It has to
> > >>> happen
> > >>> this way on i386,
On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
> On 10/13/2014 08:19 AM, Vivek Goyal wrote:
> >>>
> >>> This really shouldn't have happened this way on x86-64. It has to happen
> >>> this way on i386, but I worry that this may be a serious misdesign in
> >>> kaslr
> >>> on x86-64
On 10/13/2014 08:19 AM, Vivek Goyal wrote:
>>>
>>> This really shouldn't have happened this way on x86-64. It has to happen
>>> this way on i386, but I worry that this may be a serious misdesign in kaslr
>>> on x86-64. I'm also wondering if there is any other fallout of this?
>>
>> I agree. On x8
On Mon, Oct 13, 2014 at 08:52:57AM -0400, Vivek Goyal wrote:
> On Sat, Oct 11, 2014 at 03:34:29AM -0700, H. Peter Anvin wrote:
> > On 10/10/2014 08:14 PM, Baoquan He wrote:
> > >On 10/08/14 at 03:27pm, Vivek Goyal wrote:
> > >>On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
> > >
>
On Sat, Oct 11, 2014 at 03:34:29AM -0700, H. Peter Anvin wrote:
> On 10/10/2014 08:14 PM, Baoquan He wrote:
> >On 10/08/14 at 03:27pm, Vivek Goyal wrote:
> >>On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
> >
> >>>Sorry... this makes no sense.
> >>>
> >>>For x86-64, there is no dir
On 10/11/14 at 08:38pm, Baoquan He wrote:
> On 10/11/14 at 03:34am, H. Peter Anvin wrote:
> > On 10/10/2014 08:14 PM, Baoquan He wrote:
> > >On 10/08/14 at 03:27pm, Vivek Goyal wrote:
> > >>On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
> > >
> > >>>Sorry... this makes no sense.
>
On 10/11/14 at 03:34am, H. Peter Anvin wrote:
> On 10/10/2014 08:14 PM, Baoquan He wrote:
> >On 10/08/14 at 03:27pm, Vivek Goyal wrote:
> >>On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
> >
> >>>Sorry... this makes no sense.
> >>>
> >>>For x86-64, there is no direct connection bet
On 10/10/2014 08:14 PM, Baoquan He wrote:
On 10/08/14 at 03:27pm, Vivek Goyal wrote:
On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
Sorry... this makes no sense.
For x86-64, there is no direct connection between the physical and
virtual address spaces that the kernel runs in
On 10/08/14 at 03:27pm, Vivek Goyal wrote:
> On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
> > Sorry... this makes no sense.
> >
> > For x86-64, there is no direct connection between the physical and
> > virtual address spaces that the kernel runs in...
>
> I am sorry I did no
On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
> On 10/01/2014 06:52 AM, Vivek Goyal wrote:
> >
> > Hi Peter,
> >
> > I think there is some confusion. I will try to clarify.
> >
> > If we have 32bit signed overflow, we will not have a functional kernel.
> > And that's the messag
On 10/01/2014 06:52 AM, Vivek Goyal wrote:
>
> Hi Peter,
>
> I think there is some confusion. I will try to clarify.
>
> If we have 32bit signed overflow, we will not have a functional kernel.
> And that's the message we get when we try to kexec with
> CONFIG_RANDOMIZE_BASE=y.
>
And how does t
On 09/30/14 at 02:21pm, H. Peter Anvin wrote:
> On 09/30/2014 12:08 AM, Baoquan He wrote:
> > Function handle_relocations() is used to do the relocations handling
> > for i686 and kaslr of x86_64. For 32 bit the relocation handling is
> > mandotary to perform. For x86_64 only when kaslr is enabled
On Tue, Sep 30, 2014 at 02:21:05PM -0700, H. Peter Anvin wrote:
> On 09/30/2014 12:08 AM, Baoquan He wrote:
> > Function handle_relocations() is used to do the relocations handling
> > for i686 and kaslr of x86_64. For 32 bit the relocation handling is
> > mandotary to perform. For x86_64 only when
On 09/30/2014 12:08 AM, Baoquan He wrote:
> Function handle_relocations() is used to do the relocations handling
> for i686 and kaslr of x86_64. For 32 bit the relocation handling is
> mandotary to perform. For x86_64 only when kaslr is enabled and a
> random kernel location is chosen successfully
Function handle_relocations() is used to do the relocations handling
for i686 and kaslr of x86_64. For 32 bit the relocation handling is
mandotary to perform. For x86_64 only when kaslr is enabled and a
random kernel location is chosen successfully the relocation handling
shound be done. However pr
On Fri, Sep 12, 2014 at 8:33 AM, Vivek Goyal wrote:
> On Fri, Sep 12, 2014 at 11:22:44PM +0800, Baoquan He wrote:
>> Function handle_relocations() is used to do the relocations handling
>> for i686 and kaslr of x86_64. For 32 bit the relocation handling is
>> mandotary to perform. For x86_64 only
Hi,
Vivek Goyal wrote:
> You had reported kexec issues with CONFIG_RANDOMIZE_BASE=y. Does this
> patch resolve the issue for you?
Yup! Tested against kernel-3.16.2.
-Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ker
On Fri, Sep 12, 2014 at 05:56:12PM +0200, Thomas D. wrote:
> Hi,
>
> Vivek Goyal wrote:
> > You had reported kexec issues with CONFIG_RANDOMIZE_BASE=y. Does this
> > patch resolve the issue for you?
>
> Yup! Tested against kernel-3.16.2.
Thanks. Given this patch is small and should not break any
On Fri, Sep 12, 2014 at 11:22:44PM +0800, Baoquan He wrote:
> Function handle_relocations() is used to do the relocations handling
> for i686 and kaslr of x86_64. For 32 bit the relocation handling is
> mandotary to perform. For x86_64 only when kaslr is enabled and a
> random kernel location is ch
Function handle_relocations() is used to do the relocations handling
for i686 and kaslr of x86_64. For 32 bit the relocation handling is
mandotary to perform. For x86_64 only when kaslr is enabled and a
random kernel location is chosen successfully the relocation handling
shound be done. However pr
27 matches
Mail list logo
