[PATCH v4 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 v4 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20160805 --- arch/x86/kernel/setup.c | 8 ++-- arch/x86/mm/kaslr.c | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index bcabb88..dc50644 100644 --- a

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

On Wed, Aug 10, 2016 at 9:35 AM, Borislav Petkov wrote: > On Wed, Aug 10, 2016 at 04:59:40PM +0200, Jiri Kosina wrote: >> Mine is Lenovo thinkpad x200s; I think Boris has been testing it on x230s, > > It says "X230" here under the screen. > >> but not sure whether any of the latest

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

On Wed, Aug 10, 2016 at 6:18 AM, Jiri Kosina wrote: > On Wed, 10 Aug 2016, Rafael J. Wysocki wrote: > >> The last patch I sent had a problem, because if restore_jump_address really >> overlapped with the identity mapping of the restore kernel, it might share >> PGD or PUD

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] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 4:14 AM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Fri, Aug 12, 2016 at 7:49 AM, Borislav Petkov <b...@suse.de> wrote: >> On Thu, Aug 11, 2016 at 02:49:29PM -0700, Thomas Garnier wrote: >>> Restore the processor state before callin

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

On Fri, Aug 12, 2016 at 2:23 AM, Jiri Kosina wrote: > On Fri, 12 Aug 2016, Jiri Kosina wrote: > > That's pretty nasty, as turning LOCKDEP on has sideffects on the code > that'd normally not be expected to be run at all (tracepoint off). > > Oh well. Thanks for the analysis, I

[PATCH v2] x86/power/64: Restore processor state before using per-cpu variables

the tracing & the exception handler functions tried to use a per-cpu variable. Reported-by: Jiri Kosina <jkos...@suse.cz> Tested-by: Jiri Kosina <jkos...@suse.cz> Acked-by: Pavel Machek <pa...@ucw.cz> Reported-and-tested-by: Borislav Petkov <b...@suse.de> Signed-o

