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
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
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 whole of
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
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 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:
This
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
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.
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 #PF
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 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. It has to
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, but I worry that this
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
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
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
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 direct connection
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:
Sorry...
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 x86_64, we should
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. I'm also
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
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
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
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 between the physical
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.
For x86-64,
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
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 not
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
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
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 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 and a
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 that
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 message we get when
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
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 kaslr
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
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
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 the
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
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
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
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
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
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
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 anything
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
On Fri, Sep 12, 2014 at 8:33 AM, Vivek Goyal vgo...@redhat.com 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
54 matches
Mail list logo
