lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 25 Feb 2017 12:04:18 -0800
From:   hpa@...or.com
To:     Borislav Petkov <bp@...en8.de>
CC:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        jpoimboe@...hat.com, richard.weinberger@...il.com,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] x86: Implement __WARN using UD0

On February 25, 2017 11:38:44 AM PST, Borislav Petkov <bp@...en8.de> wrote:
>On Sat, Feb 25, 2017 at 09:55:45AM -0800, hpa@...or.com 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