[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

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

[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

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 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: [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: [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

[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 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 --

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 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

[PATCH v1] kdump, vmcoreinfo: report memory sections virtual addresses

KASLR memory randomization can randomize the base of the physical memory mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap (VMEMMAP_START). Adding these variables on VMCOREINFO so tools can easily identify the base of each memory section. Signed-off-by: Thomas Garnier <th

Re: [PATCH] mm/slub: Fix random_seq offset destruction

err) { > pr_err("SLUB: Unable to initialize free list for %s\n", > -- > 2.9.3 > Otherwise, looks good to me. Reviewed-by: Thomas Garnier <thgar...@google.com> -- Thomas

[PATCH v2 3/3] x86: Make the GDT remapping read-only on 64 bit

the original GDT. Instead of reloading the previous GDT, VMX will reload the fixmap GDT as expected. For testing, VMs were started and restored on multiple configurations. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170125 --- arch/x86/include/asm/desc.h

[PATCH v2 2/3] x86: Remap GDT tables in the Fixmap section

. For hibernation, the main processor returns with the original GDT and switches back to the remapping at completion. This patch was tested on both architectures. Hibernation and KVM were both tested specially for their usage of the GDT. Signed-off-by: Thomas Garnier <thgar...@google.com> ---

[PATCH v2 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

address does not provide enough space for the kernel to support a large number of processors. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170125 --- arch/x86/include/asm/fixmap.h | 8 arch/x86/include/asm/pgtable_64_types.h | 3 --- arch/x86/

Re: [PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

On Fri, Jan 20, 2017 at 5:06 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier <thgar...@google.com> wrote: >> This patch makes the GDT remapped pages read-only to prevent corruption. >> This ch

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

On Fri, Jan 20, 2017 at 4:57 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier <thgar...@google.com> wrote: >> Each processor holds a GDT in its per-cpu structure. The sgdt >> instruction gives the base address of the cu

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

Garnier <thgar...@google.com> wrote: > On Fri, Jan 20, 2017 at 4:57 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier <thgar...@google.com> wrote: >>> Each processor holds a GDT in its per-cpu structure. The sgdt &g

Re: [PATCH 4/6] x86/kvm/vmx: Simplify segment_base()

ems a lot better than > before to me. > > This is mostly borrowed from a patch by Thomas Garnier. > Looks good, I like that the 64-bit usage could be removed. Thanks! > Cc: Thomas Garnier <thgar...@google.com> > Cc: Jim Mattson <jmatt...@google.com> > Cc: Radim

Re: [PATCH v4 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

address does not provide enough space for the kernel to support a large number of processors. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170213 Fixed fixmap dependencies on random configurations. --- Documentation/x86/x86_64/mm.txt | 5 - arch/x86/inclu

[PATCH v4 2/4] x86: Remap GDT tables in the Fixmap section

. For hibernation, the main processor returns with the original GDT and switches back to the remapping at completion. This patch was tested on both architectures. Hibernation and KVM were both tested specially for their usage of the GDT. Signed-off-by: Thomas Garnier <thgar...@google.com> ---

[PATCH v3 3/4] x86: Make the GDT remapping read-only on 64-bit

the original GDT. Instead of reloading the previous GDT, VMX will reload the fixmap GDT as expected. For testing, VMs were started and restored on multiple configurations. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170213 --- arch/x86/include/asm/desc.h

[PATCH v3 2/4] x86: Remap GDT tables in the Fixmap section

. For hibernation, the main processor returns with the original GDT and switches back to the remapping at completion. This patch was tested on both architectures. Hibernation and KVM were both tested specially for their usage of the GDT. Signed-off-by: Thomas Garnier <thgar...@google.com> ---

[PATCH v3 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

address does not provide enough space for the kernel to support a large number of processors. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170213 --- arch/x86/include/asm/fixmap.h | 8 arch/x86/include/asm/pgtable_64_types.h | 3 --- arch/x86/

[PATCH v3 4/4] KVM: VMX: Simplify segment_base

The KVM segment_base function is confusing. This patch replaces integers with appropriate flags, simplify constructs and add comments. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170213 --- arch/x86/kvm/vmx.c | 26 ++ 1 file chang

Re: [RFC] syscalls: Restore address limit after a syscall

On Thu, Feb 9, 2017 at 3:05 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Thu, Feb 9, 2017 at 11:31 AM, Kees Cook <keesc...@chromium.org> wrote: >> On Thu, Feb 9, 2017 at 10:33 AM, Thomas Garnier <thgar...@google.com> wrote: >>> This patch prevents a

[RFC] syscalls: Restore address limit after a syscall

This patch prevents a syscall to modify the address limit of the caller. The address limit is kept by the syscall wrapper and restored just after the syscall ends. For example, it would mitigation this bug: - https://bugs.chromium.org/p/project-zero/issues/detail?id=990 Signed-off-by: Thomas

[PATCH v4 3/4] x86: Make the GDT remapping read-only on 64-bit

the original GDT. Instead of reloading the previous GDT, VMX will reload the fixmap GDT as expected. For testing, VMs were started and restored on multiple configurations. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170213 --- arch/x86/include/asm/desc.h

[PATCH v4 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

address does not provide enough space for the kernel to support a large number of processors. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170213 --- Documentation/x86/x86_64/mm.txt | 5 - arch/x86/include/asm/pgtable_64_types.h | 3 ++- 2 files chan

[PATCH v4 4/4] KVM: VMX: Simplify segment_base

The KVM segment_base function is confusing. This patch replaces integers with appropriate flags, simplify constructs and add comments. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170213 --- arch/x86/kvm/vmx.c | 30 -- 1 file chang

[PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

variables for convenience. For testing, VMs were started and restored on multiple configurations. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170119 --- arch/x86/include/asm/desc.h | 44 +++- arch/x86/include/asm/proce

[PATCH v1 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

address does not provide enough space for the kernel to support a large number of processors. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170119 --- arch/x86/include/asm/fixmap.h | 8 arch/x86/include/asm/pgtable_64_types.h | 3 --- 2 files chan

[PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

available. This patch was tested on both architectures. Hibernation and KVM were both tested specially for their usage of the GDT. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170119 --- arch/x86/Kconfig | 1 + arch/x86/include/asm/fixmap.h

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 v1] kdump, vmcoreinfo: report memory sections virtual addresses

BUDDY_MAPCOUNT_VALUE); >> > #ifdef CONFIG_X86 >> > VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE); >> > + VMCOREINFO_NUMBER(PAGE_OFFSET); >> > + VMCOREINFO_NUMBER(VMALLOC_START); >> > + VMCOREINFO_NUMBER(VMEMMAP_START); >> > #endif

Re: [PATCH v1] kdump, vmcoreinfo: report memory sections virtual addresses

+ VMCOREINFO_NUMBER(VMALLOC_START); > + VMCOREINFO_NUMBER(VMEMMAP_START); > #endif > #ifdef CONFIG_HUGETLB_PAGE > VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR); > -- > 2.5.5 > > On 08/18/16 at 07:47am, Thomas Garnier wrote: >> KASLR memory randomization can rand

[PATCH v1] memcg: Prevent caches to be both OFF_SLAB & OBJFREELIST_SLAB

ance of __kmem_cache_create. This way the function will define which way the freelist should be handled at this stage for the new cache. Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type, OBJFREELIST_SLAB") Signed-off-by: Thomas Garnier <thgar...@google.com> Signed-off-b

Re: [PATCH v1] memcg: Prevent caches to be both OFF_SLAB & OBJFREELIST_SLAB

have both flags >> at the same time resulting in allocation failures and odd behaviors. >> >> The proposed fix removes these flags by default at the entrance of >> __kmem_cache_create. This way the function will define which way the >> freelist should be handled a

Re: [PATCH v1] memcg: Prevent caches to be both OFF_SLAB & OBJFREELIST_SLAB

gt; Yes, the next iteration should be closer to memcg. I will CC Vladimir. Thanks for the heads-up. > On Wed 26-10-16 10:41:28, Thomas Garnier wrote: >> While testing OBJFREELIST_SLAB integration with pagealloc, we found a >> bug where kmem_cache(sys) would be created with both CFLGS_OFF

[PATCH v3 2/2] mm: Check kmem_create_cache flags are commons

Verify that kmem_create_cache flags are not allocator specific. It is done before removing flags that are not available with the current configuration. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20161027 --- mm/slab.h| 15 +++ mm/slab_common.

[PATCH v3 1/2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

r specific flags from memcg before calling create_cache. Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type, OBJFREELIST_SLAB") Signed-off-by: Greg Thelen <gthe...@google.com> Tested-by: Thomas Garnier <thgar...@google.com> --- Based on next-20161027 --- mm/slab_c

Re: [PATCH v3 1/2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

On Mon, Nov 7, 2016 at 2:19 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Mon, 7 Nov 2016 13:11:14 -0800 Thomas Garnier <thgar...@google.com> wrote: > >> From: Greg Thelen <gthe...@google.com> >> >> While testing OBJFREELIST_SLAB integrati

[PATCH v4 1/2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

y: Greg Thelen <gthe...@google.com> Signed-off-by: Thomas Garnier <thgar...@google.com> Tested-by: Thomas Garnier <thgar...@google.com> --- Based on next-20161027 --- mm/slab_common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/slab_common.c b/mm/slab_

[PATCH v4 2/2] mm: Check kmem_create_cache flags are commons

Verify that kmem_create_cache flags are not allocator specific. It is done before removing flags that are not available with the current configuration. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20161027 --- mm/slab.h| 15 +++ mm/slab_common.

Re: [PATCH v3 2/2] mm: Check kmem_create_cache flags are commons

On Mon, Nov 7, 2016 at 3:07 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Mon, 7 Nov 2016 13:11:15 -0800 Thomas Garnier <thgar...@google.com> wrote: > >> Verify that kmem_create_cache flags are not allocator specific. It is >> done before removin

Re: [PATCH v3 1/2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

On Mon, Nov 7, 2016 at 2:49 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Mon, 7 Nov 2016 14:32:56 -0800 Thomas Garnier <thgar...@google.com> wrote: > >> On Mon, Nov 7, 2016 at 2:19 PM, Andrew Morton <a...@linux-foundation.org> >> wrote: >> &

Re: [PATCH v2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

On Mon, Nov 7, 2016 at 11:28 AM, Christoph Lameter <c...@linux.com> wrote: > On Mon, 7 Nov 2016, Thomas Garnier wrote: > >> I am not sure that is possible. kmem_cache_create currently check for >> possible alias, I assume that it goes against what memcg tries to do. >

Re: [PATCH v2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

On Thu, Nov 3, 2016 at 1:33 PM, Christoph Lameter wrote: > On Wed, 2 Nov 2016, David Rientjes wrote: > >> > Christoph on the first version advised removing invalid flags on the >> > caller and checking they are correct in kmem_cache_create. The memcg >> > path putting the wrong

Re: [PATCH v2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

On Mon, Oct 31, 2016 at 4:38 PM, David Rientjes <rient...@google.com> wrote: > On Mon, 31 Oct 2016, Thomas Garnier wrote: > >> While testing OBJFREELIST_SLAB integration with pagealloc, we found a >> bug where kmem_cache(sys) would be created with both CFLGS_OFF_SLAB &am

[PATCH v2] memcg: Prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

eate cannot be called with them. Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type, OBJFREELIST_SLAB") Signed-off-by: Thomas Garnier <thgar...@google.com> Signed-off-by: Greg Thelen <gthe...@google.com> --- Based on next-20161025 --- mm/slab.h| 3

[PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses""

when KASLR memory randomization is enabled. Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/x86/kernel/machine_kexec_64.c | 3 +++ include/linux/kexec.h | 6 ++ 2 files changed, 9 insertions(+) diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/

Re: [PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses""

On Thu, Dec 15, 2016 at 10:16 AM, Thomas Garnier <thgar...@google.com> wrote: > On Thu, Dec 15, 2016 at 9:50 AM, Eric W. Biederman > <ebied...@xmission.com> wrote: >> Thomas Garnier <thgar...@google.com> writes: >> >>> This reverts commit 49fd897573c97b

Re: [PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses""

On Thu, Dec 15, 2016 at 9:50 AM, Eric W. Biederman <ebied...@xmission.com> wrote: > Thomas Garnier <thgar...@google.com> writes: > >> This reverts commit 49fd897573c97b0eaf10f47d850027d78c456cd7. >> >> Reverting back to commit 0549a3c because the values are used

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Tue, Jan 10, 2017 at 2:27 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Thomas Garnier <thgar...@google.com> wrote: > >> Coming back on that after a bit more testing. The LTR instruction >> check if the busy bit is already set, if already set then it wil

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 11:35 PM, Ingo Molnar <mi...@kernel.org> wrote: > > * Thomas Garnier <thgar...@google.com> wrote: > >> > No, and I had the way this worked on 64-bit wrong. LTR requires an >> > available TSS and changes it to busy. So here are m

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:01 AM, Andy Lutomirski <l...@amacapital.net> wrote: > On Thu, Jan 5, 2017 at 9:54 AM, Thomas Garnier <thgar...@google.com> wrote: >> On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski <l...@amacapital.net> wrote: >>> On Wed, Jan 4, 20

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski <l...@amacapital.net> wrote: > On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier <thgar...@google.com> wrote: >> Each processor holds a GDT in its per-cpu structure. The sgdt >> instruction gives the base address of the cu

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:56 AM, Arjan van de Ven <ar...@linux.intel.com> wrote: > On 1/5/2017 8:40 AM, Thomas Garnier wrote: >> >> Well, it happens only when KASLR memory randomization is enabled. Do >> you think it should have a separate config option? > > >

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven <ar...@linux.intel.com> wrote: > On 1/5/2017 9:54 AM, Thomas Garnier wrote: > >> >> That's my goal too. I started by doing a RO remap and got couple >> problems with hibernation. I can try again for the next iterat

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier <thgar...@google.com> wrote: >> On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven <ar...@linux.intel.com> >> wrote: >>>

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 1:19 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Thu, Jan 5, 2017 at 1:08 PM, Thomas Garnier <thgar...@google.com> wrote: >> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski <l...@kernel.org> wrote: >>> On Thu, Jan 5, 201

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 10:49 PM, Ingo Molnar <mi...@kernel.org> wrote: > > * Thomas Garnier <thgar...@google.com> wrote: > >> >> Not sure I fully understood and I don't want to miss an important point. >> >> Do >> >> you mea

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 6:34 PM, Andy Lutomirski wrote: > On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds > wrote: >> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >>> >>> Hmm. I bet that if we preset the accessed

Re: [PATCH] Fix SLAB freelist randomization duplicate entries

On Thu, Jan 5, 2017 at 4:35 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Tue, 3 Jan 2017 10:19:08 -0800 Thomas Garnier <thgar...@google.com> wrote: > >> This patch fixes a bug in the freelist randomization code. When a high >> random number is u

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 9:44 AM, Borislav Petkov <b...@alien8.de> wrote: > On Thu, Jan 05, 2017 at 08:40:29AM -0800, Thomas Garnier wrote: >> > kernel_unrandomize_smp() ... >> > >> >> That seems like a better name. > > Hardly... I'd call it something

Re: [PATCH] Fix SLAB freelist randomization duplicate entries

On Fri, Jan 6, 2017 at 12:42 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Fri, 6 Jan 2017 09:58:48 -0800 Thomas Garnier <thgar...@google.com> wrote: > >> On Thu, Jan 5, 2017 at 4:35 PM, Andrew Morton <a...@linux-foundation.org> >> wrote: >> &

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Fri, Jan 6, 2017 at 1:59 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Fri, Jan 6, 2017 at 10:03 AM, Thomas Garnier <thgar...@google.com> wrote: >> On Thu, Jan 5, 2017 at 10:49 PM, Ingo Molnar <mi...@kernel.org> wrote: >>> >>>

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 3:05 PM, Linus Torvalds wrote: > On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >> >> Hmm. I bet that if we preset the accessed bits in all the segments >> then we don't need it to be writable in general. > > I'm

[PATCH] Fix SLAB freelist randomization duplicate entries

ck <jsperb...@google.com> Reviewed-by: Thomas Garnier <thgar...@google.com> --- mm/slab.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index 29bc6c0dedd0..4f2ec6bb46eb 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -2457,7 +2457,6 @@ uni

[RFC] x86/mm/KASLR: Remap GDTs at fixed location

that if there is not enough space available, the GDTs are not remapped. The document was changed to mention GDT remapping for KASLR. This patch also include dump page tables support. This patch was tested on multiple hardware configurations and for hibernation support. Signed-off-by: Thomas Garnier <th

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 12:11 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Thomas Garnier <thgar...@google.com> wrote: > >> Each processor holds a GDT in its per-cpu structure. The sgdt >> instruction gives the base address of the current GDT. This address can

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 7:08 AM, Arjan van de Ven <ar...@linux.intel.com> wrote: > On 1/5/2017 12:11 AM, Ingo Molnar wrote: >> >> >> * Thomas Garnier <thgar...@google.com> wrote: >> >>> Each processor holds a GDT in its per-cpu structure.

Re: [PATCH v5 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier <thgar...@google.com> wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for x86. Signed-off-by: Thomas Garnier <thgar...@google.com> Not sure why it was not there anymore. -- Thomas

Re: [PATCH v5 3/4] arm/syscalls: Specific usage of verify_pre_usermode_state

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier <thgar...@google.com> wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for arm. Signed-off-by: Thomas Garnier <thgar...@google.com> Not sure why it was not there anymore. -- Thomas

Re: [PATCH v5 4/4] arm64/syscalls: Specific usage of verify_pre_usermode_state

On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier <thgar...@google.com> wrote: > Implement specific usage of verify_pre_usermode_state for user-mode > returns for arm64. Signed-off-by: Thomas Garnier <thgar...@google.com> Not sure why it was not there anymore. -- Thomas

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

This error happens even with Andy TLS fix on 32-bit (GDT is on fixmap but not readonly). I am looking into it. KVM internal error. Suberror: 3 extra data[0]: 8b0e extra data[1]: 31 EAX=0001 EBX=9f9121f3 ECX=4330b100 EDX=f000 ESI=547e EDI=ffa74000 EBP=42273ef8 ESP=42273ef8

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

On Tue, Mar 21, 2017 at 12:20 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > On Tue, Mar 21, 2017 at 11:16 AM, Thomas Garnier <thgar...@google.com> wrote: > > This error happens even with Andy TLS fix on 32-bit (GDT is on fixmap > > b

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

On Wed, Mar 22, 2017 at 9:33 AM, Andy Lutomirski <l...@amacapital.net> wrote: > On Wed, Mar 22, 2017 at 12:36 AM, Ingo Molnar <mi...@kernel.org> wrote: >> >> * Thomas Garnier <thgar...@google.com> wrote: >> >>> > static inline void setup_fixm

Re: [PATCH] lkdtm: add bad USER_DS test

On Fri, Mar 24, 2017 at 8:24 AM, Christian Borntraeger <borntrae...@de.ibm.com> wrote: > On 03/24/2017 04:17 PM, Thomas Garnier wrote: >> On Fri, Mar 24, 2017 at 1:14 AM, Heiko Carstens >> <heiko.carst...@de.ibm.com> wrote: >>> On Thu, Mar 23, 2017

[PATCH v5 1/4] syscalls: Restore address limit after a syscall

The CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE option is also added so each architecture can optimize this change. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170322 --- arch/s390/Kconfig| 1 + include/linux/syscalls.h | 26 +- init/K

[PATCH v5 3/4] arm/syscalls: Specific usage of verify_pre_usermode_state

Implement specific usage of verify_pre_usermode_state for user-mode returns for arm. --- Based on next-20170322 --- arch/arm/Kconfig | 1 + arch/arm/kernel/entry-common.S | 16 +++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig

[PATCH v5 4/4] arm64/syscalls: Specific usage of verify_pre_usermode_state

Implement specific usage of verify_pre_usermode_state for user-mode returns for arm64. --- Based on next-20170322 --- arch/arm64/Kconfig| 1 + arch/arm64/kernel/entry.S | 15 +++ 2 files changed, 16 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index

[PATCH v5 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

Implement specific usage of verify_pre_usermode_state for user-mode returns for x86. --- Based on next-20170322 --- arch/x86/Kconfig| 1 + arch/x86/entry/common.c | 3 +++ arch/x86/entry/entry_64.S | 8

[PATCH v4 3/4] arm/syscalls: Specific usage of verify_pre_usermode_state

Implement specific usage of verify_pre_usermode_state for user-mode returns for arm. --- Based on next-20170322 --- arch/arm/Kconfig | 1 + arch/arm/include/asm/domain.h | 3 +++ arch/arm/kernel/entry-common.S | 32 +++- 3 files changed, 35

[PATCH v4 4/4] arm64/syscalls: Specific usage of verify_pre_usermode_state

Implement specific usage of verify_pre_usermode_state for user-mode returns for arm64. --- Based on next-20170322 --- arch/arm64/Kconfig| 1 + arch/arm64/kernel/entry.S | 25 + 2 files changed, 26 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig

[PATCH v4 2/4] x86/syscalls: Specific usage of verify_pre_usermode_state

Implement specific usage of verify_pre_usermode_state for user-mode returns for x86. --- Based on next-20170322 --- arch/x86/Kconfig| 1 + arch/x86/entry/common.c | 3 +++ arch/x86/entry/entry_64.S | 8

Re: [PATCH v4 1/4] syscalls: Restore address limit after a syscall

On Wed, Mar 22, 2017 at 1:44 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Wed, Mar 22, 2017 at 1:38 PM, Thomas Garnier <thgar...@google.com> wrote: >> This patch ensures a syscall does not return to user-mode with a kernel >> address limit. If that happened, a

[PATCH v4 1/4] syscalls: Restore address limit after a syscall

If the CONFIG_BUG_ON_DATA_CORRUPTION option is enabled, an incorrect state will result in a BUG_ON. The CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE option is also added so each architecture can optimize this change. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170322 --- arc

Re: [PATCH v4 1/4] syscalls: Restore address limit after a syscall

Okay well then people are fine with a BUG_ON approach. I will do a next iteration tailored to that. I will also try to add the static inline suggestion from Peter. On Wed, Mar 22, 2017 at 1:54 PM, H. Peter Anvin <h...@zytor.com> wrote: > On 03/22/17 13:49, Thomas Garnier wrote: >

Re: [PATCH v4 1/4] syscalls: Restore address limit after a syscall

On Thu, Mar 23, 2017 at 8:32 AM, Borislav Petkov <b...@alien8.de> wrote: > On Thu, Mar 23, 2017 at 08:14:44AM -0700, Thomas Garnier wrote: >> Okay well then people are fine with a BUG_ON approach. I will do a >> next iteration tailored to that. I will also try to add

Re: [PATCH] lkdtm: add bad USER_DS test

On Fri, Mar 24, 2017 at 1:14 AM, Heiko Carstens wrote: > On Thu, Mar 23, 2017 at 01:34:19PM -0700, Kees Cook wrote: >> This adds CORRUPT_USER_DS to check that the get_fs() test on syscall return >> still sees USER_DS during the new VERIFY_PRE_USERMODE_STATE checks. >>

<    1   2   3   4   5   6   7   8   9   >