linux-kernel - Re: 4.15-rc6+ hang

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

Message-ID: <20180108185455.bgfrg62m44hm4mhf@gmail.com>
Date:   Mon, 8 Jan 2018 19:54:55 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Christian Kujau <lists@...dbynature.de>,
        Frank Mehnert <frank.mehnert@...cle.com>
Cc:     Tom Hromatka <tom.hromatka@...cle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dhaval Giani <dhaval.giani@...cle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: 4.15-rc6+ hang


* Christian Kujau <lists@...dbynature.de> wrote:

> On Thu, 4 Jan 2018, Tom Hromatka wrote:
> > > > [    0.000000] ------------[ cut here ]------------
> > > > [    0.000000] XSAVE consistency problem, dumping leaves
> > > I think this is a vbox issue, with virtualbox not exposing all the
> > > xsave state, so that when the kernel adds up the xsave areas, the end
> > > result doesn't match what the total size is reported to be.
> > 
> > It seems probable that this is a VirtualBox issue.  I was
> > able to boot my exact 4.15-rc6+ kernel in qemu-kvm v1.5.3
> > just fine.
> 
> This was discussed on vbox-dev back in May 2017 (see the whole thread for 
> more details):
> 
>  https://www.virtualbox.org/pipermail/vbox-dev/2017-May/014466.html
> 
> Does that help?

So, unless I've managed to confuse myself navigating that horrible email archive 
web interface, the conclusion of that discussion appears to be a workaround: by 
adding 'nofxsave' to the guest kernel boot line the warning+boot-hang goes away?

It would be nice to root cause this bug and offer a more permanent solution. We 
can even apply VirtualBox quirks to the upstream kernel, within reason - i.e. as 
long as it does not get overly ugly and does not impact other uses.

Thanks,

	Ingo