linux-kernel - Re: kexec reboot fails with extra wbinvd introduced for AME SME

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:   Wed, 17 Jan 2018 19:00:47 -0800
From:   Arjan van de Ven <arjan@...ux.intel.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Young <dyoung@...hat.com>
Cc:     Yu Chen <yu.c.chen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Juergen Gross <jgross@...e.com>,
        Tony Luck <tony.luck@...el.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Borislav Petkov <bp@...en8.de>,
        Rui Zhang <rui.zhang@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        Kexec Mailing List <kexec@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ebiederm@...hat.com, Tom Lendacky <thomas.lendacky@....com>,
        Baoquan He <bhe@...hat.com>
Subject: Re: kexec reboot fails with extra wbinvd introduced for AME SME

> Does anybody have any other ideas?

the only other weird case that comes to mind; what happens if there's a line dirty in the caches,
but the memory is now mapped uncached. (Which could happen if kexec does muck with  MTRRs, CR0 or other similar
things in weird ways)... not sure what happens in CPU, a machine check for cache inclusion violations
is not beyond the imagination and might be lethal

this would explain a kexec specific angle versus general normal (but rare) use of wbinvd.

other weird case could be cached mmio (not common, but some gpus and the like can do it)
with iommu/VT-D in the middle, and during kexec VT-D shutting
down the iommu before the wbinvd. This would be... highly odd... but this report already is in highly odd space.