Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
	"Borislav Petkov" <bp@alien8.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	"security@kernel.org" <security@kernel.org>,
	"Sasha Levin" <sasha.levin@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
Date: Fri, 31 Jul 2015 10:10:10 +0100	[thread overview]
Message-ID: <55BB3B72.6060607@citrix.com> (raw)
In-Reply-To: <cover.1438291540.git.luto@kernel.org>

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