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
| ||
|
Date: Tue, 25 Aug 2020 18:59:35 +0100 From: Andrew Cooper <amc96@....ac.uk> To: "Luck, Tony" <tony.luck@...el.com>, Andy Lutomirski <luto@...nel.org>, "Christopherson, Sean J" <sean.j.christopherson@...el.com> Cc: Andrew Cooper <andrew.cooper3@...rix.com>, Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Tom Lendacky <thomas.lendacky@....com>, Pu Wen <puwen@...on.cn>, Stephen Hemminger <sthemmin@...rosoft.com>, Sasha Levin <alexander.levin@...rosoft.com>, Dirk Hohndel <dirkhh@...are.com>, Jan Kiszka <jan.kiszka@...mens.com>, Tony W Wang-oc <TonyWWang-oc@...oxin.com>, "H. Peter Anvin" <hpa@...ux.intel.com>, "Mallick, Asit K" <asit.k.mallick@...el.com>, Gordon Tetlow <gordon@...lows.org>, David Kaplan <David.Kaplan@....com>, Andrew Cooper <amc96@....ac.uk> Subject: Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware) On 25/08/2020 18:35, Luck, Tony wrote: >>> Or malicious hypervisor action, and that's a problem. >>> >>> Suppose the hypervisor remaps a GPA used in the SYSCALL gap (e.g. the >>> actual SYSCALL text or the first memory it accesses -- I don't have a >>> TDX spec so I don't know the details). > Is it feasible to defend against a malicious (or buggy) hypervisor? > > Obviously, we can't leave holes that guests can exploit. But the hypervisor > can crash the system no matter how clever TDX is. You have to be more specific about what you mean by "malicious" hypervisor. Nothing can protect against a hypervisor which refuses to schedule the Trusted Domain. The guest cannot protect against availability maliciousness. However, you can use market forces to fix that problem. (I'll take my credit card elsewhere if you don't schedule my VM, etc) Things are more complicated when it comes to integrity or confidentiality of the TD, but the prevailing feeling seems to be "crashing obviously and reliably if something goes wrong is ok". If I've read the TDX spec/whitepaper properly, the main hypervisor can write to all the encrypted pages. This will destroy data, break the MAC, and yields #PF inside the SEAM hypervisor, or the TD when the cache line is next referenced. Cunning timing on behalf of a malicious hypervisor (hitting the SYSCALL gap) will cause the guest's #PF handler to run on a user stack, opening a privilege escalation hole. Whatever you might want to say about the exact integrity/confidentiality expectations, I think "the hypervisor can open a user=>kernel privilege escalation hole inside the TD" is not what people would consider acceptable. On AMD parts, this is why the #VC handler is IST, in an attempt to at least notice this damage and crash. There is no way TDX can get away with requiring #PF to be IST as well. ~Andrew
Powered by blists - more mailing lists