Re: [PATCH] x86: Implement __WARN using UD0

[hpa]

On February 25, 2017 11:38:44 AM PST, Borislav Petkov <bp@xxxxxxxxx> wrote:
>On Sat, Feb 25, 2017 at 09:55:45AM -0800, hpa@xxxxxxxxx wrote:
>> You mean like the INT instruction?
>
>Right, you mentioned reusing INT $9 upthread.
>
>That doesn't have the additional info in the immed8 - it is the vector
>in this case. But that's not really important for our usage.
>
>In any case, the hw does react to it when I do
>
>	"int $9"
>
>so I guess we could look into using that one.
>
>[   93.668930] test: loading out-of-tree module taints kernel.
>[   93.674785] Starting test.
>[   93.677571] coprocessor segment overrun: 0000 [#1] PREEMPT SMP
>[   93.683459] Modules linked in: test(O+) xfs libcrc32c exportfs
>snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_coded
>[   93.683489] CPU: 4 PID: 2136 Comm: insmod Tainted: G           O   
>4.10.0-rc7+ #7
>[   93.683500] Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD
>MS-7599/870-C45 (MS-7599), BIOS V1.15 03/04/2011
>[   93.683503] task: ffff88012f154380 task.stack: ffffc90006cf4000
>[   93.683512] RIP: 0010:test_init+0x17/0x20 [test]
>[   93.683515] RSP: 0018:ffffc90006cf7cb8 EFLAGS: 00000296
>[   93.683518] RAX: 000000000000000e RBX: ffffffffa03ca0c0 RCX:
>0000000000000000
>[   93.683521] RDX: 000000000000000e RSI: ffffffff802d4e48 RDI:
>ffffffff802d4e48
>[   93.683523] RBP: ffffc90006cf7cb8 R08: 0000000000000000 R09:
>0000000000000274
>[   93.683525] R10: 0000000000000000 R11: 0000000000000273 R12:
>ffffffffa03ca000
>[   93.683527] R13: 0000000000000000 R14: 0000000000000001 R15:
>ffffc90006cf7eb0
>[   93.683530] FS:  00007f55d1e3e700(0000) GS:ffff880136d00000(0000)
>knlGS:0000000000000000
>[   93.683533] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[   93.683535] CR2: 000055be657f51e8 CR3: 0000000131014000 CR4:
>00000000000006e0
>[   93.683537] Call Trace:
>[   93.683548]  do_one_initcall+0x53/0x1a0
>[   93.683554]  ? __vunmap+0xaa/0xf0
>[   93.683559]  ? kfree+0x151/0x1b0
>[   93.683566]  do_init_module+0x5f/0x1d5
>[   93.683573]  load_module+0x2026/0x2530
>[   93.683578]  ? __symbol_put+0x80/0x80
>[   93.683589]  SYSC_finit_module+0xcb/0xd0
>[   93.683597]  SyS_finit_module+0xe/0x10
>[   93.683602]  entry_SYSCALL_64_fastpath+0x18/0xa8
>[   93.683605] RIP: 0033:0x7f55d1970a59
>[   93.683607] RSP: 002b:00007ffc3cf781d8 EFLAGS: 00000206 ORIG_RAX:
>0000000000000139
>[   93.683610] RAX: ffffffffffffffda RBX: 00007f55d1c2ab78 RCX:
>00007f55d1970a59
>[   93.683612] RDX: 0000000000000000 RSI: 000055be655d73d9 RDI:
>0000000000000003
>[   93.683614] RBP: 000000000000270f R08: 0000000000000000 R09:
>00007f55d1c2cf00
>[   93.683616] R10: 0000000000000003 R11: 0000000000000206 R12:
>00007f55d1c2ab78
>[   93.683618] R13: 0000000000001020 R14: 00007f55d1c2ab78 R15:
>00007f55d1c2ab20
>[   93.683623] Code: <31> c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48
>c7 c7 6e a0 3c a0 
>[   93.683655] RIP: test_init+0x17/0x20 [test] RSP: ffffc90006cf7cb8
>[   93.683699] ---[ end trace e034b65a8bb8cf26 ]---
>[   93.683702] Kernel panic - not syncing: Fatal exception
>[   93.709252] Kernel Offset: disabled

Note that once you have a trap you can create an immediate yourself, the CPU doesn't need to do it for you, unless you really care about latency (reading the instruction steam can be kind of expensive, although it is quite a bit simpler if we know we come from kernel space.)
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.