Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-30 Thread Linus Torvalds
On Sun, Aug 30, 2020 at 8:37 AM Andy Lutomirski wrote: > > There's no such thing as "just" using an IST. Using IST opens a huge > can of works due to its recursion issues. I absolutely despise all the x86 "indirect system structures". They are horrible garbage. IST is only yet another example

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-30 Thread Andy Lutomirski
On Wed, Aug 26, 2020 at 12:16 PM Sean Christopherson wrote: > > On Tue, Aug 25, 2020 at 10:28:53AM -0700, Andy Lutomirski wrote: > > On Tue, Aug 25, 2020 at 10:19 AM Sean Christopherson > > wrote: > > > One thought would be to have the TDX module (thing that runs in SEAM and > > > sits between

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-26 Thread Sean Christopherson
On Tue, Aug 25, 2020 at 10:28:53AM -0700, Andy Lutomirski wrote: > On Tue, Aug 25, 2020 at 10:19 AM Sean Christopherson > wrote: > > One thought would be to have the TDX module (thing that runs in SEAM and > > sits between the VMM and the guest) provide a TDCALL (hypercall from guest > > to TDX

RE: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Thomas Gleixner
On Tue, Aug 25 2020 at 17:35, Tony Luck 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

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Dave Hansen
On 8/25/20 10:59 AM, Andrew Cooper wrote: > 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. I think

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Andrew Cooper
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

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Andy Lutomirski
On Tue, Aug 25, 2020 at 10:36 AM 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

RE: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Luck, Tony
> > 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

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Andy Lutomirski
On Tue, Aug 25, 2020 at 10:19 AM Sean Christopherson wrote: > > On Tue, Aug 25, 2020 at 09:49:05AM -0700, Andy Lutomirski wrote: > > On Mon, Aug 24, 2020 at 9:40 PM Sean Christopherson > > wrote: > > > > > > +Andy > > > > > > On Mon, Aug 24, 2020 at 02:52:01PM +0100, Andrew Cooper wrote: > > > >

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Sean Christopherson
On Tue, Aug 25, 2020 at 09:49:05AM -0700, Andy Lutomirski wrote: > On Mon, Aug 24, 2020 at 9:40 PM Sean Christopherson > wrote: > > > > +Andy > > > > On Mon, Aug 24, 2020 at 02:52:01PM +0100, Andrew Cooper wrote: > > > And to help with coordination, here is something prepared (slightly) > > >

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Andy Lutomirski
On Mon, Aug 24, 2020 at 9:40 PM Sean Christopherson wrote: > > +Andy > > On Mon, Aug 24, 2020 at 02:52:01PM +0100, Andrew Cooper wrote: > > And to help with coordination, here is something prepared (slightly) > > earlier. > > > >

Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-25 Thread Dave Hansen
On 8/24/20 9:39 PM, Sean Christopherson wrote: > +Andy > > On Mon, Aug 24, 2020 at 02:52:01PM +0100, Andrew Cooper wrote: >> And to help with coordination, here is something prepared (slightly) >> earlier. >> >>

TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)

2020-08-24 Thread Sean Christopherson
+Andy On Mon, Aug 24, 2020 at 02:52:01PM +0100, Andrew Cooper wrote: > And to help with coordination, here is something prepared (slightly) > earlier. > > https://docs.google.com/document/d/1hWejnyDkjRRAW-JEsRjA5c9CKLOPc6VKJQsuvODlQEI/edit?usp=sharing > > This identifies the problems from