On Sat, Mar 7, 2015 at 1:05 PM, Borislav Petkov wrote:
> On Fri, Mar 06, 2015 at 11:53:22AM -0800, Yinghai Lu wrote:
> ---
> Commit
>
> f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
>
> started passing KASLR status to kernel proper, but it uses a physical
> address as the
On Fri, Mar 06, 2015 at 11:53:22AM -0800, Yinghai Lu wrote:
> That will get wrong value back for kaslr_enabled in kernel stage.
> 1. When kaslr is not enabled at boot/choose_kernel_location, if kaslr_enabled
> get set wrongly in setup.c, late in module.c::get_module_load_offset
> will return not wa
On Fri, Mar 06, 2015 at 11:50:54AM -0800, Yinghai Lu wrote:
> On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov wrote:
>
> >
> > "However, the setup_data linked list and thus the element which contains
> > kaslr_enabled is chained together using physical addresses. At the
> > time when we access it
On Fri, Mar 06, 2015 at 09:49:25AM -0800, Yinghai Lu wrote:
> That is "copy and paste" instead of attachment for easy review.
> but gmail web client convert tab to spaces.
Next time you send a patch *only* for review *and* *not* for
application, do state that at the top like everyone else. Better
On Fri, Mar 6, 2015 at 11:50 AM, Yinghai Lu wrote:
> On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov wrote:
>
>>
>> "However, the setup_data linked list and thus the element which contains
>> kaslr_enabled is chained together using physical addresses. At the
>> time when we access it in the kerne
On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov wrote:
>
> "However, the setup_data linked list and thus the element which contains
> kaslr_enabled is chained together using physical addresses. At the
> time when we access it in the kernel proper, we're already running
> with paging enabled and t
On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov wrote:
> Please use checkpatch before submitting patches:
>
> WARNING: please, no spaces at the start of a line
> #71: FILE: arch/x86/kernel/setup.c:433:
> +unsigned char *data;$
>
> WARNING: please, no spaces at the start of a line
> #72: FILE:
On Wed, Mar 04, 2015 at 01:32:53PM -0800, Yinghai Lu wrote:
> On Wed, Mar 4, 2015 at 12:00 PM, Ingo Molnar wrote:
> >
> > It is totally unacceptable that you don't do proper analysis of the
> > patches you submit, and that you don't bother writing proper, readable
> > changelogs.
>
> Sorry, pleas
On Wed, Mar 4, 2015 at 6:58 PM, joeyli wrote:
>
> After 84c91b7ae merged to v3.17 kernel, hibernate code checks the e280 regions
> should not be changed when doing hibernate resume. Without your patch 8,
> the hibernate resume checking will randomly fail on the machines that reserved
> setup_data
Hi Yinghai,
On Wed, Mar 04, 2015 at 10:12:58AM -0800, Yinghai Lu wrote:
> On Wed, Mar 4, 2015 at 7:54 AM, Jiri Kosina wrote:
>
> >
> > Also this 15-patch series needs to be separated into two patchsets. The
> > whole series is not appropriate for -rc3, but this particular one at least
> > is a r
On Wed, Mar 4, 2015 at 12:00 PM, Ingo Molnar wrote:
>
> It is totally unacceptable that you don't do proper analysis of the
> patches you submit, and that you don't bother writing proper, readable
> changelogs.
Sorry, please check it again:
Subject: [PATCH v4] x86, kaslr: Get kaslr_enabled back
* Yinghai Lu wrote:
> On Wed, Mar 4, 2015 at 2:16 AM, Borislav Petkov wrote:
> > On Wed, Mar 04, 2015 at 12:00:37AM -0800, Yinghai Lu wrote:
> >> commit f47233c2d34f ("x86/mm/ASLR: Propagate base load address
> >> calculation")
> >> is using address as value for kaslr_enabled.
> >>
> >> That w
* Yinghai Lu wrote:
> On Wed, Mar 4, 2015 at 7:54 AM, Jiri Kosina wrote:
>
> >
> > Also this 15-patch series needs to be separated into two patchsets. The
> > whole series is not appropriate for -rc3, but this particular one at least
> > is a regression fix that has to go in.
>
> The first 4
On Wed, Mar 4, 2015 at 10:06 AM, Yinghai Lu wrote:
> On Wed, Mar 4, 2015 at 2:16 AM, Borislav Petkov wrote:
>> On Wed, Mar 04, 2015 at 12:00:37AM -0800, Yinghai Lu wrote:
>>> commit f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
>>> is using address as value for kaslr_enabl
On Wed, Mar 4, 2015 at 7:54 AM, Jiri Kosina wrote:
>
> Also this 15-patch series needs to be separated into two patchsets. The
> whole series is not appropriate for -rc3, but this particular one at least
> is a regression fix that has to go in.
The first 4 should go v4.0.
could leave others to
On Wed, Mar 4, 2015 at 2:16 AM, Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 12:00:37AM -0800, Yinghai Lu wrote:
>> commit f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
>> is using address as value for kaslr_enabled.
>>
>> That will random kaslr_enabled get that set or
On Wed, 4 Mar 2015, Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 12:00:37AM -0800, Yinghai Lu wrote:
> > commit f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
> > is using address as value for kaslr_enabled.
> >
> > That will random kaslr_enabled get that set or cleared
On Wed, Mar 04, 2015 at 12:00:37AM -0800, Yinghai Lu wrote:
> commit f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
> is using address as value for kaslr_enabled.
>
> That will random kaslr_enabled get that set or cleared.
> Will have problem for system really have kaslr ena
commit f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
is using address as value for kaslr_enabled.
That will random kaslr_enabled get that set or cleared.
Will have problem for system really have kaslr enabled.
-v2: update changelog.
Fixes: f47233c2d34f ("x86/mm/ASLR: Prop
19 matches
Mail list logo
