[tip:x86/pti] x86/tls: Fix possible spectre-v1 in do_get_thread_area()

Commit-ID: 993773d11d45c90cb1c6481c2638c3d9f092ea5b Gitweb: https://git.kernel.org/tip/993773d11d45c90cb1c6481c2638c3d9f092ea5b Author: Dianzhang Chen AuthorDate: Wed, 26 Jun 2019 12:50:30 +0800 Committer: Thomas Gleixner CommitDate: Thu, 27 Jun 2019 23:48:04 +0200 x86/tls: Fix

[tip:x86/pti] x86/ptrace: Fix possible spectre-v1 in ptrace_get_debugreg()

Commit-ID: 31a2fbb390fee4231281b939e1979e810f945415 Gitweb: https://git.kernel.org/tip/31a2fbb390fee4231281b939e1979e810f945415 Author: Dianzhang Chen AuthorDate: Tue, 25 Jun 2019 23:30:17 +0800 Committer: Thomas Gleixner CommitDate: Thu, 27 Jun 2019 23:48:04 +0200 x86/ptrace: Fix

[PATCH v3] x86/tls: Fix possible spectre-v1 in do_get_thread_area()

before using it to index p->thread.tls_array. Signed-off-by: Dianzhang Chen --- arch/x86/kernel/tls.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/tls.c b/arch/x86/kernel/tls.c index a5b802a..71d3fef 100644 --- a/arch/x86/kernel/tls.c +++ b/arch/x

Re: [PATCH v2] x86/tls: Fix possible spectre-v1 in do_get_thread_area()

On Wed, Jun 26, 2019 at 12:38 AM Thomas Gleixner wrote: > > On Wed, 26 Jun 2019, Dianzhang Chen wrote: > > > The index to access the threads tls array is controlled by userspace > > via syscall: sys_ptrace(), hence leading to a potential exploitation > > of the Spec

[PATCH v2] x86/tls: Fix possible spectre-v1 in do_get_thread_area()

before using it to index p->thread.tls_array. Signed-off-by: Dianzhang Chen --- arch/x86/kernel/tls.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/tls.c b/arch/x86/kernel/tls.c index a5b802a..424cff5 100644 --- a/arch/x86/kernel/tls.c +++ b/arch/x

[PATCH v2] x86/ptrace: Fix possible spectre-v1 in ptrace_get_debugreg()

before using it to index thread->ptrace_bps. Signed-off-by: Dianzhang Chen --- arch/x86/kernel/ptrace.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index a166c96..cbac646 100644 --- a/arch/x86/kernel/ptrace.c +++ b

[PATCH] x86: tls: fix possible spectre-v1 in do_get_thread_area()

tizing idx before using it to index p->thread.tls_array. Signed-off-by: Dianzhang Chen --- arch/x86/kernel/tls.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/tls.c b/arch/x86/kernel/tls.c index a5b802a..4cd338c 100644 --- a/arch/x86/kernel/tls.c +

Re: [PATCH] mm/slab_common.c: fix possible spectre-v1 in kmalloc_slab()

On Thu, May 30, 2019 at 2:24 PM Michal Hocko wrote: > I understand the general mechanism of spectre v1. What I was asking for > is an example of where userspace directly controls the allocation size > as this is usually bounded to an in kernel object size. I can see how > and N * sizeof(object) wh

Re: [PATCH] kernel/sys.c: fix possible spectre-v1 in do_prlimit()

On Wed, May 29, 2019 at 10:39:52AM +0800, Dianzhang Chen wrote: > > Hi, > > > > Although when detect it is misprediction and drop the execution, but > > it can not drop all the effects of speculative execution, like the > > cache state. During the speculative exe

Re: [PATCH] mm/slab_common.c: fix possible spectre-v1 in kmalloc_slab()

thanks, i think your suggestion is ok. in my previous method is easy to understand for spectre logic, but your suggestion is more sense to use of array_index_nospec. On Thu, May 30, 2019 at 3:48 AM Matthew Wilcox wrote: > > On Wed, May 29, 2019 at 08:37:28PM +0800, Dianzhang Chen

Re: [PATCH] mm/slab_common.c: fix possible spectre-v1 in kmalloc_slab()

at 1:49 AM Michal Hocko wrote: > > On Thu 30-05-19 00:39:53, Dianzhang Chen wrote: > > It's come from `192+1`. > > > > > > The more code fragment is: > > > > > > if (size <= 192) { > > > > if (!size) > > > >

Re: [PATCH] mm/slab_common.c: fix possible spectre-v1 in kmalloc_slab()

ge of [0, size), so in order to make the `size<=192`, need to clamp the index in the range of [0, 192+1) . On Thu, May 30, 2019 at 12:25 AM Michal Hocko wrote: > > On Wed 29-05-19 20:37:28, Dianzhang Chen wrote: > [...] > > @@ -1056,6 +1057,7 @@ struct kmem_cache *kmalloc_slab(siz

[PATCH] mm/slab_common.c: fix possible spectre-v1 in kmalloc_slab()

c_slab. Fix this by sanitizing `size` before using it to index size_index. Signed-off-by: Dianzhang Chen --- mm/slab_common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/slab_common.c b/mm/slab_common.c index 58251ba..41c7e34 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@

Re: [PATCH] kernel/sys.c: fix possible spectre-v1 in do_prlimit()

orm of spectre v1 would be[1]: if (x < array1_size) { y = array1[x]; // do something using y that is // observable when speculatively // executed } [1] https://spectreattack.com/spectre.pdf Cyrill Gorcunov 于2019年5月28日周二 下午3:10写道： > > On Tue, May 28, 2019 at 10:37:10AM +

[PATCH] kernel/sys.c: fix possible spectre-v1 in do_prlimit()

VAL; ... rlim = tsk->signal->rlim + resource;// use resource as index ... *old_rlim = *rlim; Fix this by sanitizing resource before using it to index tsk->signal->rlim. Signed-off-by: Dianzhang Chen --- kernel/sys.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a

[PATCH] x86: fix possible spectre-v1 in ptrace_get_debugreg()

his by sanitizing n before using it to index thread->ptrace_bps. Signed-off-by: Dianzhang Chen --- arch/x86/kernel/ptrace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index 4b8ee05..3f8f158 100644 --- a/arch/x86/kernel

[PATCH] x86: fix possible spectre-v1 in do_get_thread_area()

ng idx before using it to index p->thread.tls_array. Signed-off-by: Dianzhang Chen --- arch/x86/kernel/tls.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/tls.c b/arch/x86/kernel/tls.c index a5b802a..e3dc05b 100644 --- a/arch/x86/kernel/tls.c +++ b