From: Michael Ellerman <mpe@ellerman.id.au>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: oss-security@lists.openwall.com,
"debian-powerpc@lists.debian.org"
<debian-powerpc@lists.debian.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
Date: Wed, 27 Oct 2021 16:30:44 +1100 [thread overview]
Message-ID: <878ryfavaz.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <05b88724-90b6-a38a-bb3b-7392f85c1934@physik.fu-berlin.de>
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> writes:
> Hi Michael!
Hi Adrian,
Thanks for testing ...
>> The Linux kernel for powerpc since v5.2 has a bug which allows a
>> malicious KVM guest to crash the host, when the host is running on
>> Power8.
>>
>> Only machines using Linux as the hypervisor, aka. KVM, powernv or bare
>> metal, are affected by the bug. Machines running PowerVM are not
>> affected.
>>
>> The bug was introduced in:
>>
>> 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
>>
>> Which was first released in v5.2.
>>
>> The upstream fix is:
>>
>> cdeb5d7d890e ("KVM: PPC: Book3S HV: Make idle_kvm_start_guest() return 0 if it went to guest")
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cdeb5d7d890e14f3b70e8087e745c4a6a7d9f337
>>
>> Which will be included in the v5.16 release.
>
> I have tested these patches against 5.14 but it seems the problem [1] still remains for me
> for big-endian guests. I built a patched kernel yesterday, rebooted the KVM server and let
> the build daemons do their work over night.
>
> When I got up this morning, I noticed the machine was down, so I checked the serial console
> via IPMI and saw the same messages again as reported in [1]:
>
> [41483.963562] watchdog: BUG: soft lockup - CPU#104 stuck for 25521s! [migration/104:175]
> [41507.963307] watchdog: BUG: soft lockup - CPU#104 stuck for 25544s! [migration/104:175]
> [41518.311200] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [41518.311216] rcu: 136-...0: (135 ticks this GP) idle=242/1/0x4000000000000000 softirq=32031/32033 fqs=2729959
> [41547.962882] watchdog: BUG: soft lockup - CPU#104 stuck for 25581s! [migration/104:175]
> [41571.962627] watchdog: BUG: soft lockup - CPU#104 stuck for 25603s! [migration/104:175]
> [41581.330530] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [41581.330546] rcu: 136-...0: (135 ticks this GP) idle=242/1/0x4000000000000000 softirq=32031/32033 fqs=2736378
> [41611.962202] watchdog: BUG: soft lockup - CPU#104 stuck for 25641s! [migration/104:175]
> [41635.961947] watchdog: BUG: soft lockup - CPU#104 stuck for 25663s! [migration/104:175]
> [41644.349859] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [41644.349876] rcu: 136-...0: (135 ticks this GP) idle=242/1/0x4000000000000000 softirq=32031/32033 fqs=2742753
> [41671.961564] watchdog: BUG: soft lockup - CPU#104 stuck for 25697s! [migration/104:175]
> [41695.961309] watchdog: BUG: soft lockup - CPU#104 stuck for 25719s! [migration/104:175]
> [41707.369190] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [41707.369206] rcu: 136-...0: (135 ticks this GP) idle=242/1/0x4000000000000000 softirq=32031/32033 fqs=2749151
> [41735.960884] watchdog: BUG: soft lockup - CPU#104 stuck for 25756s! [migration/104:175]
> [41759.960629] watchdog: BUG: soft lockup - CPU#104 stuck for 25778s! [migration/104:175]
> [41770.388520] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [41770.388548] rcu: 136-...0: (135 ticks this GP) idle=242/1/0x4000000000000000 softirq=32031/32033 fqs=2755540
> [41776.076307] rcu: rcu_sched kthread timer wakeup didn't happen for 1423 jiffies! g49897 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
> [41776.076327] rcu: Possible timer handling issue on cpu=32 timer-softirq=1056014
> [41776.076336] rcu: rcu_sched kthread starved for 1424 jiffies! g49897 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=32
> [41776.076350] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
> [41776.076360] rcu: RCU grace-period kthread stack dump:
> [41776.076434] rcu: Stack dump where RCU GP kthread last ran:
> [41783.960374] watchdog: BUG: soft lockup - CPU#104 stuck for 25801s! [migration/104:175]
> [41807.960119] watchdog: BUG: soft lockup - CPU#104 stuck for 25823s! [migration/104:175]
> [41831.959864] watchdog: BUG: soft lockup - CPU#104 stuck for 25846s! [migration/104:175]
> [41833.407851] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [41833.407868] rcu: 136-...0: (135 ticks this GP) idle=242/1/0x4000000000000000 softirq=32031/32033 fqs=2760381
> [41863.959524] watchdog: BUG: soft lockup - CPU#104 stuck for 25875s! [migration/104:175]
>
> It seems that in this case, it was the testsuite of the git package [2] that triggered the bug. As you
> can see from the overview, the git package has been in the building state for 8 hours meaning the
> build server crashed and is no longer giving feedback to the database.
OK, that sucks.
I did test the repro case you gave me before (in the bugzilla), which
was building glibc, that passes for me with a patched host.
I guess we have yet another bug.
I tried the following in a debian BE VM and it completed fine:
$ dget -u http://ftp.debian.org/debian/pool/main/g/git/git_2.33.1-1.dsc
$ sbuild -d sid --arch=powerpc --no-arch-all git_2.33.1-1.dsc
Same for ppc64.
And I also tried both at once, repeatedly in a loop.
I guess it's something more complicated.
What exact host/guest kernel versions and configs are you running?
cheers
next prev parent reply other threads:[~2021-10-27 5:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 11:18 Linux kernel: powerpc: KVM guest can trigger host crash on Power8 Michael Ellerman
2021-10-26 8:48 ` John Paul Adrian Glaubitz
2021-10-27 5:29 ` Nicholas Piggin
2021-10-27 5:30 ` Michael Ellerman [this message]
2021-10-27 10:03 ` John Paul Adrian Glaubitz
2021-10-27 11:06 ` Michael Ellerman
2021-10-27 11:09 ` John Paul Adrian Glaubitz
2021-10-28 6:39 ` Michael Ellerman
2021-10-28 11:20 ` John Paul Adrian Glaubitz
2021-10-28 14:05 ` John Paul Adrian Glaubitz
2021-10-28 14:15 ` John Paul Adrian Glaubitz
2021-11-01 17:36 ` Michal Suchánek
2021-10-29 0:41 ` Nicholas Piggin
2021-10-29 12:33 ` John Paul Adrian Glaubitz
2021-11-01 17:43 ` Michal Suchánek
2021-10-30 7:19 ` John Paul Adrian Glaubitz
2021-11-01 6:53 ` Michael Ellerman
2021-11-01 7:37 ` John Paul Adrian Glaubitz
2021-11-01 17:20 ` John Paul Adrian Glaubitz
2022-01-04 13:00 ` John Paul Adrian Glaubitz
2022-01-06 10:58 ` Michael Ellerman
2022-01-07 11:20 ` John Paul Adrian Glaubitz
2022-01-09 22:17 ` John Paul Adrian Glaubitz
2022-01-13 0:17 ` John Paul Adrian Glaubitz
2022-01-26 20:21 ` John Paul Adrian Glaubitz
2022-01-27 15:50 ` Mike
2021-10-28 13:52 ` John Paul Adrian Glaubitz
2021-10-28 14:00 ` John Paul Adrian Glaubitz
2021-10-28 3:58 ` [oss-security] " Salvatore Bonaccorso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878ryfavaz.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=debian-powerpc@lists.debian.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=oss-security@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).