* [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
@ 2015-07-30 21:31 Andy Lutomirski
0 siblings, 0 replies; 8+ messages in thread
From: Andy Lutomirski @ 2015-07-30 21:31 UTC (permalink / raw)
To: X86 ML, Borislav Petkov, linux-kernel
Cc: security, Andy Lutomirski, Peter Zijlstra, Andrew Cooper,
Steven Rostedt, xen-devel, Jan Beulich, Sasha Levin,
Boris Ostrovsky
This is intended for x86/urgent. Sorry for taking so long, but it
seemed nice to avoid breaking Xen.
This fixes the "dazed and confused" issue which was exposed by the
CVE-2015-5157 fix. It's also probably a good general attack surface
reduction, and it replaces some scary code with IMO less scary code.
Also, servers and embedded systems should probably turn off modify_ldt.
This makes that possible.
Xen people, can you test patch 1? It works for me on my evil 32-bit
Xen virtio setup.
Willy and Kees: I left the config option alone. The -tiny people will
like it, and we can always add a sysctl of some sort later.
Changes from v5:
- Improve Xen bits, this time with comments that seem plausible.
- Fix debug_locks warning on exec.
- Add a test for exec preserving the LDT (!)
Changes from v4:
- Fix Xen even better (patch 1 is new).
- Reorder the patches to make a little more sense.
Changes from v3:
- Hopefully fixed Xen.
- Fixed 32-bit test case on 32-bit native kernel.
- Fix bogus vumnap for some LDT sizes.
- Strengthen test case to check all LDT sizes (catches bogus vunmap).
- Lots of cleanups, mostly from Borislav.
- Simplify IPI code using on_each_cpu_mask.
Changes from v2:
- Allocate ldt_struct and the LDT entries separately. This should fix Xen.
- Stop using write_ldt_entry, since I'm pretty sure it's unnecessary now
that we no longer mutate an in-use LDT. (Xen people, can you check?)
Changes from v1:
- The config option is new.
- The test case is new.
- Fixed a missing allocation failure check.
- Fixed a use-after-free on fork().
Andy Lutomirski (4):
x86/xen: Probe target addresses in set_aliased_prot before the
hypercall
x86/ldt: Make modify_ldt synchronous
selftests/x86, x86/ldt: Add a selftest for modify_ldt
x86/ldt: Make modify_ldt optional
arch/x86/Kconfig | 17 +
arch/x86/include/asm/desc.h | 15 -
arch/x86/include/asm/mmu.h | 5 +-
arch/x86/include/asm/mmu_context.h | 68 +++-
arch/x86/kernel/Makefile | 3 +-
arch/x86/kernel/cpu/common.c | 4 +-
arch/x86/kernel/cpu/perf_event.c | 16 +-
arch/x86/kernel/ldt.c | 262 +++++++++-------
arch/x86/kernel/process_64.c | 6 +-
arch/x86/kernel/step.c | 8 +-
arch/x86/power/cpu.c | 3 +-
arch/x86/xen/enlighten.c | 40 +++
kernel/sys_ni.c | 1 +
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/ldt_gdt.c | 576 ++++++++++++++++++++++++++++++++++
15 files changed, 871 insertions(+), 155 deletions(-)
create mode 100644 tools/testing/selftests/x86/ldt_gdt.c
--
2.4.3
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
@ 2015-07-30 21:31 Andy Lutomirski
2015-07-31 9:10 ` Andrew Cooper
2015-07-31 9:10 ` Andrew Cooper
0 siblings, 2 replies; 8+ messages in thread
From: Andy Lutomirski @ 2015-07-30 21:31 UTC (permalink / raw)
To: X86 ML, Borislav Petkov, linux-kernel
Cc: Peter Zijlstra, Steven Rostedt, security, Sasha Levin,
Konrad Rzeszutek Wilk, Boris Ostrovsky, Andrew Cooper,
Jan Beulich, xen-devel, Andy Lutomirski
This is intended for x86/urgent. Sorry for taking so long, but it
seemed nice to avoid breaking Xen.
This fixes the "dazed and confused" issue which was exposed by the
CVE-2015-5157 fix. It's also probably a good general attack surface
reduction, and it replaces some scary code with IMO less scary code.
Also, servers and embedded systems should probably turn off modify_ldt.
This makes that possible.
Xen people, can you test patch 1? It works for me on my evil 32-bit
Xen virtio setup.
Willy and Kees: I left the config option alone. The -tiny people will
like it, and we can always add a sysctl of some sort later.
Changes from v5:
- Improve Xen bits, this time with comments that seem plausible.
- Fix debug_locks warning on exec.
- Add a test for exec preserving the LDT (!)
Changes from v4:
- Fix Xen even better (patch 1 is new).
- Reorder the patches to make a little more sense.
Changes from v3:
- Hopefully fixed Xen.
- Fixed 32-bit test case on 32-bit native kernel.
- Fix bogus vumnap for some LDT sizes.
- Strengthen test case to check all LDT sizes (catches bogus vunmap).
- Lots of cleanups, mostly from Borislav.
- Simplify IPI code using on_each_cpu_mask.
Changes from v2:
- Allocate ldt_struct and the LDT entries separately. This should fix Xen.
- Stop using write_ldt_entry, since I'm pretty sure it's unnecessary now
that we no longer mutate an in-use LDT. (Xen people, can you check?)
Changes from v1:
- The config option is new.
- The test case is new.
- Fixed a missing allocation failure check.
- Fixed a use-after-free on fork().
Andy Lutomirski (4):
x86/xen: Probe target addresses in set_aliased_prot before the
hypercall
x86/ldt: Make modify_ldt synchronous
selftests/x86, x86/ldt: Add a selftest for modify_ldt
x86/ldt: Make modify_ldt optional
arch/x86/Kconfig | 17 +
arch/x86/include/asm/desc.h | 15 -
arch/x86/include/asm/mmu.h | 5 +-
arch/x86/include/asm/mmu_context.h | 68 +++-
arch/x86/kernel/Makefile | 3 +-
arch/x86/kernel/cpu/common.c | 4 +-
arch/x86/kernel/cpu/perf_event.c | 16 +-
arch/x86/kernel/ldt.c | 262 +++++++++-------
arch/x86/kernel/process_64.c | 6 +-
arch/x86/kernel/step.c | 8 +-
arch/x86/power/cpu.c | 3 +-
arch/x86/xen/enlighten.c | 40 +++
kernel/sys_ni.c | 1 +
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/ldt_gdt.c | 576 ++++++++++++++++++++++++++++++++++
15 files changed, 871 insertions(+), 155 deletions(-)
create mode 100644 tools/testing/selftests/x86/ldt_gdt.c
--
2.4.3
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
2015-07-30 21:31 Andy Lutomirski
@ 2015-07-31 9:10 ` Andrew Cooper
2015-07-31 9:10 ` Andrew Cooper
1 sibling, 0 replies; 8+ messages in thread
From: Andrew Cooper @ 2015-07-31 9:10 UTC (permalink / raw)
To: Andy Lutomirski, X86 ML, Borislav Petkov, linux-kernel
Cc: security, Peter Zijlstra, Steven Rostedt, xen-devel, Jan Beulich,
Sasha Levin, Boris Ostrovsky
On 30/07/15 22:31, Andy Lutomirski wrote:
> This is intended for x86/urgent. Sorry for taking so long, but it
> seemed nice to avoid breaking Xen.
Very much appreciated. Thanks!
>
> This fixes the "dazed and confused" issue which was exposed by the
> CVE-2015-5157 fix. It's also probably a good general attack surface
> reduction, and it replaces some scary code with IMO less scary code.
>
> Also, servers and embedded systems should probably turn off modify_ldt.
> This makes that possible.
>
> Xen people, can you test patch 1? It works for me on my evil 32-bit
> Xen virtio setup.
So the LDT issue seems to have gone away, which is good.
However, I did get this from my single vcpu guest test
[OK] LDT entry 0 is invalid
[SKIP] Cannot set affinity to CPU 1
[RUN] Test exec
[ 3.638967] CPU 0 set the LDT
[OK] LDT entry 0 has AR 0x0040FA00 and limit 0x0000002A
[ 3.639380] ------------[ cut here ]------------
[ 3.639389] WARNING: CPU: 0 PID: 383 at
/local/linux-mainline.git/arch/x86/include/asm/mmu_context.h:96
flush_old_exec+0x7fd/0xb70()
[ 3.639397] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
[ 3.639401] CPU: 0 PID: 383 Comm: ldt_gdt_32 Not tainted 4.2.0-rc4+ #21
[ 3.639407] 00000000 00000000 c6fb9e10 c13b63ab 00000000 c6fb9e40
c105f299 c149476c
[ 3.639417] c6fb9e6c 0000017f c148d5ac 00000060 c11463dd c11463dd
c750aa00 c765e280
[ 3.639426] c765fb80 c6fb9e58 c105f333 00000009 c6fb9e50 c149476c
c6fb9e6c c6fb9e9c
[ 3.639436] Call Trace:
[ 3.639442] [<c13b63ab>] dump_stack+0x48/0x60
[ 3.639447] [<c105f299>] warn_slowpath_common+0x89/0xc0
[ 3.639451] [<c11463dd>] ? flush_old_exec+0x7fd/0xb70
[ 3.639456] [<c11463dd>] ? flush_old_exec+0x7fd/0xb70
[ 3.639460] [<c105f333>] warn_slowpath_fmt+0x33/0x40
[ 3.639464] [<c11463dd>] flush_old_exec+0x7fd/0xb70
[ 3.639470] [<c118fdc4>] load_elf_binary+0x2b4/0x1060
[ 3.639475] [<c10a360e>] ? lock_release+0x27e/0x4e0
[ 3.639480] [<c10a3931>] ? lock_acquire+0xc1/0x240
[ 3.639484] [<c1146b6e>] search_binary_handler+0x4e/0xd0
[ 3.639489] [<c114721c>] do_execveat_common+0x62c/0x910
[ 3.639493] [<c114716d>] ? do_execveat_common+0x57d/0x910
[ 3.639498] [<c1147524>] do_execve+0x24/0x30
[ 3.639502] [<c1147788>] SyS_execve+0x28/0x40
[ 3.639507] [<c13bd497>] syscall_call+0x7/0x7
[ 3.639511] ---[ end trace 95a382309b1f72bd ]---
[OK] LDT entry 0 has AR 0x0040FA00 and limit 0x0000002A
[OK] Child succeeded
[ 3.639897] CPU 0 cleared the LDT
And this from a two-vcpu test:
[RUN] Cross-CPU LDT invalidation
[ 5.260315] CPU 1 set the LDT
[ 5.260324] CPU 0 set the LDT
[ 5.268245] CPU 0 cleared the LDT
[ 5.268261] ------------[ cut here ]------------
[ 5.268263] CPU 1 cleared the LDT
[ 5.268272] WARNING: CPU: 0 PID: 389 at
/local/linux-mainline.git/kernel/locking/lockdep.c:2639
trace_hardirqs_off_caller+0xa9/0xb0()
[ 5.268280] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
[ 5.268285] CPU: 0 PID: 389 Comm: ldt_gdt_32 Not tainted 4.2.0-rc4+ #21
[ 5.268291] 00000000 00000000 c6863f38 c13b63ab 00000000 c6863f68
c105f299 c149476c
[ 5.268301] c6863f94 00000185 c1499b9c 00000a4f c109f8b9 c109f8b9
c13be3a7 00002000
[ 5.268311] c101b470 c6863f80 c105f333 00000009 c6863f78 c149476c
c6863f94 c6863f9c
[ 5.268320] Call Trace:
[ 5.268326] [<c13b63ab>] dump_stack+0x48/0x60
[ 5.268331] [<c105f299>] warn_slowpath_common+0x89/0xc0
[ 5.268336] [<c109f8b9>] ? trace_hardirqs_off_caller+0xa9/0xb0
[ 5.268340] [<c109f8b9>] ? trace_hardirqs_off_caller+0xa9/0xb0
[ 5.268346] [<c13be3a7>] ? error_code+0x5b/0x64
[ 5.268352] [<c101b470>] ? do_device_not_available+0x50/0x50
[ 5.268357] [<c105f333>] warn_slowpath_fmt+0x33/0x40
[ 5.268361] [<c109f8b9>] trace_hardirqs_off_caller+0xa9/0xb0
[ 5.268367] [<c10029ec>] trace_hardirqs_off_thunk+0xc/0x10
[ 5.268371] [<c13be3a7>] ? error_code+0x5b/0x64
[ 5.268376] [<c13b0000>] ? xen_build_mfn_list_list+0x2a0/0x300
[ 5.268381] [<c101b470>] ? do_device_not_available+0x50/0x50
[ 5.268386] ---[ end trace da759e1fe4c971e6 ]---
[ 5.268434] CPU 1 set the LDT
[ 5.268441] CPU 0 set the LDT
[ 5.268537] CPU 0 cleared the LDT
[ 5.268543] CPU 1 cleared the LDT
[ 5.268629] CPU 1 set the LDT
[ 5.268634] CPU 0 set the LDT
[ 5.268726] CPU 0 cleared the LDT
[ 5.268732] CPU 1 cleared the LDT
[ 5.268818] CPU 1 set the LDT
[ 5.268823] CPU 0 set the LDT
[ 5.268916] CPU 0 cleared the LDT
[ 5.268922] CPU 1 cleared the LDT
[ 5.341360] CPU 1 set the LDT
[ 5.341369] CPU 0 set the LDT
[ 5.341528] CPU 0 cleared the LDT
[ 5.341538] CPU 1 cleared the LDT
[OK] All 5 iterations succeeded
I am going to try some 64bit tests now.
~Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
2015-07-30 21:31 Andy Lutomirski
2015-07-31 9:10 ` Andrew Cooper
@ 2015-07-31 9:10 ` Andrew Cooper
2015-07-31 13:44 ` Boris Ostrovsky
2015-07-31 13:44 ` Boris Ostrovsky
1 sibling, 2 replies; 8+ messages in thread
From: Andrew Cooper @ 2015-07-31 9:10 UTC (permalink / raw)
To: Andy Lutomirski, X86 ML, Borislav Petkov, linux-kernel
Cc: Peter Zijlstra, Steven Rostedt, security, Sasha Levin,
Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Beulich, xen-devel
On 30/07/15 22:31, Andy Lutomirski wrote:
> This is intended for x86/urgent. Sorry for taking so long, but it
> seemed nice to avoid breaking Xen.
Very much appreciated. Thanks!
>
> This fixes the "dazed and confused" issue which was exposed by the
> CVE-2015-5157 fix. It's also probably a good general attack surface
> reduction, and it replaces some scary code with IMO less scary code.
>
> Also, servers and embedded systems should probably turn off modify_ldt.
> This makes that possible.
>
> Xen people, can you test patch 1? It works for me on my evil 32-bit
> Xen virtio setup.
So the LDT issue seems to have gone away, which is good.
However, I did get this from my single vcpu guest test
[OK] LDT entry 0 is invalid
[SKIP] Cannot set affinity to CPU 1
[RUN] Test exec
[ 3.638967] CPU 0 set the LDT
[OK] LDT entry 0 has AR 0x0040FA00 and limit 0x0000002A
[ 3.639380] ------------[ cut here ]------------
[ 3.639389] WARNING: CPU: 0 PID: 383 at
/local/linux-mainline.git/arch/x86/include/asm/mmu_context.h:96
flush_old_exec+0x7fd/0xb70()
[ 3.639397] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
[ 3.639401] CPU: 0 PID: 383 Comm: ldt_gdt_32 Not tainted 4.2.0-rc4+ #21
[ 3.639407] 00000000 00000000 c6fb9e10 c13b63ab 00000000 c6fb9e40
c105f299 c149476c
[ 3.639417] c6fb9e6c 0000017f c148d5ac 00000060 c11463dd c11463dd
c750aa00 c765e280
[ 3.639426] c765fb80 c6fb9e58 c105f333 00000009 c6fb9e50 c149476c
c6fb9e6c c6fb9e9c
[ 3.639436] Call Trace:
[ 3.639442] [<c13b63ab>] dump_stack+0x48/0x60
[ 3.639447] [<c105f299>] warn_slowpath_common+0x89/0xc0
[ 3.639451] [<c11463dd>] ? flush_old_exec+0x7fd/0xb70
[ 3.639456] [<c11463dd>] ? flush_old_exec+0x7fd/0xb70
[ 3.639460] [<c105f333>] warn_slowpath_fmt+0x33/0x40
[ 3.639464] [<c11463dd>] flush_old_exec+0x7fd/0xb70
[ 3.639470] [<c118fdc4>] load_elf_binary+0x2b4/0x1060
[ 3.639475] [<c10a360e>] ? lock_release+0x27e/0x4e0
[ 3.639480] [<c10a3931>] ? lock_acquire+0xc1/0x240
[ 3.639484] [<c1146b6e>] search_binary_handler+0x4e/0xd0
[ 3.639489] [<c114721c>] do_execveat_common+0x62c/0x910
[ 3.639493] [<c114716d>] ? do_execveat_common+0x57d/0x910
[ 3.639498] [<c1147524>] do_execve+0x24/0x30
[ 3.639502] [<c1147788>] SyS_execve+0x28/0x40
[ 3.639507] [<c13bd497>] syscall_call+0x7/0x7
[ 3.639511] ---[ end trace 95a382309b1f72bd ]---
[OK] LDT entry 0 has AR 0x0040FA00 and limit 0x0000002A
[OK] Child succeeded
[ 3.639897] CPU 0 cleared the LDT
And this from a two-vcpu test:
[RUN] Cross-CPU LDT invalidation
[ 5.260315] CPU 1 set the LDT
[ 5.260324] CPU 0 set the LDT
[ 5.268245] CPU 0 cleared the LDT
[ 5.268261] ------------[ cut here ]------------
[ 5.268263] CPU 1 cleared the LDT
[ 5.268272] WARNING: CPU: 0 PID: 389 at
/local/linux-mainline.git/kernel/locking/lockdep.c:2639
trace_hardirqs_off_caller+0xa9/0xb0()
[ 5.268280] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
[ 5.268285] CPU: 0 PID: 389 Comm: ldt_gdt_32 Not tainted 4.2.0-rc4+ #21
[ 5.268291] 00000000 00000000 c6863f38 c13b63ab 00000000 c6863f68
c105f299 c149476c
[ 5.268301] c6863f94 00000185 c1499b9c 00000a4f c109f8b9 c109f8b9
c13be3a7 00002000
[ 5.268311] c101b470 c6863f80 c105f333 00000009 c6863f78 c149476c
c6863f94 c6863f9c
[ 5.268320] Call Trace:
[ 5.268326] [<c13b63ab>] dump_stack+0x48/0x60
[ 5.268331] [<c105f299>] warn_slowpath_common+0x89/0xc0
[ 5.268336] [<c109f8b9>] ? trace_hardirqs_off_caller+0xa9/0xb0
[ 5.268340] [<c109f8b9>] ? trace_hardirqs_off_caller+0xa9/0xb0
[ 5.268346] [<c13be3a7>] ? error_code+0x5b/0x64
[ 5.268352] [<c101b470>] ? do_device_not_available+0x50/0x50
[ 5.268357] [<c105f333>] warn_slowpath_fmt+0x33/0x40
[ 5.268361] [<c109f8b9>] trace_hardirqs_off_caller+0xa9/0xb0
[ 5.268367] [<c10029ec>] trace_hardirqs_off_thunk+0xc/0x10
[ 5.268371] [<c13be3a7>] ? error_code+0x5b/0x64
[ 5.268376] [<c13b0000>] ? xen_build_mfn_list_list+0x2a0/0x300
[ 5.268381] [<c101b470>] ? do_device_not_available+0x50/0x50
[ 5.268386] ---[ end trace da759e1fe4c971e6 ]---
[ 5.268434] CPU 1 set the LDT
[ 5.268441] CPU 0 set the LDT
[ 5.268537] CPU 0 cleared the LDT
[ 5.268543] CPU 1 cleared the LDT
[ 5.268629] CPU 1 set the LDT
[ 5.268634] CPU 0 set the LDT
[ 5.268726] CPU 0 cleared the LDT
[ 5.268732] CPU 1 cleared the LDT
[ 5.268818] CPU 1 set the LDT
[ 5.268823] CPU 0 set the LDT
[ 5.268916] CPU 0 cleared the LDT
[ 5.268922] CPU 1 cleared the LDT
[ 5.341360] CPU 1 set the LDT
[ 5.341369] CPU 0 set the LDT
[ 5.341528] CPU 0 cleared the LDT
[ 5.341538] CPU 1 cleared the LDT
[OK] All 5 iterations succeeded
I am going to try some 64bit tests now.
~Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
2015-07-31 9:10 ` Andrew Cooper
@ 2015-07-31 13:44 ` Boris Ostrovsky
2015-07-31 13:44 ` Boris Ostrovsky
1 sibling, 0 replies; 8+ messages in thread
From: Boris Ostrovsky @ 2015-07-31 13:44 UTC (permalink / raw)
To: Andrew Cooper, Andy Lutomirski, X86 ML, Borislav Petkov, linux-kernel
Cc: security, Peter Zijlstra, Steven Rostedt, xen-devel, Jan Beulich,
Sasha Levin
On 07/31/2015 05:10 AM, Andrew Cooper wrote:
> On 30/07/15 22:31, Andy Lutomirski wrote:
>> This is intended for x86/urgent. Sorry for taking so long, but it
>> seemed nice to avoid breaking Xen.
> Very much appreciated. Thanks!
>
>> This fixes the "dazed and confused" issue which was exposed by the
>> CVE-2015-5157 fix. It's also probably a good general attack surface
>> reduction, and it replaces some scary code with IMO less scary code.
>>
>> Also, servers and embedded systems should probably turn off modify_ldt.
>> This makes that possible.
>>
>> Xen people, can you test patch 1? It works for me on my evil 32-bit
>> Xen virtio setup.
> So the LDT issue seems to have gone away, which is good.
>
> However, I did get this from my single vcpu guest test
>
> [OK] LDT entry 0 is invalid
> [SKIP] Cannot set affinity to CPU 1
> [RUN] Test exec
> [ 3.638967] CPU 0 set the LDT
> [OK] LDT entry 0 has AR 0x0040FA00 and limit 0x0000002A
> [ 3.639380] ------------[ cut here ]------------
> [ 3.639389] WARNING: CPU: 0 PID: 383 at
> /local/linux-mainline.git/arch/x86/include/asm/mmu_context.h:96
> flush_old_exec+0x7fd/0xb70()
> [ 3.639397] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
You must be running v5 (or earlier). This is fixed in v6 --- it is now
'DEBUG_LOCKS_WARN_ON(preemptible());'
-boris
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
2015-07-31 9:10 ` Andrew Cooper
2015-07-31 13:44 ` Boris Ostrovsky
@ 2015-07-31 13:44 ` Boris Ostrovsky
2015-07-31 14:02 ` Andrew Cooper
1 sibling, 1 reply; 8+ messages in thread
From: Boris Ostrovsky @ 2015-07-31 13:44 UTC (permalink / raw)
To: Andrew Cooper, Andy Lutomirski, X86 ML, Borislav Petkov, linux-kernel
Cc: Peter Zijlstra, Steven Rostedt, security, Sasha Levin,
Konrad Rzeszutek Wilk, Jan Beulich, xen-devel
On 07/31/2015 05:10 AM, Andrew Cooper wrote:
> On 30/07/15 22:31, Andy Lutomirski wrote:
>> This is intended for x86/urgent. Sorry for taking so long, but it
>> seemed nice to avoid breaking Xen.
> Very much appreciated. Thanks!
>
>> This fixes the "dazed and confused" issue which was exposed by the
>> CVE-2015-5157 fix. It's also probably a good general attack surface
>> reduction, and it replaces some scary code with IMO less scary code.
>>
>> Also, servers and embedded systems should probably turn off modify_ldt.
>> This makes that possible.
>>
>> Xen people, can you test patch 1? It works for me on my evil 32-bit
>> Xen virtio setup.
> So the LDT issue seems to have gone away, which is good.
>
> However, I did get this from my single vcpu guest test
>
> [OK] LDT entry 0 is invalid
> [SKIP] Cannot set affinity to CPU 1
> [RUN] Test exec
> [ 3.638967] CPU 0 set the LDT
> [OK] LDT entry 0 has AR 0x0040FA00 and limit 0x0000002A
> [ 3.639380] ------------[ cut here ]------------
> [ 3.639389] WARNING: CPU: 0 PID: 383 at
> /local/linux-mainline.git/arch/x86/include/asm/mmu_context.h:96
> flush_old_exec+0x7fd/0xb70()
> [ 3.639397] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
You must be running v5 (or earlier). This is fixed in v6 --- it is now
'DEBUG_LOCKS_WARN_ON(preemptible());'
-boris
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
2015-07-31 13:44 ` Boris Ostrovsky
@ 2015-07-31 14:02 ` Andrew Cooper
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Cooper @ 2015-07-31 14:02 UTC (permalink / raw)
To: Boris Ostrovsky, Andy Lutomirski, X86 ML, Borislav Petkov, linux-kernel
Cc: Peter Zijlstra, Steven Rostedt, security, Sasha Levin,
Konrad Rzeszutek Wilk, Jan Beulich, xen-devel
On 31/07/15 14:44, Boris Ostrovsky wrote:
> On 07/31/2015 05:10 AM, Andrew Cooper wrote:
>> On 30/07/15 22:31, Andy Lutomirski wrote:
>>> This is intended for x86/urgent. Sorry for taking so long, but it
>>> seemed nice to avoid breaking Xen.
>> Very much appreciated. Thanks!
>>
>>> This fixes the "dazed and confused" issue which was exposed by the
>>> CVE-2015-5157 fix. It's also probably a good general attack surface
>>> reduction, and it replaces some scary code with IMO less scary code.
>>>
>>> Also, servers and embedded systems should probably turn off modify_ldt.
>>> This makes that possible.
>>>
>>> Xen people, can you test patch 1? It works for me on my evil 32-bit
>>> Xen virtio setup.
>> So the LDT issue seems to have gone away, which is good.
>>
>> However, I did get this from my single vcpu guest test
>>
>> [OK] LDT entry 0 is invalid
>> [SKIP] Cannot set affinity to CPU 1
>> [RUN] Test exec
>> [ 3.638967] CPU 0 set the LDT
>> [OK] LDT entry 0 has AR 0x0040FA00 and limit 0x0000002A
>> [ 3.639380] ------------[ cut here ]------------
>> [ 3.639389] WARNING: CPU: 0 PID: 383 at
>> /local/linux-mainline.git/arch/x86/include/asm/mmu_context.h:96
>> flush_old_exec+0x7fd/0xb70()
>> [ 3.639397] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
>
> You must be running v5 (or earlier). This is fixed in v6 --- it is now
> 'DEBUG_LOCKS_WARN_ON(preemptible());'
Hmm - I definitely have the correct code, but did a complete clean and
rebuild, and the issue went away. I presume I had something stale in
the build.
I am still seeing
[ 5.496264] WARNING: CPU: 0 PID: 389 at
/local/linux-mainline.git/kernel/locking/lockdep.c:2639
trace_hardirqs_off_caller+0xa9/0xb0()
[ 5.496272] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
[ 5.496276] CPU: 0 PID: 389 Comm: ldt_gdt_32 Not tainted 4.2.0-rc4+ #21
But that looks incidental, and unrelated to these fixes.
~Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
@ 2015-07-31 14:02 ` Andrew Cooper
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Cooper @ 2015-07-31 14:02 UTC (permalink / raw)
To: Boris Ostrovsky, Andy Lutomirski, X86 ML, Borislav Petkov, linux-kernel
Cc: security, Peter Zijlstra, Steven Rostedt, xen-devel, Jan Beulich,
Sasha Levin
On 31/07/15 14:44, Boris Ostrovsky wrote:
> On 07/31/2015 05:10 AM, Andrew Cooper wrote:
>> On 30/07/15 22:31, Andy Lutomirski wrote:
>>> This is intended for x86/urgent. Sorry for taking so long, but it
>>> seemed nice to avoid breaking Xen.
>> Very much appreciated. Thanks!
>>
>>> This fixes the "dazed and confused" issue which was exposed by the
>>> CVE-2015-5157 fix. It's also probably a good general attack surface
>>> reduction, and it replaces some scary code with IMO less scary code.
>>>
>>> Also, servers and embedded systems should probably turn off modify_ldt.
>>> This makes that possible.
>>>
>>> Xen people, can you test patch 1? It works for me on my evil 32-bit
>>> Xen virtio setup.
>> So the LDT issue seems to have gone away, which is good.
>>
>> However, I did get this from my single vcpu guest test
>>
>> [OK] LDT entry 0 is invalid
>> [SKIP] Cannot set affinity to CPU 1
>> [RUN] Test exec
>> [ 3.638967] CPU 0 set the LDT
>> [OK] LDT entry 0 has AR 0x0040FA00 and limit 0x0000002A
>> [ 3.639380] ------------[ cut here ]------------
>> [ 3.639389] WARNING: CPU: 0 PID: 383 at
>> /local/linux-mainline.git/arch/x86/include/asm/mmu_context.h:96
>> flush_old_exec+0x7fd/0xb70()
>> [ 3.639397] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
>
> You must be running v5 (or earlier). This is fixed in v6 --- it is now
> 'DEBUG_LOCKS_WARN_ON(preemptible());'
Hmm - I definitely have the correct code, but did a complete clean and
rebuild, and the issue went away. I presume I had something stale in
the build.
I am still seeing
[ 5.496264] WARNING: CPU: 0 PID: 389 at
/local/linux-mainline.git/kernel/locking/lockdep.c:2639
trace_hardirqs_off_caller+0xa9/0xb0()
[ 5.496272] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
[ 5.496276] CPU: 0 PID: 389 Comm: ldt_gdt_32 Not tainted 4.2.0-rc4+ #21
But that looks incidental, and unrelated to these fixes.
~Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-07-31 14:20 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-30 21:31 [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option Andy Lutomirski
2015-07-30 21:31 Andy Lutomirski
2015-07-31 9:10 ` Andrew Cooper
2015-07-31 9:10 ` Andrew Cooper
2015-07-31 13:44 ` Boris Ostrovsky
2015-07-31 13:44 ` Boris Ostrovsky
2015-07-31 14:02 ` Andrew Cooper
2015-07-31 14:02 ` Andrew Cooper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.