linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).