linux-kernel - CONFIG_JUMP_LABEL=y on 32-bit x86 leads to intermittent qemu crashes

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>] [day] [month] [year] [list]

Message-ID: <CAHmME9pBFvcm7F=-Sxc5apU6JuE=1X=Omza_eMKL5qyuisTJ3g@mail.gmail.com>
Date:   Thu, 2 Jan 2020 15:55:11 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     QEMU Developers <qemu-devel@...gnu.org>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: CONFIG_JUMP_LABEL=y on 32-bit x86 leads to intermittent qemu crashes

Hi,

Here's an interesting crash I've seen pop up since enabling CONFIG_JUMP_LABEL=y:

[    4.716238] EIP: secure_tcp_seq+0x1e/0xa0^M
[    4.716238] Code: c1 e8 46 90 fb ff eb a2 8d 74 26 00 55 89 e5 83
ec 18 89 75 f8 89 c6 0f b7 45 08 89 5d f4 0f b7 d9 89 7d fc 89 d7 89
45 ec 3e <8d> 74 26 00 8b 4d
ec c1 e3 10 89 fa c7 04 24 d0 e3 36 c1 89 f0 09^M
[    4.716238] EAX: 000090bc EBX: 00005114 ECX: 00005114 EDX: 01f1a8c0^M
[    4.716238] ESI: 02f1a8c0 EDI: 01f1a8c0 EBP: c010bb88 ESP: c010bb70^M
[    4.716238] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00000282^M
[    4.716238] CR0: 80050033 CR2: bfcd7fb0 CR3: 00380000 CR4: 00000690^M
[    4.716238] Call Trace:^M
[    4.716238]  <SOFTIRQ>^M
[    4.716238]  tcp_v4_init_seq+0x3d/0x50^M
[    4.716238]  tcp_conn_request+0x35d/0x926^M
[    4.716238]  ? fib6_table_lookup+0xb5/0x210^M
[    4.716238]  ? ip_route_input_slow+0x864/0x900^M
...

It looks like this is:
secure_tcp_seq ->
  net_secret_init->
    net_get_random_once(&net_secret, sizeof(net_secret))
        get_random_once(&net_secret, sizeof(net_secret))
          DO_ONCE(get_random_bytes(&net_secret, sizeof(net_secret)))

Which then expands to the usual static_key logic.

I was only able to reproduce this when the host system running
`qemu-system-i386 -m 256M -smp 4 -cpu coreduo -machine q35` is under
considerable load.

Is there a TCG issue with how it handles the dynamic patching debug
instructions?

Jason