[PATCH v3 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

Initialize KASLR memory randomization after max_pfn is initialized. Also ensure the size is rounded up. Could have create problems on machines with more than 1Tb of memory on certain random addresses. Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions") Signed-off-

[PATCH v3 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

Initialize KASLR memory randomization after max_pfn is initialized. Also ensure the size is rounded up. Could have create problems on machines with more than 1Tb of memory on certain random addresses. Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions") Signed-off-

[PATCH v3 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

while doing extensive testing of KASLR memory randomization on different type of hardware. Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions") Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20160805 --- arch/x86/mm/init.c | 14 --

[PATCH v3 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

while doing extensive testing of KASLR memory randomization on different type of hardware. Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions") Signed-off-by: Thomas Garnier --- Based on next-20160805 --- arch/x86/mm/init.c | 14 -- 1 file changed, 12 insert

[PATCH v2 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

while doing extensive testing of KASLR memory randomization on different type of hardware. Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions") Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20160805 --- arch/x86/mm/init.c | 14 --

[PATCH v2 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

while doing extensive testing of KASLR memory randomization on different type of hardware. Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions") Signed-off-by: Thomas Garnier --- Based on next-20160805 --- arch/x86/mm/init.c | 14 -- 1 file changed, 12 insert

[PATCH v2 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

Initialize KASLR memory randomization after max_pfn is initialized. Also ensure the size is rounded up. Could have create problems on machines with more than 1Tb of memory on certain random addresses. Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions") Signed-off-

[PATCH v2 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

Initialize KASLR memory randomization after max_pfn is initialized. Also ensure the size is rounded up. Could have create problems on machines with more than 1Tb of memory on certain random addresses. Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions") Signed-off-

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Tue, Aug 9, 2016 at 9:03 AM, Joerg Roedel <jroe...@suse.de> wrote: > On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote: >> On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier <thgar...@google.com> wrote: >> > Initialize KASLR memory randomization afte

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Tue, Aug 9, 2016 at 9:03 AM, Joerg Roedel wrote: > On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote: >> On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier wrote: >> > Initialize KASLR memory randomization after max_pfn is initialized. Also >> > ensure th

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Tue, Aug 9, 2016 at 9:18 AM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina <ji...@kernel.org> wrote: >> On Tue, 9 Aug 2016, Thomas Garnier wrote: >> >>> >> Okay, I did one-by-one reverts, and the

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Tue, Aug 9, 2016 at 9:18 AM, Rafael J. Wysocki wrote: > On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina wrote: >> On Tue, 9 Aug 2016, Thomas Garnier wrote: >> >>> >> Okay, I did one-by-one reverts, and the one above, i.e. >>> >> >>> &g

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier <thgar...@google.com> wrote: > Initialize KASLR memory randomization after max_pfn is initialized. Also > ensure the size is rounded up. Could have create problems on machines > with more than 1Tb of memory on certain random addresses.

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier wrote: > Initialize KASLR memory randomization after max_pfn is initialized. Also > ensure the size is rounded up. Could have create problems on machines > with more than 1Tb of memory on certain random addresses. > > Signed-off-by:

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On Mon, Aug 8, 2016 at 10:16 PM, Mika Penttilä <mika.pentt...@nextfour.com> wrote: > On 08/08/2016 09:40 PM, Thomas Garnier wrote: >> Default implementation expects 6 pages maximum are needed for low page >> allocations. If KASLR memory randomization is enabled, the worse c

Re: [PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

On Mon, Aug 8, 2016 at 10:16 PM, Mika Penttilä wrote: > On 08/08/2016 09:40 PM, Thomas Garnier wrote: >> Default implementation expects 6 pages maximum are needed for low page >> allocations. If KASLR memory randomization is enabled, the worse case >> of e820 layout w

[PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

while doing extensive testing of KASLR memory randomization on different type of hardware. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20160805 --- arch/x86/mm/init.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c

[PATCH v1 2/2] x86/KASLR: Increase BRK pages for KASLR memory randomization

while doing extensive testing of KASLR memory randomization on different type of hardware. Signed-off-by: Thomas Garnier --- Based on next-20160805 --- arch/x86/mm/init.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index 6209289..3a27e6a 100644

[PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

Initialize KASLR memory randomization after max_pfn is initialized. Also ensure the size is rounded up. Could have create problems on machines with more than 1Tb of memory on certain random addresses. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20160805 --- ar

[PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

Initialize KASLR memory randomization after max_pfn is initialized. Also ensure the size is rounded up. Could have create problems on machines with more than 1Tb of memory on certain random addresses. Signed-off-by: Thomas Garnier --- Based on next-20160805 --- arch/x86/kernel/setup.c | 4

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

t;> kernel identity mapping and the image restoration will fail as a >>> result (leading to a kernel panic most of the time). >>> >>> To fix this problem, rework kernel_ident_mapping_init() to support >>> unaligned offsets between KVA and PA up to the PMD leve

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

t; result (leading to a kernel panic most of the time). >>> >>> To fix this problem, rework kernel_ident_mapping_init() to support >>> unaligned offsets between KVA and PA up to the PMD level and make >>> set_up_temporary_mappings() use it as approprtiate.

Re: [PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code

bles and store it in >> > temp_level4_pgt, so that the value of that variable is ready to be >> > written into CR3. Then, the assembly code doesn't have to worry >> > about converting that value into a physical address and things work >> > regardless of whether or not CONFI

Re: [PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code

f that variable is ready to be >> > written into CR3. Then, the assembly code doesn't have to worry >> > about converting that value into a physical address and things work >> > regardless of whether or not CONFIG_RANDOMIZE_MEMORY is set. >> > >> >

Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping

On Tue, Aug 2, 2016 at 12:55 PM, Yinghai Lu <ying...@kernel.org> wrote: > On Tue, Aug 2, 2016 at 10:48 AM, Thomas Garnier <thgar...@google.com> wrote: >> On Tue, Aug 2, 2016 at 10:36 AM, Yinghai Lu <ying...@kernel.org> wrote: >>> >>> Looks like

Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping

On Tue, Aug 2, 2016 at 12:55 PM, Yinghai Lu wrote: > On Tue, Aug 2, 2016 at 10:48 AM, Thomas Garnier wrote: >> On Tue, Aug 2, 2016 at 10:36 AM, Yinghai Lu wrote: >>> >>> Looks like we need to change the loop from phys address to virtual >>> addres

Re: [PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore

On Tue, Aug 2, 2016 at 1:47 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Tue, Aug 2, 2016 at 4:34 PM, Thomas Garnier <thgar...@google.com> wrote: >> On Mon, Aug 1, 2016 at 5:38 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >>> On Monday, August

Re: [PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore

On Tue, Aug 2, 2016 at 1:47 PM, Rafael J. Wysocki wrote: > On Tue, Aug 2, 2016 at 4:34 PM, Thomas Garnier wrote: >> On Mon, Aug 1, 2016 at 5:38 PM, Rafael J. Wysocki wrote: >>> On Monday, August 01, 2016 10:08:00 AM Thomas Garnier wrote: >>>> When KASL

Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping

On Tue, Aug 2, 2016 at 10:36 AM, Yinghai Lu <ying...@kernel.org> wrote: > On Mon, Aug 1, 2016 at 10:07 AM, Thomas Garnier <thgar...@google.com> wrote: >> Correctly setup the temporary mapping for hibernation. Previous >> implementation assumed the address w

Re: [PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping

On Tue, Aug 2, 2016 at 10:36 AM, Yinghai Lu wrote: > On Mon, Aug 1, 2016 at 10:07 AM, Thomas Garnier wrote: >> Correctly setup the temporary mapping for hibernation. Previous >> implementation assumed the address was aligned on the PGD level. With >> KASLR memory

Re: [PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore

On Mon, Aug 1, 2016 at 5:38 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Monday, August 01, 2016 10:08:00 AM Thomas Garnier wrote: >> When KASLR memory randomization is used, __PAGE_OFFSET is a global >> variable changed during boot. The assembly code w

Re: [PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore

On Mon, Aug 1, 2016 at 5:38 PM, Rafael J. Wysocki wrote: > On Monday, August 01, 2016 10:08:00 AM Thomas Garnier wrote: >> When KASLR memory randomization is used, __PAGE_OFFSET is a global >> variable changed during boot. The assembly code was using the variable >>

Re: [PATCH] x86/mm: Enable KASLR for vmemmap memory region (x86_64)

On Tue, Aug 2, 2016 at 1:14 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Thomas Garnier <thgar...@google.com> wrote: > >> On Wed, Jul 27, 2016 at 8:59 AM, Thomas Garnier <thgar...@google.com> wrote: >> > Add vmemmap in the list of randomized memory r

Re: [PATCH] x86/mm: Enable KASLR for vmemmap memory region (x86_64)

On Tue, Aug 2, 2016 at 1:14 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> On Wed, Jul 27, 2016 at 8:59 AM, Thomas Garnier wrote: >> > Add vmemmap in the list of randomized memory regions. >> > >> > The vmemmap region holds a representation of

Re: [PATCH] x86/mm: Enable KASLR for vmemmap memory region (x86_64)

On Wed, Jul 27, 2016 at 8:59 AM, Thomas Garnier <thgar...@google.com> wrote: > Add vmemmap in the list of randomized memory regions. > > The vmemmap region holds a representation of the physical memory (through > a struct page array). An attacker could use this region to dis

Re: [PATCH] x86/mm: Enable KASLR for vmemmap memory region (x86_64)

On Wed, Jul 27, 2016 at 8:59 AM, Thomas Garnier wrote: > Add vmemmap in the list of randomized memory regions. > > The vmemmap region holds a representation of the physical memory (through > a struct page array). An attacker could use this region to disclose the > kernel memory

[PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore

When KASLR memory randomization is used, __PAGE_OFFSET is a global variable changed during boot. The assembly code was using the variable as an immediate value to calculate the cr3 physical address. The physical address was incorrect resulting to a GP fault. Signed-off-by: Thomas Garnier <th

[PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping

Correctly setup the temporary mapping for hibernation. Previous implementation assumed the address was aligned on the PGD level. With KASLR memory randomization enabled, the address is randomized on the PUD level. This change supports unaligned address up to PMD. Signed-off-by: Thomas Garnier

[PATCH v1 2/2] x86/power/64: Fix __PAGE_OFFSET usage on restore

When KASLR memory randomization is used, __PAGE_OFFSET is a global variable changed during boot. The assembly code was using the variable as an immediate value to calculate the cr3 physical address. The physical address was incorrect resulting to a GP fault. Signed-off-by: Thomas Garnier

[PATCH v1 1/2] x86/power/64: Support unaligned addresses for temporary mapping

Correctly setup the temporary mapping for hibernation. Previous implementation assumed the address was aligned on the PGD level. With KASLR memory randomization enabled, the address is randomized on the PUD level. This change supports unaligned address up to PMD. Signed-off-by: Thomas Garnier

[PATCH v1 0/2] x86/power/64: Make KASLR memory randomization compatible with hibernation

***Background: KASLR memory randomization for x86_64 was added when KASLR did not support hibernation. Now that it does, some changes are needed. ***Problems that needed solving: Hibernation was failing on reboot with a GP fault when CONFIG_RANDOMIZE_MEMORY was enabled. Two issues were

[PATCH v1 0/2] x86/power/64: Make KASLR memory randomization compatible with hibernation

***Background: KASLR memory randomization for x86_64 was added when KASLR did not support hibernation. Now that it does, some changes are needed. ***Problems that needed solving: Hibernation was failing on reboot with a GP fault when CONFIG_RANDOMIZE_MEMORY was enabled. Two issues were

[PATCH] x86/mm: Enable KASLR for vmemmap memory region (x86_64)

Add vmemmap in the list of randomized memory regions. The vmemmap region holds a representation of the physical memory (through a struct page array). An attacker could use this region to disclose the kernel memory layout (walking the page linked list). Signed-off-by: Thomas Garnier <th

[PATCH] x86/mm: Enable KASLR for vmemmap memory region (x86_64)

Add vmemmap in the list of randomized memory regions. The vmemmap region holds a representation of the physical memory (through a struct page array). An attacker could use this region to disclose the kernel memory layout (walking the page linked list). Signed-off-by: Thomas Garnier Signed-off

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

I am sorry, there has been parallel work between KASLR memory randomization and hibernation support. That's why hibernation was not tested, it was not supported when the feature was created. Communication will be better next time. I will work on identifying the problem and pushing a fix. Thanks

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

I am sorry, there has been parallel work between KASLR memory randomization and hibernation support. That's why hibernation was not tested, it was not supported when the feature was created. Communication will be better next time. I will work on identifying the problem and pushing a fix. Thanks

[tip:x86/boot] x86/mm: Do not reference phys addr beyond kernel

Commit-ID: 4ff5308744f5858e4e49e56a0445e2f8b73e47e0 Gitweb: http://git.kernel.org/tip/4ff5308744f5858e4e49e56a0445e2f8b73e47e0 Author: Thomas Garnier <thgar...@google.com> AuthorDate: Wed, 15 Jun 2016 12:05:45 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sun,

[tip:x86/boot] x86/mm: Do not reference phys addr beyond kernel

Commit-ID: 4ff5308744f5858e4e49e56a0445e2f8b73e47e0 Gitweb: http://git.kernel.org/tip/4ff5308744f5858e4e49e56a0445e2f8b73e47e0 Author: Thomas Garnier AuthorDate: Wed, 15 Jun 2016 12:05:45 -0700 Committer: Ingo Molnar CommitDate: Sun, 10 Jul 2016 17:21:37 +0200 x86/mm: Do not reference

[tip:x86/boot] x86/mm: Separate variable for trampoline PGD

Commit-ID: b234e8a09003af108d3573f0369e25c080676b14 Gitweb: http://git.kernel.org/tip/b234e8a09003af108d3573f0369e25c080676b14 Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 21 Jun 2016 17:47:01 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 8

[tip:x86/boot] x86/mm: Separate variable for trampoline PGD

Commit-ID: b234e8a09003af108d3573f0369e25c080676b14 Gitweb: http://git.kernel.org/tip/b234e8a09003af108d3573f0369e25c080676b14 Author: Thomas Garnier AuthorDate: Tue, 21 Jun 2016 17:47:01 -0700 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 17:33:46 +0200 x86/mm: Separate variable

[tip:x86/boot] x86/mm: Add PUD VA support for physical mapping

Commit-ID: faa379332f3cb3375db1849e27386f8bc9b97da4 Gitweb: http://git.kernel.org/tip/faa379332f3cb3375db1849e27386f8bc9b97da4 Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 21 Jun 2016 17:47:00 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 8

[tip:x86/boot] x86/mm: Add PUD VA support for physical mapping

Commit-ID: faa379332f3cb3375db1849e27386f8bc9b97da4 Gitweb: http://git.kernel.org/tip/faa379332f3cb3375db1849e27386f8bc9b97da4 Author: Thomas Garnier AuthorDate: Tue, 21 Jun 2016 17:47:00 -0700 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 17:33:46 +0200 x86/mm: Add PUD VA

[tip:x86/boot] x86/mm: Add memory hotplug support for KASLR memory randomization

Commit-ID: 90397a41779645d3abba5599f6bb538fdcab9339 Gitweb: http://git.kernel.org/tip/90397a41779645d3abba5599f6bb538fdcab9339 Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 21 Jun 2016 17:47:06 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 8

[tip:x86/boot] x86/mm: Add memory hotplug support for KASLR memory randomization

Commit-ID: 90397a41779645d3abba5599f6bb538fdcab9339 Gitweb: http://git.kernel.org/tip/90397a41779645d3abba5599f6bb538fdcab9339 Author: Thomas Garnier AuthorDate: Tue, 21 Jun 2016 17:47:06 -0700 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 17:35:21 +0200 x86/mm: Add memory

[tip:x86/boot] x86/mm: Enable KASLR for vmalloc memory regions

Commit-ID: a95ae27c2ee1cba5f4f6b9dea43ffe88252e79b1 Gitweb: http://git.kernel.org/tip/a95ae27c2ee1cba5f4f6b9dea43ffe88252e79b1 Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 21 Jun 2016 17:47:04 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 8

[tip:x86/boot] x86/mm: Implement ASLR for kernel memory regions

Commit-ID: 0483e1fa6e09d4948272680f691dccb1edb9677f Gitweb: http://git.kernel.org/tip/0483e1fa6e09d4948272680f691dccb1edb9677f Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 21 Jun 2016 17:47:02 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 8

[tip:x86/boot] x86/mm: Enable KASLR for vmalloc memory regions

Commit-ID: a95ae27c2ee1cba5f4f6b9dea43ffe88252e79b1 Gitweb: http://git.kernel.org/tip/a95ae27c2ee1cba5f4f6b9dea43ffe88252e79b1 Author: Thomas Garnier AuthorDate: Tue, 21 Jun 2016 17:47:04 -0700 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 17:35:21 +0200 x86/mm: Enable KASLR

[tip:x86/boot] x86/mm: Implement ASLR for kernel memory regions

Commit-ID: 0483e1fa6e09d4948272680f691dccb1edb9677f Gitweb: http://git.kernel.org/tip/0483e1fa6e09d4948272680f691dccb1edb9677f Author: Thomas Garnier AuthorDate: Tue, 21 Jun 2016 17:47:02 -0700 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 17:33:46 +0200 x86/mm: Implement ASLR

[tip:x86/boot] x86/mm: Update physical mapping variable names

Commit-ID: 59b3d0206d74a700069e49160e8194b2ca93b703 Gitweb: http://git.kernel.org/tip/59b3d0206d74a700069e49160e8194b2ca93b703 Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 21 Jun 2016 17:46:59 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 8

[tip:x86/boot] x86/mm: Update physical mapping variable names

Commit-ID: 59b3d0206d74a700069e49160e8194b2ca93b703 Gitweb: http://git.kernel.org/tip/59b3d0206d74a700069e49160e8194b2ca93b703 Author: Thomas Garnier AuthorDate: Tue, 21 Jun 2016 17:46:59 -0700 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 17:33:46 +0200 x86/mm: Update physical

[tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

Commit-ID: 021182e52fe01c1f7b126f97fd6ba048dc4234fd Gitweb: http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 21 Jun 2016 17:47:03 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 8

[tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

Commit-ID: 021182e52fe01c1f7b126f97fd6ba048dc4234fd Gitweb: http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd Author: Thomas Garnier AuthorDate: Tue, 21 Jun 2016 17:47:03 -0700 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 17:35:15 +0200 x86/mm: Enable KASLR

[tip:x86/boot] x86/mm: Refactor KASLR entropy functions

Commit-ID: d899a7d146a2ed8a7e6c2f61bcd232908bcbaabc Gitweb: http://git.kernel.org/tip/d899a7d146a2ed8a7e6c2f61bcd232908bcbaabc Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 21 Jun 2016 17:46:58 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 8

[tip:x86/boot] x86/mm: Refactor KASLR entropy functions

Commit-ID: d899a7d146a2ed8a7e6c2f61bcd232908bcbaabc Gitweb: http://git.kernel.org/tip/d899a7d146a2ed8a7e6c2f61bcd232908bcbaabc Author: Thomas Garnier AuthorDate: Tue, 21 Jun 2016 17:46:58 -0700 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 17:33:45 +0200 x86/mm: Refactor KASLR

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper wrote: > Hey Kees, > > On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote: >> Notable problems that needed solving: > ... >> - Reasonable entropy is needed early at boot before get_random_bytes() >>is available. > >

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper wrote: > Hey Kees, > > On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote: >> Notable problems that needed solving: > ... >> - Reasonable entropy is needed early at boot before get_random_bytes() >>is available. > > This series is

Re: [PATCH v6 2/3] x86/mm: Implement ASLR for kernel memory sections (x86_64)

On Fri, Jun 17, 2016 at 3:26 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -1993,6 +1993,23 @@ config PHYSICAL_ALIGN >> >> Don't change this unless you know what you are doing. >> >>

Re: [PATCH v6 2/3] x86/mm: Implement ASLR for kernel memory sections (x86_64)

On Fri, Jun 17, 2016 at 3:26 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -1993,6 +1993,23 @@ config PHYSICAL_ALIGN >> >> Don't change this unless you know what you are doing. >> >> +config RANDOMIZE_MEMORY >> + bool

Re: [PATCH v6 1/3] x86/mm: PUD VA support for physical mapping (x86_64)

On Fri, Jun 17, 2016 at 2:02 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Kees Cook <keesc...@chromium.org> wrote: > >> From: Thomas Garnier <thgar...@google.com> >> >> Minor change that allows early boot physical mapping of PUD level virtual >

Re: [PATCH v6 1/3] x86/mm: PUD VA support for physical mapping (x86_64)

On Fri, Jun 17, 2016 at 2:02 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> From: Thomas Garnier >> >> Minor change that allows early boot physical mapping of PUD level virtual >> addresses. The current implementation expects the virtual address to be

[PATCH v1 1/2] mm: Reorganize SLAB freelist randomization

chosen because they provide a bit more entropy early on boot and better performance when specific arch instructions are not available. Signed-off-by: Thomas Garnier <thgar...@google.com> Reviewed-by: Kees Cook <keesc...@chromium.org> --- Based on next-20160526 --- include/linux/sla

[PATCH v1 1/2] mm: Reorganize SLAB freelist randomization

chosen because they provide a bit more entropy early on boot and better performance when specific arch instructions are not available. Signed-off-by: Thomas Garnier Reviewed-by: Kees Cook --- Based on next-20160526 --- include/linux/slab_def.h | 2 +- mm/slab.c| 80

[PATCH v1 2/2] mm: SLUB Freelist randomization

Context Switches 189140 (2282.15) Sleeps 99008.6 (768.091) After: Average Optimal load -j 12 Run (std deviation): Elapsed Time 102.47 (0.562732) User Time 1045.3 (1.34263) System Time 88.311 (0.342554) Percent CPU 1105.8 (6.49444) Context Switches 189081 (2355.78) Sleeps 99231.5 (800.358)

[PATCH v1 2/2] mm: SLUB Freelist randomization

Context Switches 189140 (2282.15) Sleeps 99008.6 (768.091) After: Average Optimal load -j 12 Run (std deviation): Elapsed Time 102.47 (0.562732) User Time 1045.3 (1.34263) System Time 88.311 (0.342554) Percent CPU 1105.8 (6.49444) Context Switches 189081 (2355.78) Sleeps 99231.5 (800.358) Signed-

[PATCH v1 0/2] mm: SLUB Freelist randomization

This is PATCH v1 for the SLUB Freelist randomization. The patch is now based on the Linux master branch (as the based SLAB patch was merged). Changes since RFC v2: - Redone slab_test testing to decide best entropy approach on new page creation. - Moved to use get_random_int as best approach

[PATCH v1 0/2] mm: SLUB Freelist randomization

This is PATCH v1 for the SLUB Freelist randomization. The patch is now based on the Linux master branch (as the based SLAB patch was merged). Changes since RFC v2: - Redone slab_test testing to decide best entropy approach on new page creation. - Moved to use get_random_int as best approach

Re: [RFC v2 1/2] mm: Reorganize SLAB freelist randomization

On Wed, May 25, 2016 at 6:09 PM, Joonsoo Kim <iamjoonsoo@lge.com> wrote: > On Tue, May 24, 2016 at 02:15:22PM -0700, Thomas Garnier wrote: >> This commit reorganizes the previous SLAB freelist randomization to >> prepare for the SLUB implementation. It moves functions t

Re: [RFC v2 1/2] mm: Reorganize SLAB freelist randomization

On Wed, May 25, 2016 at 6:09 PM, Joonsoo Kim wrote: > On Tue, May 24, 2016 at 02:15:22PM -0700, Thomas Garnier wrote: >> This commit reorganizes the previous SLAB freelist randomization to >> prepare for the SLUB implementation. It moves functions that will be >> shared to

Re: [RFC v2 2/2] mm: SLUB Freelist randomization

On Wed, May 25, 2016 at 6:49 PM, Joonsoo Kim <js1...@gmail.com> wrote: > 2016-05-25 6:15 GMT+09:00 Thomas Garnier <thgar...@google.com>: >> Implements Freelist randomization for the SLUB allocator. It was >> previous implemented for the SLAB allocator. Both use the s

Re: [RFC v2 2/2] mm: SLUB Freelist randomization

On Wed, May 25, 2016 at 6:49 PM, Joonsoo Kim wrote: > 2016-05-25 6:15 GMT+09:00 Thomas Garnier : >> Implements Freelist randomization for the SLUB allocator. It was >> previous implemented for the SLAB allocator. Both use the same >> configuration option (CONFIG

Re: [RFC v2 2/2] mm: SLUB Freelist randomization

On Wed, May 25, 2016 at 3:25 PM, Kees Cook <keesc...@chromium.org> wrote: > On Tue, May 24, 2016 at 2:15 PM, Thomas Garnier <thgar...@google.com> wrote: >> Implements Freelist randomization for the SLUB allocator. It was >> previous implemented for the SLAB a

Re: [RFC v2 2/2] mm: SLUB Freelist randomization

On Wed, May 25, 2016 at 3:25 PM, Kees Cook wrote: > On Tue, May 24, 2016 at 2:15 PM, Thomas Garnier wrote: >> Implements Freelist randomization for the SLUB allocator. It was >> previous implemented for the SLAB allocator. Both use the same >> configuration option (CONFIG

[RFC v2 2/2] mm: SLUB Freelist randomization

Time 102.47 (0.562732) User Time 1045.3 (1.34263) System Time 88.311 (0.342554) Percent CPU 1105.8 (6.49444) Context Switches 189081 (2355.78) Sleeps 99231.5 (800.358) Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on 0e01df100b6bf22a1de61b66657502a6454153c5 --- include/linu

[RFC v2 2/2] mm: SLUB Freelist randomization

Time 102.47 (0.562732) User Time 1045.3 (1.34263) System Time 88.311 (0.342554) Percent CPU 1105.8 (6.49444) Context Switches 189081 (2355.78) Sleeps 99231.5 (800.358) Signed-off-by: Thomas Garnier --- Based on 0e01df100b6bf22a1de61b66657502a6454153c5 --- include/linux/slub_def.h | 8 ++

[RFC v2 1/2] mm: Reorganize SLAB freelist randomization

functions are changed to align with the SLUB implementation, now using get_random_* functions. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on 0e01df100b6bf22a1de61b66657502a6454153c5 --- include/linux/slab_def.h | 11 +++- mm/slab.c

[RFC v2 1/2] mm: Reorganize SLAB freelist randomization

functions are changed to align with the SLUB implementation, now using get_random_* functions. Signed-off-by: Thomas Garnier --- Based on 0e01df100b6bf22a1de61b66657502a6454153c5 --- include/linux/slab_def.h | 11 +++- mm/slab.c| 68

[RFC v2 0/2] mm: SLUB Freelist randomization

This is RFC v2 for the SLUB Freelist randomization. The patch is now based on the Linux master branch (as the based SLAB patch was merged). Changes since RFC v1: - Redone slab_test testing to decide best entropy approach on new page creation. - Moved to use get_random_int as best approach to

[RFC v2 0/2] mm: SLUB Freelist randomization

This is RFC v2 for the SLUB Freelist randomization. The patch is now based on the Linux master branch (as the based SLAB patch was merged). Changes since RFC v1: - Redone slab_test testing to decide best entropy approach on new page creation. - Moved to use get_random_int as best approach to

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

On Thu, May 19, 2016 at 7:15 PM, Joonsoo Kim <js1...@gmail.com> wrote: > 2016-05-20 5:20 GMT+09:00 Thomas Garnier <thgar...@google.com>: >> I ran the test given by Joonsoo and it gave me these minimum cycles >> per size across 20 usage: > > I can't understand w

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

On Thu, May 19, 2016 at 7:15 PM, Joonsoo Kim wrote: > 2016-05-20 5:20 GMT+09:00 Thomas Garnier : >> I ran the test given by Joonsoo and it gave me these minimum cycles >> per size across 20 usage: > > I can't understand what you did here. Maybe, it's due to my poor Engling.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

but increase performance for machines without arch specific randomization instructions. Thanks, Thomas On Wed, May 18, 2016 at 7:07 PM, Joonsoo Kim <iamjoonsoo@lge.com> wrote: > On Wed, May 18, 2016 at 12:12:13PM -0700, Thomas Garnier wrote: >> I thought the mix of slab_test & k

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

but increase performance for machines without arch specific randomization instructions. Thanks, Thomas On Wed, May 18, 2016 at 7:07 PM, Joonsoo Kim wrote: > On Wed, May 18, 2016 at 12:12:13PM -0700, Thomas Garnier wrote: >> I thought the mix of slab_test & kernbench would show a diver

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

I thought the mix of slab_test & kernbench would show a diverse picture on perf data. Is there another test that you think would be useful? Thanks, Thomas On Wed, May 18, 2016 at 12:02 PM, Christoph Lameter <c...@linux.com> wrote: > On Wed, 18 May 2016, Thomas Garnier wrote: >

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

I thought the mix of slab_test & kernbench would show a diverse picture on perf data. Is there another test that you think would be useful? Thanks, Thomas On Wed, May 18, 2016 at 12:02 PM, Christoph Lameter wrote: > On Wed, 18 May 2016, Thomas Garnier wrote: > >&

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

Yes, I agree that it is not related to the changes. On Wed, May 18, 2016 at 11:24 AM, Christoph Lameter <c...@linux.com> wrote: > 0.On Wed, 18 May 2016, Thomas Garnier wrote: > >> slab_test, before: >> 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles >>

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

Yes, I agree that it is not related to the changes. On Wed, May 18, 2016 at 11:24 AM, Christoph Lameter wrote: > 0.On Wed, 18 May 2016, Thomas Garnier wrote: > >> slab_test, before: >> 1 times kmalloc(8) -> 67 cycles kfree -> 101 cycles >> 1 times kmalloc

[RFC v1 2/2] mm: SLUB Freelist randomization

ycles Kernbench, before: Average Optimal load -j 12 Run (std deviation): Elapsed Time 101.873 (1.16069) User Time 1045.22 (1.60447) System Time 88.969 (0.559195) Percent CPU 1112.9 (13.8279) Context Switches 189140 (2282.15) Sleeps 99008.6 (768.091) After: Average Optimal load -j 12 Run (std deviation

[RFC v1 2/2] mm: SLUB Freelist randomization

ycles Kernbench, before: Average Optimal load -j 12 Run (std deviation): Elapsed Time 101.873 (1.16069) User Time 1045.22 (1.60447) System Time 88.969 (0.559195) Percent CPU 1112.9 (13.8279) Context Switches 189140 (2282.15) Sleeps 99008.6 (768.091) After: Average Optimal load -j 12 Run (std de

[RFC v1 1/2] mm: Reorganize SLAB freelist randomization

-by: Thomas Garnier <thgar...@google.com> --- Based on next-20160517 --- include/linux/slab_def.h | 11 +++- mm/slab.c| 66 +--- mm/slab.h| 16 mm/slab_common.c

[RFC v1 1/2] mm: Reorganize SLAB freelist randomization

-by: Thomas Garnier --- Based on next-20160517 --- include/linux/slab_def.h | 11 +++- mm/slab.c| 66 +--- mm/slab.h| 16 mm/slab_common.c | 50 4 files changed

<    2   3   4   5   6   7   8   9   >