Re: [PATCH tip] x86/mm: Correct fixmap header usage on adaptable MODULES_END

On Sun, Mar 19, 2017 at 9:03 AM, Wei Yang <richard.weiy...@gmail.com> wrote: > On Fri, Mar 17, 2017 at 10:50:34AM -0700, Thomas Garnier wrote: >>This patch remove fixmap header usage on non-x86 code that was >>introduced by the adaptable MODULE_END change. > > H

Re: [tip:x86/mm 1/3] fs/proc/kcore.c:626:2: note: in expansion of macro 'if'

Checked and it is correctly fixed by my suggested update on the patch thread. On Thu, Mar 16, 2017 at 9:41 AM, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm > head: 45fc8757d1d2128e342b4e7ef39adedf7752faac >

[PATCH tip] x86/mm: Correct fixmap header usage on adaptable MODULES_END

This patch remove fixmap header usage on non-x86 code that was introduced by the adaptable MODULE_END change. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on tip:x86/mm --- arch/x86/include/asm/pgtable_64.h | 1 + arch/x86/kernel/module.c | 1 - arch/

Re: [x86] 45fc8757d1: BUG:unable_to_handle_kernel

I tried multiple things to repro this crash without success: - Used the config on my existing qemu setup (boot fine) - Add most of the command-line (boot fine) - Try to run the script on a dedicated machine and it seems it is really tailored for your setup. I had errors with usernames and cpio

[PATCH tip v2] x86/mm: Correct fixmap header usage on adaptable MODULES_END

This patch removes fixmap headers on non-x86 code introduced by the adaptable MODULE_END change. It is also removed in the 32-bit pgtable header. Instead, it is added by default in the pgtable generic header for both architectures. Signed-off-by: Thomas Garnier <thgar...@google.com> ---

Re: [PATCH tip] x86/mm: Correct fixmap header usage on adaptable MODULES_END

On Sun, Mar 19, 2017 at 6:14 PM, Wei Yang <richard.weiy...@gmail.com> wrote: > On Sun, Mar 19, 2017 at 09:25:00AM -0700, Thomas Garnier wrote: >>On Sun, Mar 19, 2017 at 9:03 AM, Wei Yang <richard.weiy...@gmail.com> wrote: >>> On Fri, Mar 17, 2017 at 10:50:34

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

On Tue, Mar 21, 2017 at 4:51 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Tue, Mar 21, 2017 at 3:32 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Tue, Mar 21, 2017 at 2:11 PM, Linus Torvalds >> <torva...@linux-foundation.org> wrote: >>> On Tu

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

and the WP test page, the error does not reproduce. I am still looking at the exact distance between repro and no-repro as well as the exact root cause. On Tue, Mar 21, 2017 at 12:23 PM, Thomas Garnier <thgar...@google.com> wrote: > On Tue, Mar 21, 2017 at 12:20 PM, Linus Torvalds > <

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

On Tue, Mar 21, 2017 at 9:27 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Tue, Mar 21, 2017 at 5:41 PM, Thomas Garnier <thgar...@google.com> wrote: >> On Tue, Mar 21, 2017 at 4:51 PM, Andy Lutomirski <l...@kernel.org> wrote: >>> On Tue, Mar 21,

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

On Tue, Apr 4, 2017 at 11:27 AM, H. Peter Anvin <h...@zytor.com> wrote: > On 04/04/17 10:47, Thomas Garnier wrote: >> diff --git a/arch/x86/include/asm/pgtable_64_types.h >> b/arch/x86/include/asm/pgtable_64_types.h >> index 516593e66bd6..12fa851c7fa8 100644 &g

[PATCH v7 4/4] arm64/syscalls: Architecture specific pre-usermode check

the kernel on an explicit check. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170410 --- arch/arm64/Kconfig| 1 + arch/arm64/kernel/entry.S | 13 + 2 files changed, 14 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig

[PATCH v7 4/4] arm64/syscalls: Architecture specific pre-usermode check

