and the
global variable stack cookie is used. If a specific stack mode was
selected (regular or strong) and the compiler does not support selecting
the segment register, an error is emitted.
Signed-off-by: Thomas Garnier
---
arch/x86/Kconfig | 12
arch/x86
Adapt module loading to support PIE relocations. Generate dynamic GOT if
a symbol requires it but no entry exists in the kernel GOT.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86
randomization range.
Signed-off-by: Thomas Garnier
---
Documentation/x86/x86_64/mm.txt | 3 +++
arch/x86/Kconfig| 4
arch/x86/include/asm/pgtable_64_types.h | 6 ++
arch/x86/kernel/head64.c| 5 -
arch/x86/mm/dump_pagetables.c | 3
5-bytes as before.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86/include/asm/ftrace.h | 4 --
arch/x86/include/asm/sections.h | 4 ++
arch/x86/kernel/ftrace.c| 42
Change the relocation tool to correctly handle relocations generated by
-fPIE option:
- Add relocation for each entry of the .got section given the linker does not
generate R_X86_64_GLOB_DAT on a simple link.
- Ignore R_X86_64_GOTPCREL.
Signed-off-by: Thomas Garnier
---
arch/x86/tools
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
Acked-by: Pavel Machek
---
arch/x86/power
.
Signed-off-by: Thomas Garnier
---
arch/x86/include/asm/processor.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index e28add6b791f..7ae9fb91f7b5 100644
--- a/arch/x86/include/asm/processor.h
+++ b
Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86/kernel/Makefile | 6 ++
arch/x86/kernel/head64.c | 3 +++
2 files changed, 9 insertions(+)
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel
Change assembly to use the new _ASM_MOVABS macro instead of _ASM_MOV for
the assembly to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86/include/asm/pm-trace.h | 2
.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86/kernel/head_64.S | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/head_64.S b/arch
Replace the %c constraint with %P. The %c is incompatible with PIE
because it implies an immediate value whereas %P reference a symbol.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch
Replace the %c constraint with %P. The %c is incompatible with PIE
because it implies an immediate value whereas %P reference a symbol.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86/crypto/aes-x86_64-asm_64.S
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86/kernel/relocate_kernel_64.S
Add a new _ASM_MOVABS macro to fetch a symbol address. It will be used
to replace "_ASM_MOV $, %dst" code construct that are not compatible
with PIE.
Signed-off-by: Thomas Garnier
---
arch/x86/include/asm/asm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/a
Thanks Baoquan!
Reviewed-by: Thomas Garnier
On Wed, Aug 29, 2018 at 4:49 AM Kirill A. Shutemov wrote:
>
> On Wed, Aug 29, 2018 at 10:17:53AM +0800, Baoquan He wrote:
> > In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the
> > initial size of the dir
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
Signed-off-by: Greg Thelen
---
Based on next-20
ache_create() would reject invalid
> flags and fail and if memcg_create_kmem_cache() would mask out the invalid
> flags using SLAB_FLAGS_PERMITTED or so.
Okay, I think for SLAB we can allow everything except the two flags
mentioned here.
Should I deny certain flags for SLUB? I can allow everything fo
ation 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_SLAB &
>> CFLGS
C_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 randomize the base of the ph
when KASLR memory randomization is enabled.
Signed-off-by: Thomas Garnier
---
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/kernel/machine_kexec_64.c
index
On Thu, Dec 15, 2016 at 9:50 AM, Eric W. Biederman
wrote:
> Thomas Garnier writes:
>
>> This reverts commit 49fd897573c97b0eaf10f47d850027d78c456cd7.
>>
>> Reverting back to commit 0549a3c because the values are used by crash
>> and other tools already. I exp
On Thu, Dec 15, 2016 at 10:16 AM, Thomas Garnier wrote:
> On Thu, Dec 15, 2016 at 9:50 AM, Eric W. Biederman
> wrote:
>> Thomas Garnier writes:
>>
>>> This reverts commit 49fd897573c97b0eaf10f47d850027d78c456cd7.
>>>
>>> Reverting back to commit
> 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
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
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
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
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
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
Reviewed-by: Thomas Garnier
---
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 @@ union freelist_init_state {
unsign
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
---
Based
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
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.
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
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
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
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 wrote:
> On Tue, Mar 21, 2017 at 12:20 PM, Linus Torvalds
> wrote:
>>
>> On Tue, Mar
On Tue, Mar 21, 2017 at 4:51 PM, Andy Lutomirski wrote:
> On Tue, Mar 21, 2017 at 3:32 PM, Andy Lutomirski wrote:
>> On Tue, Mar 21, 2017 at 2:11 PM, Linus Torvalds
>> wrote:
>>> On Tue, Mar 21, 2017 at 1:25 PM, Thomas Garnier wrote:
>>>> The issue seems t
On Tue, Mar 21, 2017 at 9:27 PM, Andy Lutomirski wrote:
> On Tue, Mar 21, 2017 at 5:41 PM, Thomas Garnier wrote:
>> On Tue, Mar 21, 2017 at 4:51 PM, Andy Lutomirski wrote:
>>> On Tue, Mar 21, 2017 at 3:32 PM, Andy Lutomirski
>>> wrote:
>>>> On Tue,
On Wed, Mar 22, 2017 at 9:33 AM, Andy Lutomirski wrote:
> On Wed, Mar 22, 2017 at 12:36 AM, Ingo Molnar wrote:
>>
>> * Thomas Garnier wrote:
>>
>>> > static inline void setup_fixmap_gdt(int cpu)
>>> > {
>>> > __set_fixmap(g
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
---
Based on next-20170322
---
arch/s390/Kconfig| 1
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
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
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
On Wed, Mar 22, 2017 at 1:44 PM, Andy Lutomirski wrote:
> On Wed, Mar 22, 2017 at 1:38 PM, Thomas Garnier wrote:
>> This patch ensures a syscall does not return to user-mode with a kernel
>> address limit. If that happened, a process can corrupt kernel-mode
>> memory a
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 wrote:
> On 03/22/17 13:49, Thomas Garnier wrote:
>>
>> We can defaul
On Thu, Mar 23, 2017 at 8:32 AM, Borislav Petkov 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 the static
>> inline
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
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
---
Based on next-20170322
---
arch/s390/Kconfig| 1 +
include/linux/syscalls.h | 26 +-
init/Kconfig | 7
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
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
On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote:
> Implement specific usage of verify_pre_usermode_state for user-mode
> returns for x86.
Signed-off-by: Thomas Garnier
Not sure why it was not there anymore.
--
Thomas
On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote:
> Implement specific usage of verify_pre_usermode_state for user-mode
> returns for arm64.
Signed-off-by: Thomas Garnier
Not sure why it was not there anymore.
--
Thomas
On Thu, Mar 23, 2017 at 10:25 AM, Thomas Garnier wrote:
> Implement specific usage of verify_pre_usermode_state for user-mode
> returns for arm.
Signed-off-by: Thomas Garnier
Not sure why it was not there anymore.
--
Thomas
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
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
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
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
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
On Thu, Jan 5, 2017 at 12:11 AM, Ingo Molnar wrote:
>
> * 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 to bypass KASLR memory rand
On Thu, Jan 5, 2017 at 7:08 AM, Arjan van de Ven wrote:
> On 1/5/2017 12:11 AM, Ingo Molnar wrote:
>>
>>
>> * Thomas Garnier wrote:
>>
>>> Each processor holds a GDT in its per-cpu structure. The sgdt
>>> instruction gives the base address of
On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski wrote:
> On Wed, Jan 4, 2017 at 2:16 PM, 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
On Thu, Jan 5, 2017 at 10:01 AM, Andy Lutomirski wrote:
> On Thu, Jan 5, 2017 at 9:54 AM, Thomas Garnier wrote:
>> On Thu, Jan 5, 2017 at 9:51 AM, Andy Lutomirski wrote:
>>> On Wed, Jan 4, 2017 at 2:16 PM, Thomas Garnier wrote:
>>>> Each processor holds a GDT in i
On Thu, Jan 5, 2017 at 10:56 AM, Arjan van de Ven 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?
>
>
> no I would want it a runtim
On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven 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 iteration or
>> delay it for anot
On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote:
> On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote:
>> On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven
>> wrote:
>>> On 1/5/2017 9:54 AM, Thomas Garnier wrote:
>>>
>>>>
>>>>
On Thu, Jan 5, 2017 at 1:19 PM, Andy Lutomirski wrote:
> On Thu, Jan 5, 2017 at 1:08 PM, Thomas Garnier wrote:
>> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote:
>>> On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote:
>>>> On Thu, Jan 5, 2017
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 not sure that this is architecturally safe.
>
>
On Thu, Jan 5, 2017 at 4:35 PM, Andrew Morton wrote:
> On Tue, 3 Jan 2017 10:19:08 -0800 Thomas Garnier wrote:
>
>> This patch fixes a bug in the freelist randomization code. When a high
>> random number is used, the freelist will contain duplicate entries. It
>>
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 bits in all the segments
>>> then we don't need it to be writable in
On Thu, Jan 5, 2017 at 10:49 PM, Ingo Molnar wrote:
>
> * Thomas Garnier wrote:
>
>> >> Not sure I fully understood and I don't want to miss an important point.
>> >> Do
>> >> you mean making GDT (remapping and per-cpu) read-only and switch the
>&
On Fri, Jan 6, 2017 at 9:44 AM, Borislav Petkov 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 like kaslr_load_gdt
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:
>> >
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
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.
>>
>> Signed-off-by: Kees Cook
On Fri, Mar 24, 2017 at 8:24 AM, Christian Borntraeger
wrote:
> On 03/24/2017 04:17 PM, Thomas Garnier wrote:
>> 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_USE
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
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
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
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
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
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:
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 kernel space when
> running in
; 561b7e1a55e0
>> [9.988946] Code: ff 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1
>> e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1
>> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38
>> [9.988962] RIP: memcpy_erms+0x6/0x10 RSP:
On Fri, May 5, 2017 at 1:23 AM, Daniel Gruss
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.
>
>> - How this approach prevent the
On Fri, Apr 28, 2017 at 8:32 AM, Thomas Garnier 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_CHECK option disables the g
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.
>>
>>
>> I think we're not
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 what would be more useful is to add a specific
hen above two SGI MMIOH regions also will be
> mapped into the direct mapping section.
>
> To fix it, we need check if it's SGI UV system by calling
> is_early_uv_system() in kernel_randomize_memory(). If yes, do not adapt the
> size of the direct mapping section. Do it now.
>
&g
On Mon, May 22, 2017 at 9:30 AM, Mike Travis 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:
>
> On Sat, May 20, 2
On Thu, May 11, 2017 at 11:58 PM, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
>> On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier wrote:
>> >
>> > Ingo: Do you want the change as-is? Would you like it to be optional?
>> > What do you think?
>&
e a lot of sense. Thanks a lot for investigating this issue!
Acked-by: Thomas Garnier
>
> Fix it in this patch.
>
> The back trace is pasted as below:
>
> [9.988867] IP: memcpy_erms+0x6/0x10
> [9.988868] PGD 0
> [9.988868]
> [9.988870] Oops: [#1]
gt; [0.234000] ---[ end trace d4ded46ab8ab8ba9 ]---
> [0.234000] Kernel panic - not syncing: Attempted to kill the idle task!
> [0.234000] ---[ end Kernel panic - not syncing: Attempted to kill the
> idle task!
>
> Signed-off-by: Baoquan He
> Signed-off-by: Dave You
;> > #ifdef CONFIG_X86
>> > VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
>> > + VMCOREINFO_NUMBER(PAGE_OFFSET);
>> > + VMCOREINFO_NUMBER(VMALLOC_START);
>> > + VMCOREINFO_NUMBER(VMEMMAP_START);
>> > #endif
>> > #ifdef CONFIG_HUGETLB_
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 flags is through
On Mon, Nov 7, 2016 at 11:28 AM, Christoph Lameter 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.
>
> What
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
---
Based on next-20161027
---
mm/slab.h| 15 +++
mm/slab_common.c | 6 ++
2 files
fore calling
create_cache.
Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type,
OBJFREELIST_SLAB")
Signed-off-by: Greg Thelen
Tested-by: Thomas Garnier
---
Based on next-20161027
---
mm/slab_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
d
On Mon, Nov 7, 2016 at 2:19 PM, Andrew Morton wrote:
> On Mon, 7 Nov 2016 13:11:14 -0800 Thomas Garnier wrote:
>
>> From: Greg Thelen
>>
>> While testing OBJFREELIST_SLAB integration with pagealloc, we found a
>> bug where kmem_cache(sys) would be cr
fix discards allocator specific flags from memcg before calling
create_cache.
The bug exists since 4.6-rc1 and affects testing debug pagealloc
configurations.
Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type,
OBJFREELIST_SLAB")
Signed-off-by: Greg Thelen
Signed-off-by:
501 - 600 of 834 matches
Mail list logo
