On Sat, Mar 7, 2015 at 1:05 PM, Borislav Petkov b...@suse.de 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
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
On Fri, Mar 06, 2015 at 11:50:54AM -0800, Yinghai Lu wrote:
On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov b...@suse.de 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
On Wed, Mar 04, 2015 at 01:32:53PM -0800, Yinghai Lu wrote:
On Wed, Mar 4, 2015 at 12:00 PM, Ingo Molnar mi...@kernel.org 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,
On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov b...@suse.de 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:
On Fri, Mar 6, 2015 at 11:50 AM, Yinghai Lu ying...@kernel.org wrote:
On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov b...@suse.de 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
On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov b...@suse.de 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
On Wed, Mar 4, 2015 at 2:16 AM, Borislav Petkov b...@alien8.de 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
On Wed, Mar 4, 2015 at 7:54 AM, Jiri Kosina jkos...@suse.cz 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
On Wed, Mar 4, 2015 at 10:06 AM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Mar 4, 2015 at 2:16 AM, Borislav Petkov b...@alien8.de 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
On Wed, Mar 4, 2015 at 12:00 PM, Ingo Molnar mi...@kernel.org 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
* Yinghai Lu ying...@kernel.org wrote:
On Wed, Mar 4, 2015 at 2:16 AM, Borislav Petkov b...@alien8.de 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
* Yinghai Lu ying...@kernel.org wrote:
On Wed, Mar 4, 2015 at 7:54 AM, Jiri Kosina jkos...@suse.cz 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
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 jkos...@suse.cz 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
On Wed, Mar 4, 2015 at 6:58 PM, joeyli j...@suse.com 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
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:
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 enabled.
17 matches
Mail list logo