the kernel on an explicit check. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170410 --- arch/arm64/Kconfig| 1 + arch/arm64/kernel/entry.S | 13 + 2 files changed, 14 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig

[PATCH v7 2/4] x86/syscalls: Architecture specific pre-usermode check

on 32-bit and on the 64-bit syscall slowpath. For the 64-bit syscall fast path, an assembly address limit check redirects to the slow path if the address limit is different. The TASK_SIZE_MAX define is moved to the pgtable_64_types header so it can be used in assembly code. Signed-off-by: Thomas

Re: [PATCH v7 4/4] arm64/syscalls: Architecture specific pre-usermode check

On Mon, Apr 10, 2017 at 1:06 PM, Thomas Garnier <thgar...@google.com> wrote: > Disable the generic pre-usermode check in favor of an optimized > implementation. This patch adds specific checks on user-mode return path > to make it faster and smaller. > > The address lim

[PATCH v7 4/4] arm64/syscalls: Architecture specific pre-usermode check

the kernel on an explicit check. Signed-off-by: Thomas Garnier <thgar...@google.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> --- Based on next-20170410 Fix comments from Catalin and add review-by in the message. --- arch/arm64/Kconfig| 1 + arch/arm64/kernel/

[PATCH v7 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> Tested-by: Kees Cook <keesc...@chromium.org> --- Based on next-20170410 --- arch/s390/Kconfig| 1 + include/linux/sys

[PATCH v7 3/4] arm/syscalls: Architecture specific pre-usermode check

. If the address limit was changed, a generic handler is called to stop the kernel on an explicit check. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170410 --- arch/arm/Kconfig | 1 + arch/arm/kernel/entry-common.S | 10 +- 2 files changed, 10 inse

[PATCH v6 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. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170404 --- arch/x86/Kconfig| 1 + arch/x86/entry/common.c | 3 +++ arch/x86/entry/entr

[PATCH v6 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. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170404 --- arch/arm64/Kconfig| 1 + arch/arm64/kernel/entry.S | 15 +++ 2 files changed, 16 insertions(+)

[PATCH v6 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> Tested-by: Kees Cook <keesc...@chromium.org> --- Based on next-20170404 --- arch/s390/Kconfig| 1 + include/linux/sys

[PATCH v6 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. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170404 --- arch/arm/Kconfig | 1 + arch/arm/kernel/entry-common.S | 16 +++- 2 files changed, 16 inse

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

On Wed, Apr 5, 2017 at 10:49 AM, Catalin Marinas <catalin.mari...@arm.com> wrote: > On Wed, Apr 05, 2017 at 07:36:17AM -0700, Thomas Garnier wrote: >> On Wed, Apr 5, 2017 at 7:22 AM, Catalin Marinas <catalin.mari...@arm.com> >> wrote: >> > On Tue, Apr 04, 2017

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

On Wed, Apr 5, 2017 at 7:22 AM, Catalin Marinas <catalin.mari...@arm.com> wrote: > On Tue, Apr 04, 2017 at 10:47:27AM -0700, Thomas Garnier wrote: >> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S >> index 43512d4d7df2..6d598e7051c3 100644 >> ---

Re: KASLR causes intermittent boot failures on some systems

On Wed, Apr 19, 2017 at 7:34 AM, Dan Williams wrote: > Does the randomization ever cross a pgd boundary? Yes, it can cross a pgd boundary. The original physical memory mapping might as well but you would need almost 550Gb of memory. > > These crashes look very similar

Re: [PATCH 2/2] x86/mm/KASLR: Correct the upper boundary of KALSR mm regions if adjacent to EFI

Thanks for the change. Acked-by: Thomas Garnier <thgar...@google.com> On Wed, Mar 8, 2017 at 12:35 AM, Bhupesh Sharma <bhsha...@redhat.com> wrote: > On Wed, Mar 8, 2017 at 1:48 PM, Dave Young <dyo...@redhat.com> wrote: >> On 03/08/17 at 03:47pm, Baoquan He wrote

[PATCH v1 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-20170308 --- arch/x86/Kconfig | 1 + arch/x86/entry/common.c | 3 +++ arch/x86/entry/entry_64.S | 6 ++ 3 files changed, 10 insertions(+) diff --git a/arch/x86/Kconfig

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

the verify_pre_usermode_state function is called. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170308 --- include/linux/syscalls.h | 19 +++ init/Kconfig | 16 kernel/sys.c | 11 +++ 3 files changed, 46 insertions(+) diff

[PATCH v1 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-20170308 --- arch/arm64/Kconfig| 1 + arch/arm64/kernel/entry.S | 2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index

[PATCH v1 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-20170308 --- arch/arm/Kconfig | 1 + arch/arm/kernel/entry-common.S | 5 + 2 files changed, 6 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index

[PATCH v7 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-20170308 --- Documentation/x86/x86_64/mm.txt | 5 - arch/x86/include/asm/pgtable_64_types.h | 3 ++- arch/x86/kernel/mo

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

com> for testing and recommending changes for Xen support. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170308 --- arch/x86/entry/vdso/vma.c | 2 +- arch/x86/include/asm/desc.h | 58 --- arch/x86/include/

[PATCH v7 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-20170308 --- arch/x86/include/asm/desc.h

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

On Thu, Mar 23, 2017 at 1:15 PM, Kees Cook <keesc...@chromium.org> wrote: > On Thu, Mar 23, 2017 at 10:25 AM, 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 proc

Re: [PATCH tip v2] x86/mm: Correct fixmap header usage on adaptable MODULES_END

On Tue, Mar 21, 2017 at 12:17 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Thomas Garnier <thgar...@google.com> wrote: > >> This patch removes fixmap headers on non-x86 code introduced by the >> adaptable MODULE_END change. It is also removed in the

Re: [PATCH tip v2] x86/mm: Correct fixmap header usage on adaptable MODULES_END

On Mon, Mar 20, 2017 at 6:52 PM, Wei Yang <richard.weiy...@gmail.com> wrote: > On Mon, Mar 20, 2017 at 12:40:24PM -0700, Thomas Garnier wrote: >>This patch removes fixmap headers on non-x86 code introduced by the >>adaptable MODULE_END change. It is also removed in the 32

Re: [x86] 45fc8757d1: BUG:unable_to_handle_kernel

On Sun, Mar 19, 2017 at 6:40 PM, Ye Xiaolong wrote: > Could you paste the error log? > I suspect it was caused by job-script saved as dos format, you may try > `dos2unix job-script` before "lkp qemu" to see whether it works. > You were right, I had some strange '\n' error

Re: KASLR causes intermittent boot failures on some systems

CCing Kees for information. On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote: > Hi, > > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory > regions") causes some of my systems with persistent memory (whether real > or emulated) to fail to boot with a

Re: KASLR causes intermittent boot failures on some systems

On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He wrote: > Yeah, according to my debugging tracking, it goes as Dan said. And the > is_ram is REGION_DISJOINT. And till arch_add_memory, the parameters > passed to arch_add_memory are "arch_add_memory, align_start:0x100, >

[PATCH v3 4/4] arm64/syscalls: Move address limit check in loop

. Fixes: cf7de27ab351 ("arm64/syscalls: Check address limit on user-mode return") Reported-by: Leonard Crestez <leonard.cres...@nxp.com> Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/arm64/kernel/signal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions

[PATCH v3 3/4] arm/syscalls: Optimize address limit check

using a SIGKILL signal. For example the lkdtm address limit check does not work because the signal to kill the process will reset the user-mode address limit. Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/arm/kernel/entry-common.S | 11 +++ arch/arm/kernel/signal.c

[PATCH v3 2/4] Revert "arm/syscalls: Check address limit on user-mode return"

res...@nxp.com> Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/arm/include/asm/thread_info.h | 15 ++- arch/arm/include/asm/uaccess.h | 2 -- arch/arm/kernel/entry-common.S | 9 ++--- arch/arm/kernel/signal.c | 5 - 4 files changed, 8 inser

[PATCH v3 1/4] syscalls: Use CHECK_DATA_CORRUPTION for addr_limit_user_check

Use CHECK_DATA_CORRUPTION instead of BUG_ON to provide more flexibility on address limit failures. By default, send a SIGKILL signal to kill the current process preventing exploitation of a bad address limit. Make the TIF_FSCHECK flag optional so ARM can use this function. Signed-off-by: Thomas

Re: [PATCH v10 1/3] x86/syscalls: Check address limit on user-mode return

On Thu, Jul 6, 2017 at 1:48 PM, Thomas Gleixner <t...@linutronix.de> wrote: > On Thu, 6 Jul 2017, Thomas Garnier wrote: >> On Wed, Jun 28, 2017 at 10:52 AM, Kees Cook <keesc...@chromium.org> wrote: >> > >> > On Tue, Jun 20, 2017 at 1:24 PM, Kees Cook <k

Re: [PATCH v10 1/3] x86/syscalls: Check address limit on user-mode return

On Wed, Jun 28, 2017 at 10:52 AM, Kees Cook <keesc...@chromium.org> wrote: > > On Tue, Jun 20, 2017 at 1:24 PM, Kees Cook <keesc...@chromium.org> wrote: > > On Wed, Jun 14, 2017 at 6:12 PM, Thomas Garnier <thgar...@google.com> wrote: > >> Ensure the addr

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Tue, Jul 18, 2017 at 7:36 AM, Leonard Crestez <leonard.cres...@nxp.com> wrote: > On Wed, 2017-06-14 at 18:12 -0700, Thomas Garnier wrote: >> Ensure the address limit is a user-mode segment before returning to >> user-mode. Otherwise a process can corrupt kernel-mode

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez <leonard.cres...@nxp.com> wrote: > > On Tue, 2017-07-18 at 09:04 -0700, Thomas Garnier wrote: > > On Tue, Jul 18, 2017 at 7:36 AM, Leonard Crestez <leonard.cres...@nxp.com> > > wrote: > > > > > > O

Re: [kernel-hardening] Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Wed, Jul 19, 2017 at 10:06 AM, Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > On Wed, Jul 19, 2017 at 05:58:20PM +0300, Leonard Crestez wrote: >> On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote: >> > On Tue, Jul 18, 2017 at 10:18 AM, Leonard Cre

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Wed, Jul 19, 2017 at 7:58 AM, Leonard Crestez <leonard.cres...@nxp.com> wrote: > On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote: >> On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez <leonard.cres...@nxp.com> >> wrote: >> > On Tue, 2017-07-18

[PATCH 3/3] arm64/syscalls: Move address limit check in loop

. Fixes: cf7de27ab351 ("arm64/syscalls: Check address limit on user-mode return") Reported-by: Leonard Crestez <leonard.cres...@nxp.com> Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/arm64/kernel/signal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions

[PATCH 1/3] arm/syscalls: Move address limit check in loop

y: Leonard Crestez <leonard.cres...@nxp.com> Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/arm/kernel/signal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c index 3a48b54c6405..f4574287d14b 100644

[PATCH 2/3] arm/syscalls: Optimize work flags assembly check

Remove the double branch and use tsteq instead. Suggested-by: Russell King <li...@armlinux.org.uk> Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/arm/kernel/entry-common.S | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/arm/kernel/entr

Re: [PATCH 1/3] arm/syscalls: Move address limit check in loop

On Tue, Jul 25, 2017 at 3:38 AM, Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > On Tue, Jul 25, 2017 at 01:28:01PM +0300, Leonard Crestez wrote: >> On Mon, 2017-07-24 at 10:07 -0700, Thomas Garnier wrote: >> > On Wed, Jul 19, 2017 at 10:58 AM, Thomas Garn

Re: [PATCH 1/3] arm/syscalls: Move address limit check in loop

On Wed, Jul 19, 2017 at 10:58 AM, Thomas Garnier <thgar...@google.com> wrote: > The work pending loop can call set_fs after addr_limit_user_check > removed the _TIF_FSCHECK flag. To prevent the infinite loop, move > the addr_limit_user_check call at the beginning of the

Re: [PATCH 1/3] arm/syscalls: Move address limit check in loop

On Wed, Jul 26, 2017 at 5:02 AM, Will Deacon <will.dea...@arm.com> wrote: > On Tue, Jul 25, 2017 at 01:01:17PM -0700, Thomas Garnier wrote: >> On Tue, Jul 25, 2017 at 3:38 AM, Russell King - ARM Linux >> <li...@armlinux.org.uk> wrote: >> > On Tue, Jul 25, 2017

[PATCH v2 3/3] arm64/syscalls: Move address limit check in loop

. Fixes: cf7de27ab351 ("arm64/syscalls: Check address limit on user-mode return") Reported-by: Leonard Crestez <leonard.cres...@nxp.com> Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/arm64/kernel/signal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions

[PATCH v2 1/3] Revert "arm/syscalls: Check address limit on user-mode return"

res...@nxp.com> Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/arm/include/asm/thread_info.h | 15 ++- arch/arm/include/asm/uaccess.h | 2 -- arch/arm/kernel/entry-common.S | 9 ++--- arch/arm/kernel/signal.c | 5 - 4 files changed, 8 inser

[PATCH v2 2/3] arm/syscalls: Optimize address limit check

the signal to kill the process will reset the user-mode address limit. Signed-off-by: Thomas Garnier <thgar...@google.com> --- arch/arm/kernel/entry-common.S | 11 +++ arch/arm/kernel/signal.c | 5 + 2 files changed, 16 insertions(+) diff --git a/arch/arm/kernel/entry-comm

Re: [PATCH 1/3] arm/syscalls: Move address limit check in loop

On Wed, Jul 26, 2017 at 11:25 AM, Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > On Wed, Jul 26, 2017 at 07:20:22AM -0700, Thomas Garnier wrote: >> On Wed, Jul 26, 2017 at 5:02 AM, Will Deacon <will.dea...@arm.com> wrote: >> > I looked to see what you've d

Re: [kernel-hardening] Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Wed, Jul 19, 2017 at 11:35 AM, Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > On Wed, Jul 19, 2017 at 10:20:35AM -0700, Thomas Garnier wrote: >> On Wed, Jul 19, 2017 at 10:06 AM, Russell King - ARM Linux >> <li...@armlinux.org.uk> wrote: >> > On W

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

On Wed, Apr 26, 2017 at 1:12 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Thomas Garnier <thgar...@google.com> wrote: > >> >> +#ifdef CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE >> >> +/* >> >> + * This function is called whe

Re: [PATCH 1/2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

On Wed, Apr 26, 2017 at 3:43 AM, Baoquan He wrote: > > This bug will cause SGI uv 100 boot failure since SGI uv 100 can only > use efi old_map because of hardware. On rhel it failed all SGI uv series > since we haven't back ported fix for SGI uv 200/300. > > On 04/26/17 at

[PATCH v8 4/4] arm64/syscalls: Optimize address limit check

Disable the generic address limit check in favor of an architecture specific optimized implementation. The address limit is checked on each syscall return path to user-mode. If it was changed, a generic handler is called to stop the kernel on an explicit check. Signed-off-by: Thomas Garnier

[PATCH v8 1/4] syscalls: Verify address limit before returning to user-mode

://bugs.chromium.org/p/project-zero/issues/detail?id=990 Signed-off-by: Thomas Garnier <thgar...@google.com> Tested-by: Kees Cook <keesc...@chromium.org> --- Based on next-20170426 --- arch/s390/Kconfig| 1 + include/linux/syscalls.h | 27 ++-

[PATCH v8 3/4] arm/syscalls: Optimize address limit check

the kernel on an explicit check. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170426 --- arch/arm/Kconfig | 1 + arch/arm/kernel/entry-common.S | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/K

[PATCH v8 2/4] x86/syscalls: Optimize address limit check

syscall fast path, an assembly address limit check redirects to the slow path if the address limit is different. The TASK_SIZE_MAX definition is moved to the pgtable_64_types header so it can be used in assembly code. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20

Re: [PATCH v8 1/4] syscalls: Verify address limit before returning to user-mode

On Wed, Apr 26, 2017 at 11:49 PM, Ingo Molnar <mi...@kernel.org> wrote: > > * Thomas Garnier <thgar...@google.com> wrote: > >> + >> +/* >> + * Called before coming back to user-mode. Returning to user-mode with an >> + * address limit different than USE

[PATCH v8 1/4] syscalls: Verify address limit before returning to user-mode

://bugs.chromium.org/p/project-zero/issues/detail?id=990 Signed-off-by: Thomas Garnier <thgar...@google.com> Tested-by: Kees Cook <keesc...@chromium.org> --- Based on next-20170426 --- arch/s390/Kconfig| 1 + include/linux/syscalls.h | 27 ++-

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

On Mon, Apr 24, 2017 at 11:23 PM, Ingo Molnar <mi...@kernel.org> wrote: > > * Kees Cook <keesc...@chromium.org> wrote: > >> On Mon, Apr 10, 2017 at 9:44 AM, Thomas Garnier <thgar...@google.com> wrote: >> > This patch ensures a syscall does not return to

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

On Mon, Apr 24, 2017 at 11:33 PM, Ingo Molnar <mi...@kernel.org> wrote: > > * 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 process can corrupt

[PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

is enabled by default on s390 because a similar feature already exists. [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=990 Signed-off-by: Thomas Garnier <thgar...@google.com> Tested-by: Kees Cook <keesc...@chromium.org> --- Based on next-20170426 --- arch/s390/Kconfig

[PATCH v9 2/4] x86/syscalls: Optimize address limit check

syscall fast path, an assembly address limit check redirects to the slow path if the address limit is different. The TASK_SIZE_MAX definition is moved to the pgtable_64_types header so it can be used in assembly code. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20

[PATCH v9 4/4] arm64/syscalls: Optimize address limit check

Disable the generic address limit check in favor of an architecture specific optimized implementation. The address limit is checked on each syscall return path to user-mode. If it was changed, a generic handler is called to stop the kernel on an explicit check. Signed-off-by: Thomas Garnier

[PATCH v9 3/4] arm/syscalls: Optimize address limit check

the kernel on an explicit check. Signed-off-by: Thomas Garnier <thgar...@google.com> --- Based on next-20170426 --- arch/arm/Kconfig | 1 + arch/arm/kernel/entry-common.S | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/K

Re: [PATCH v2 2/3] arm/syscalls: Optimize address limit check

On Wed, Jul 26, 2017 at 10:00 AM, Thomas Garnier <thgar...@google.com> wrote: > Disable the generic address limit check in favor of an architecture > specific optimized implementation. The generic implementation using > pending work flags did not work well with ARM and a

Re: [PATCH v2 2/3] arm/syscalls: Optimize address limit check

On Mon, Aug 7, 2017 at 10:55 AM, Russell King - ARM Linux wrote: > > It's better in so far as it avoids the problems previously highlighted. > > However, it depends how efficient we want these paths to be - the > difference between your assembly and the assembly I've

Re: [PATCH v2 2/3] arm/syscalls: Optimize address limit check

On Mon, Aug 7, 2017 at 10:35 AM, Kees Cook <keesc...@chromium.org> wrote: > On Wed, Jul 26, 2017 at 10:00 AM, Thomas Garnier <thgar...@google.com> wrote: >> Disable the generic address limit check in favor of an architecture >> specific optimized implementation. The g

Re: [PATCH v3 3/4] arm/syscalls: Optimize address limit check

On Mon, Aug 14, 2017 at 2:37 PM, Thomas Garnier <thgar...@google.com> wrote: > Disable the generic address limit check in favor of an architecture > specific optimized implementation. The generic implementation using > pending work flags did not work well with ARM and a

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 9, 2017 at 7:29 AM, Thomas Garnier <thgar...@google.com> wrote: > > On Tue, May 9, 2017 at 4:10 AM, Greg KH <g...@kroah.com> wrote: > > On Tue, May 09, 2017 at 08:56:19AM +0200, Ingo Molnar wrote: > >> > >> * Kees Cook <keesc...@chromium

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Tue, May 9, 2017 at 4:10 AM, Greg KH wrote: > On Tue, May 09, 2017 at 08:56:19AM +0200, Ingo Molnar wrote: >> >> * Kees Cook wrote: >> >> > > There's the option of using GCC plugins now that the infrastructure was >> > > upstreamed from grsecurity. It

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 11:58 PM, Ingo Molnar <mi...@kernel.org> wrote: > > * Linus Torvalds <torva...@linux-foundation.org> wrote: > >> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier <thgar...@google.com> wrote: >> > >> > Ingo: Do you want

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

On Tue, Jun 20, 2017 at 1:18 PM, Kees Cook <keesc...@chromium.org> wrote: > On Wed, Jun 14, 2017 at 6:12 PM, Thomas Garnier <thgar...@google.com> wrote: >> Ensure the address limit is a user-mode segment before returning to >> user-mode. Otherwise a process can

Re: [PATCH v10 3/3] arm64/syscalls: Check address limit on user-mode return

On Wed, Jun 21, 2017 at 1:16 AM, Catalin Marinas <catalin.mari...@arm.com> wrote: > On Wed, Jun 14, 2017 at 06:12:03PM -0700, Thomas Garnier wrote: >> Ensure the address limit is a user-mode segment before returning to >> user-mode. Otherwise a process can corrupt kernel-mode

Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system

On Mon, May 22, 2017 at 9:30 AM, Mike Travis <mike.tra...@hpe.com> wrote: > > > On 5/21/2017 4:17 PM, Baoquan He wrote: > > Sorry, forget 'To' Mike, Russ and Frank > > On 05/22/17 at 07:14am, Baoquan He wrote: > > On 05/21/17 at 01:38pm, Thomas Garnier wrote: &g

Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system

Do it now. > > Signed-off-by: Baoquan He <b...@redhat.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: x...@kernel.org > Cc: Thomas Garnier <thgar...@google.co

[PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

-by: Thomas Garnier <thgar...@google.com> --- v10 redesigns the change to use work flags on set_fs as recommended by Linus and agreed by others. Based on next-20170609 --- arch/arm/include/asm/thread_info.h | 15 +-- arch/arm/include/asm/uaccess.h | 2 ++ arch/arm/kernel/entry-co

[PATCH v10 1/3] x86/syscalls: Check address limit on user-mode return

if needed. The addr_limit_user_check function is added as a cross-architecture function to check the address limit. [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=990 Signed-off-by: Thomas Garnier <thgar...@google.com> --- v10 redesigns the change to use work flags on

[PATCH v10 3/3] arm64/syscalls: Check address limit on user-mode return

if needed. [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=990 Signed-off-by: Thomas Garnier <thgar...@google.com> --- v10 redesigns the change to use work flags on set_fs as recommended by Linus and agreed by others. Based on next-20170609 --- arch/arm64/include/asm/thread_

Re: [PATCH] x86/mm: Fix incorrect for loop count calculation in sync_global_pgds

hy we saw empty PGD. Make a lot of sense. Thanks a lot for investigating this issue! Acked-by: Thomas Garnier <thgar...@google.com> > > Fix it in this patch. > > The back trace is pasted as below: > > [9.988867] IP: memcpy_erms+0x6/0x10 > [9.988868] PGD 0 > [

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

.@redhat.com> > Signed-off-by: Dave Young <dyo...@redhat.com> > Cc: Matt Fleming <m...@codeblueprint.co.uk> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: "

Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

On Fri, May 5, 2017 at 1:23 AM, Daniel Gruss <daniel.gr...@iaik.tugraz.at> wrote: > > On 04.05.2017 17:28, Thomas Garnier wrote: >> >> Please read the documentation on submitting patches [1] and coding style [2]. > > > I will have a closer look at that.

Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

On Mon, May 8, 2017 at 6:53 AM, Daniel Gruss wrote: > On 06.05.2017 10:38, Daniel Gruss wrote: >> >> On 2017-05-06 06:02, David Gens wrote: >>> >>> Assuming that their patch indeed leaks per-cpu addresses.. it might not >>> necessarily >>> be required to change it. >>

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Mon, May 8, 2017 at 8:26 AM, Kees Cook wrote: > On Mon, May 8, 2017 at 8:22 AM, Daniel Micay wrote: >> On Mon, 2017-05-08 at 09:52 +0200, Ingo Molnar wrote: >>> >>> ... it's just not usable in that form for a regular maintenance flow. >>> >>> So

Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, Apr 28, 2017 at 8:32 AM, Thomas Garnier <thgar...@google.com> wrote: > Ensure that a syscall does not return to user-mode with a kernel address > limit. If that happens, a process can corrupt kernel-mode memory and > elevate privileges [1]. > > The CONFIG_ADDR_LIMIT_

Re: [PATCH v3] x86/mm: Fix incorrect for loop count calculation in sync_global_pgds

8 >> [9.988962] RIP: memcpy_erms+0x6/0x10 RSP: ba92c783f9b8 >> [9.988962] CR2: 9387bfff >> [9.989022] ---[ end trace fe34c0fc0fe685ab ]--- >> [9.998690] Kernel panic - not syncing: Fatal exception >> [ 10.004708] Kernel Offset: 0x11000

Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

On Thu, May 4, 2017 at 3:02 AM, Daniel Gruss wrote: > After several recent works [1,2,3] KASLR on x86_64 was basically considered > dead by many researchers. We have been working on an efficient but effective > fix for this problem and found that not mapping the

Re: [PATCH] ARM: uaccess: Add missing include for set_thread_flag

r of a different approach on linux-next (see commit 2404269bc4e77a67875c8db6667be34c9913c96e). Let me know if this commit resolve the issue and thanks for reaching out. > > Regards, > Jonathan > > On 20 September 2017 at 00:32, Thomas Garnier <thgar...@google.com> wrote: > > On T

Re: [PATCH] ARM: uaccess: Add missing include for set_thread_flag

On Tue, Sep 19, 2017 at 4:50 AM, Jonathan Liu wrote: > Fixes "implicit declaration of function" compile error for out-of-tree > kernel modules including asm/uaccess.h. I failed to reproduce this issue by creating an out of tree module with a separate file (with only uaccess.h).

Re: module: use relative references for __ksymtab entries

ood idea, I assume we may still get relocations given the compiler is pretty bad at optimizing (_ptr - .) but I might be wrong. Anyway, the size decrease is great and we can ignore these relocations if need be. Thanks. >> >> Cc: Jessica Yu <j...@kernel.org> >> Cc: Arnd Bergman

Re: [PATCH v3 3/4] arm/syscalls: Optimize address limit check

On Tue, Aug 22, 2017 at 9:42 AM, Thomas Garnier <thgar...@google.com> wrote: > On Mon, Aug 14, 2017 at 2:37 PM, Thomas Garnier <thgar...@google.com> wrote: >> Disable the generic address limit check in favor of an architecture >> specific optimized implementation. The g

[PATCH v4 16/27] compiler: Option to add PROVIDE_HIDDEN replacement for weak symbols

Provide an option to have a PROVIDE_HIDDEN (linker script) entry for each weak symbol. This option solves an error in x86_64 where the linker optimizes PIE generated code to be non-PIE because --emit-relocs was used instead of -pie (to reduce dynamic relocations). Signed-off-by: Thomas Garnier

<    1   2   3   4   5   6   7   8   9   >