Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
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 0x002A >> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
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 0x002A [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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
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 0x002A [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] c6fb9e10 c13b63ab c6fb9e40 c105f299 c149476c [3.639417] c6fb9e6c 017f c148d5ac 0060 c11463dd c11463dd c750aa00 c765e280 [3.639426] c765fb80 c6fb9e58 c105f333 0009 c6fb9e50 c149476c c6fb9e6c c6fb9e9c [3.639436] Call Trace: [3.639442] [] dump_stack+0x48/0x60 [3.639447] [] warn_slowpath_common+0x89/0xc0 [3.639451] [] ? flush_old_exec+0x7fd/0xb70 [3.639456] [] ? flush_old_exec+0x7fd/0xb70 [3.639460] [] warn_slowpath_fmt+0x33/0x40 [3.639464] [] flush_old_exec+0x7fd/0xb70 [3.639470] [] load_elf_binary+0x2b4/0x1060 [3.639475] [] ? lock_release+0x27e/0x4e0 [3.639480] [] ? lock_acquire+0xc1/0x240 [3.639484] [] search_binary_handler+0x4e/0xd0 [3.639489] [] do_execveat_common+0x62c/0x910 [3.639493] [] ? do_execveat_common+0x57d/0x910 [3.639498] [] do_execve+0x24/0x30 [3.639502] [] SyS_execve+0x28/0x40 [3.639507] [] syscall_call+0x7/0x7 [3.639511] ---[ end trace 95a382309b1f72bd ]--- [OK]LDT entry 0 has AR 0x0040FA00 and limit 0x002A [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] c6863f38 c13b63ab c6863f68 c105f299 c149476c [5.268301] c6863f94 0185 c1499b9c 0a4f c109f8b9 c109f8b9 c13be3a7 2000 [5.268311] c101b470 c6863f80 c105f333 0009 c6863f78 c149476c c6863f94 c6863f9c [5.268320] Call Trace: [5.268326] [] dump_stack+0x48/0x60 [5.268331] [] warn_slowpath_common+0x89/0xc0 [5.268336] [] ? trace_hardirqs_off_caller+0xa9/0xb0 [5.268340] [] ? trace_hardirqs_off_caller+0xa9/0xb0 [5.268346] [] ? error_code+0x5b/0x64 [5.268352] [] ? do_device_not_available+0x50/0x50 [5.268357] [] warn_slowpath_fmt+0x33/0x40 [5.268361] [] trace_hardirqs_off_caller+0xa9/0xb0 [5.268367] [] trace_hardirqs_off_thunk+0xc/0x10 [5.268371] [] ? error_code+0x5b/0x64 [5.268376] [] ? xen_build_mfn_list_list+0x2a0/0x300 [5.268381] [] ? 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
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 0x002A [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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
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 0x002A [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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
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 0x002A [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] c6fb9e10 c13b63ab c6fb9e40 c105f299 c149476c [3.639417] c6fb9e6c 017f c148d5ac 0060 c11463dd c11463dd c750aa00 c765e280 [3.639426] c765fb80 c6fb9e58 c105f333 0009 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 0x002A [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] c6863f38 c13b63ab c6863f68 c105f299 c149476c [5.268301] c6863f94 0185 c1499b9c 0a4f c109f8b9 c109f8b9 c13be3a7 2000 [5.268311] c101b470 c6863f80 c105f333 0009 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] [c13b] ? 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
