On Wed, Mar 31, 2021 at 08:46:18PM -0700, Dave Hansen wrote:
> On 3/31/21 8:28 PM, Andi Kleen wrote:
> >> The hardware (and VMMs and SEAM) have ways of telling the guest kernel
> >> what is supported: CPUID. If it screws up, and the guest gets an
> >> unexpected #VE, so be it.
> > The main reason
On 3/31/21 8:28 PM, Andi Kleen wrote:
>> The hardware (and VMMs and SEAM) have ways of telling the guest kernel
>> what is supported: CPUID. If it screws up, and the guest gets an
>> unexpected #VE, so be it.
> The main reason for disabling stuff is actually that we don't need
> to harden it. All
> The hardware (and VMMs and SEAM) have ways of telling the guest kernel
> what is supported: CPUID. If it screws up, and the guest gets an
> unexpected #VE, so be it.
The main reason for disabling stuff is actually that we don't need
to harden it. All these things are potential attack paths.
>
On 3/31/21 3:28 PM, Kuppuswamy, Sathyanarayanan wrote:
>
> On 3/31/21 3:11 PM, Dave Hansen wrote:
>> On 3/31/21 3:06 PM, Sean Christopherson wrote:
>>> I've no objection to a nice message in the #VE handler. What I'm
>>> objecting to
>>> is sanity checking the CPUID model provided by the TDX
On Wed, Mar 31, 2021, Kuppuswamy, Sathyanarayanan wrote:
>
> On 3/31/21 3:11 PM, Dave Hansen wrote:
> > On 3/31/21 3:06 PM, Sean Christopherson wrote:
> > > I've no objection to a nice message in the #VE handler. What I'm
> > > objecting to
> > > is sanity checking the CPUID model provided by
On 3/31/21 2:49 PM, Dave Hansen wrote:
On 3/31/21 2:09 PM, Kuppuswamy Sathyanarayanan wrote:
As per Guest-Host Communication Interface (GHCI) Specification
for Intel TDX, sec 2.4.1, TDX architecture does not support
MWAIT, MONITOR and WBINVD instructions. So in non-root TDX mode,
if
On 3/31/21 3:11 PM, Dave Hansen wrote:
On 3/31/21 3:06 PM, Sean Christopherson wrote:
I've no objection to a nice message in the #VE handler. What I'm objecting to
is sanity checking the CPUID model provided by the TDX module. If we don't
trust the TDX module to honor the spec, then there
On 3/31/21 3:06 PM, Sean Christopherson wrote:
> I've no objection to a nice message in the #VE handler. What I'm objecting to
> is sanity checking the CPUID model provided by the TDX module. If we don't
> trust the TDX module to honor the spec, then there are a huge pile of things
> that are
On Wed, Mar 31, 2021, Dave Hansen wrote:
> On 3/31/21 2:53 PM, Sean Christopherson wrote:
> > On Wed, Mar 31, 2021, Kuppuswamy Sathyanarayanan wrote:
> >> Changes since v3:
> >> * WARN user if SEAM does not disable MONITOR/MWAIT instruction.
> > Why bother? There are a whole pile of features
On 3/31/21 2:53 PM, Sean Christopherson wrote:
> On Wed, Mar 31, 2021, Kuppuswamy Sathyanarayanan wrote:
>> Changes since v3:
>> * WARN user if SEAM does not disable MONITOR/MWAIT instruction.
> Why bother? There are a whole pile of features that are dictated by the TDX
> module spec.
On Wed, Mar 31, 2021, Kuppuswamy Sathyanarayanan wrote:
> Changes since v3:
> * WARN user if SEAM does not disable MONITOR/MWAIT instruction.
Why bother? There are a whole pile of features that are dictated by the TDX
module spec. MONITOR/MWAIT is about as uninteresting as it gets, e.g.
On 3/31/21 2:09 PM, Kuppuswamy Sathyanarayanan wrote:
> As per Guest-Host Communication Interface (GHCI) Specification
> for Intel TDX, sec 2.4.1, TDX architecture does not support
> MWAIT, MONITOR and WBINVD instructions. So in non-root TDX mode,
> if MWAIT/MONITOR instructions are executed with
As per Guest-Host Communication Interface (GHCI) Specification
for Intel TDX, sec 2.4.1, TDX architecture does not support
MWAIT, MONITOR and WBINVD instructions. So in non-root TDX mode,
if MWAIT/MONITOR instructions are executed with CPL != 0 it will
trigger #UD, and for CPL = 0 case, virtual
13 matches
Mail list logo
