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 Tue, Mar 21, 2017 at 12:20 PM, Linus Torvalds wrote: > > On Tue, Mar 21, 2017 at 11:16 AM, Thomas Garnier wrote: > > 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

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

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: [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: [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 in the middle of a lot

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: [PATCH tip v2] x86/mm: Correct fixmap header usage on adaptable MODULES_END

On Mon, Mar 20, 2017 at 6:52 PM, Wei Yang 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-bit pgtable >>header.

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 Tue, Mar 21, 2017 at 12:17 AM, Ingo Molnar wrote: > > * 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-bit pgtable >> header. Instead, it is added by def

[tip:x86/mm] x86/headers: Simplify asm/fixmap.h inclusion into asm/pgtable*.h

Commit-ID: ef37bc361442545a5be3c56c49a08c3153032127 Gitweb: http://git.kernel.org/tip/ef37bc361442545a5be3c56c49a08c3153032127 Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 21 Mar 2017 08:17:25 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue,

[tip:x86/mm] x86/headers: Simplify asm/fixmap.h inclusion into asm/pgtable*.h

Commit-ID: ef37bc361442545a5be3c56c49a08c3153032127 Gitweb: http://git.kernel.org/tip/ef37bc361442545a5be3c56c49a08c3153032127 Author: Thomas Garnier AuthorDate: Tue, 21 Mar 2017 08:17:25 +0100 Committer: Ingo Molnar CommitDate: Tue, 21 Mar 2017 08:21:17 +0100 x86/headers: Simplify

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

[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 --- arch/x86/include/asm

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: [PATCH tip] x86/mm: Correct fixmap header usage on adaptable MODULES_END

On Sun, Mar 19, 2017 at 6:14 PM, Wei Yang 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 wrote: >>> On Fri, Mar 17, 2017 at 10:50:34AM -0700, Thomas Garnier wrote: >>>>This patch remove fixma

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: [PATCH tip] x86/mm: Correct fixmap header usage on adaptable MODULES_END

On Sun, Mar 19, 2017 at 9:03 AM, Wei Yang 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. > > Hi, Thomas > > In this patch, it loo

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

Commit-ID: f991376e444aee8f5643a45703c1433bf7948940 Gitweb: http://git.kernel.org/tip/f991376e444aee8f5643a45703c1433bf7948940 Author: Thomas Garnier <thgar...@google.com> AuthorDate: Fri, 17 Mar 2017 10:50:34 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat,

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

Commit-ID: f991376e444aee8f5643a45703c1433bf7948940 Gitweb: http://git.kernel.org/tip/f991376e444aee8f5643a45703c1433bf7948940 Author: Thomas Garnier AuthorDate: Fri, 17 Mar 2017 10:50:34 -0700 Committer: Ingo Molnar CommitDate: Sat, 18 Mar 2017 09:48:00 +0100 x86/mm: Correct fixmap

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

[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 --- Based on tip:x86/mm --- arch/x86/include/asm/pgtable_64.h | 1 + arch/x86/kernel/module.c | 1 - arch/x86/mm/dump_pagetables.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

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

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 >

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

[tip:x86/mm] x86: Remap GDT tables in the fixmap section

Commit-ID: 69218e47994da614e7af600bf06887750ab6657a Gitweb: http://git.kernel.org/tip/69218e47994da614e7af600bf06887750ab6657a Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 14 Mar 2017 10:05:07 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu,

[tip:x86/mm] x86: Remap GDT tables in the fixmap section

Commit-ID: 69218e47994da614e7af600bf06887750ab6657a Gitweb: http://git.kernel.org/tip/69218e47994da614e7af600bf06887750ab6657a Author: Thomas Garnier AuthorDate: Tue, 14 Mar 2017 10:05:07 -0700 Committer: Ingo Molnar CommitDate: Thu, 16 Mar 2017 09:06:35 +0100 x86: Remap GDT tables

[tip:x86/mm] x86: Make the GDT remapping read-only on 64-bit

Commit-ID: 45fc8757d1d2128e342b4e7ef39adedf7752faac Gitweb: http://git.kernel.org/tip/45fc8757d1d2128e342b4e7ef39adedf7752faac Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 14 Mar 2017 10:05:08 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu,

[tip:x86/mm] x86: Make the GDT remapping read-only on 64-bit

Commit-ID: 45fc8757d1d2128e342b4e7ef39adedf7752faac Gitweb: http://git.kernel.org/tip/45fc8757d1d2128e342b4e7ef39adedf7752faac Author: Thomas Garnier AuthorDate: Tue, 14 Mar 2017 10:05:08 -0700 Committer: Ingo Molnar CommitDate: Thu, 16 Mar 2017 09:06:35 +0100 x86: Make the GDT

[tip:x86/mm] x86/mm: Adapt MODULES_END based on fixmap section size

Commit-ID: f06bdd4001c257792c54dce9427399f2896470af Gitweb: http://git.kernel.org/tip/f06bdd4001c257792c54dce9427399f2896470af Author: Thomas Garnier <thgar...@google.com> AuthorDate: Tue, 14 Mar 2017 10:05:06 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu,

[tip:x86/mm] x86/mm: Adapt MODULES_END based on fixmap section size

Commit-ID: f06bdd4001c257792c54dce9427399f2896470af Gitweb: http://git.kernel.org/tip/f06bdd4001c257792c54dce9427399f2896470af Author: Thomas Garnier AuthorDate: Tue, 14 Mar 2017 10:05:06 -0700 Committer: Ingo Molnar CommitDate: Thu, 16 Mar 2017 09:06:24 +0100 x86/mm: Adapt

[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 2/3] x86: Remap GDT tables in the Fixmap section

changes for Xen support. Signed-off-by: Thomas Garnier --- Based on next-20170308 --- arch/x86/entry/vdso/vma.c | 2 +- arch/x86/include/asm/desc.h | 58 --- arch/x86/include/asm/fixmap.h | 4 +++ arch/x86/include/asm/processor.h | 1

[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

[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 --- Based on next-20170308 --- arch/x86/include/asm/desc.h | 106

[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 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 --- Based on next-20170308 --- Documentation/x86/x86_64/mm.txt | 5 - arch/x86/include/asm/pgtable_64_types.h | 3 ++- arch/x86/kernel/module.c| 1

[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 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 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 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 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 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 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 1/4] syscalls: Restore address limit after a syscall

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

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

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 On Wed, Mar 8, 2017 at 12:35 AM, Bhupesh Sharma wrote: > On Wed, Mar 8, 2017 at 1:48 PM, Dave Young wrote: >> On 03/08/17 at 03:47pm, Baoquan He wrote: >>> EFI allocates runtime services regions top-down, starting

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 4/6] x86/kvm/vmx: Simplify segment_base()

> 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 > Cc: Jim Mattson > Cc: Radim Krčmář > Cc: Paolo Bonzini > Signed-off-by: Andy Lutomirski > --- &g

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

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 --- Based on next-20170213 Fixed fixmap dependencies on random configurations. --- Documentation/x86/x86_64/mm.txt | 5 - arch/x86/include/asm/pgtable_64_types.h | 3

[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 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 --- Based on next-20170213

[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 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 --- Based on next-20170213 --- arch/x86/include/asm/desc.h | 51

[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 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 --- Based on next-20170213 --- arch/x86/kvm/vmx.c | 30 -- 1 file changed, 20 insertions(+), 10

[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 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 --- Based on next-20170213 --- Documentation/x86/x86_64/mm.txt | 5 - arch/x86/include/asm/pgtable_64_types.h | 3 ++- 2 files changed, 6 insertions(+), 2 deletions

[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 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 --- Based on next-20170213 --- arch/x86/include/asm/desc.h | 51

[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 --- Based on next-20170213

[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

[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 --- Based on next-20170213 --- arch/x86/kvm/vmx.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletions

[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 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 --- Based on next-20170213 --- arch/x86/include/asm/fixmap.h | 8 arch/x86/include/asm/pgtable_64_types.h | 3 --- arch/x86/kernel/module.c| 1

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

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

On Thu, Feb 9, 2017 at 3:05 PM, Andy Lutomirski wrote: > On Thu, Feb 9, 2017 at 11:31 AM, Kees Cook wrote: >> On Thu, Feb 9, 2017 at 10:33 AM, Thomas Garnier wrote: >>> This patch prevents a syscall to modify the address limit of the >>> caller. The address limit is

[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

[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

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

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

unsigned long i, count = oo_objects(s->oo); > > + /* Bailout if already initialised */ > + if (s->random_seq) > + return 0; > + > err = cache_random_seq_create(s, count, GFP_KERNEL); > if (err) { > pr_err("SLUB: U

[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 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 --- Based on next-20170125 --- arch/x86/include/asm/desc.h | 46

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

[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 --- Based on next-20170125 --- arch/x86/include/asm/fixmap.h | 8 arch/x86/include/asm/pgtable_64_types.h | 3 --- arch/x86/kernel/module.c| 1

[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 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 --- Based on next-20170125

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 v1 2/3] x86: Remap GDT tables in the Fixmap section

Garnier wrote: > On Fri, Jan 20, 2017 at 4:57 PM, Andy Lutomirski wrote: >> On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: >>> Each processor holds a GDT in its per-cpu structure. The sgdt >>> instruction gives the base address of the current GDT. This addres

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

On Fri, Jan 20, 2017 at 4:57 PM, Andy Lutomirski wrote: > On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier 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 >> be used t

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 3/3] x86: Make the GDT remapping read-only on 64 bit

On Fri, Jan 20, 2017 at 5:06 PM, Andy Lutomirski wrote: > On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: >> This patch makes the GDT remapped pages read-only to prevent corruption. >> This change is done only on 64 bit. >> >> The native_load_tr_desc functi

[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

[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 --- Based on next-20170119 --- arch/x86/include/asm/fixmap.h | 8 arch/x86/include/asm/pgtable_64_types.h | 3 --- 2 files changed, 8 insertions(+), 3

[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 --- Based on next-20170119 --- arch/x86/Kconfig | 1 + arch/x86/include/asm/fixmap.h| 4 arch/x86/include/asm

[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 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 --- Based on next-20170119 --- arch/x86/include/asm/desc.h | 44 +++- arch/x86/include/asm/processor.h | 1 + arch/x86/kernel

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 Tue, Jan 10, 2017 at 2:27 AM, Ingo Molnar wrote: > > * Thomas Garnier 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 will just >> issue a #GP given a bad selector: &

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 Fri, Jan 6, 2017 at 11:35 PM, Ingo Molnar wrote: > > * Thomas Garnier 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 my thoughts on how >> > this should work: >&

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 Fri, Jan 6, 2017 at 1:59 PM, Andy Lutomirski wrote: > On Fri, Jan 6, 2017 at 10:03 AM, Thomas Garnier wrote: >> On Thu, Jan 5, 2017 at 10:49 PM, Ingo Molnar wrote: >>> >>> * Thomas Garnier wrote: >>> >>>> >> Not sure I fully understoo

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: [PATCH] Fix SLAB freelist randomization duplicate entries

On Fri, Jan 6, 2017 at 12:42 PM, Andrew Morton wrote: > On Fri, 6 Jan 2017 09:58:48 -0800 Thomas Garnier wrote: > >> On Thu, Jan 5, 2017 at 4:35 PM, Andrew Morton >> wrote: >> > On Tue, 3 Jan 2017 10:19:08 -0800 Thomas Garnier >> > wrote: >> >

<    1   2   3   4   5   6   7   8   9   >