On Sun, Feb 14, 2021 at 11:33 AM Andi Kleen wrote:
>
> On Fri, Feb 12, 2021 at 01:48:36PM -0800, Dave Hansen wrote:
> > On 2/12/21 1:47 PM, Andy Lutomirski wrote:
> > >> What about adding a property to the TD, e.g. via a flag set during TD
> > >> creation,
> > >> that controls whether unaccepted
On Fri, Feb 12, 2021 at 01:48:36PM -0800, Dave Hansen wrote:
> On 2/12/21 1:47 PM, Andy Lutomirski wrote:
> >> What about adding a property to the TD, e.g. via a flag set during TD
> >> creation,
> >> that controls whether unaccepted accesses cause #VE or are, for all
> >> intents and
> >>
On 2/12/21 1:47 PM, Andy Lutomirski wrote:
>> What about adding a property to the TD, e.g. via a flag set during TD
>> creation,
>> that controls whether unaccepted accesses cause #VE or are, for all intents
>> and
>> purposes, fatal? That would allow Linux to pursue treating EPT #VEs for
>>
On Fri, Feb 12, 2021 at 1:37 PM Sean Christopherson wrote:
>
> On Fri, Feb 12, 2021, Dave Hansen wrote:
> > On 2/12/21 12:54 PM, Sean Christopherson wrote:
> > > Ah, I see what you're thinking.
> > >
> > > Treating an EPT #VE as fatal was also considered as an option. IIUC it
> > > was
> > >
On Fri, Feb 12, 2021, Dave Hansen wrote:
> On 2/12/21 12:54 PM, Sean Christopherson wrote:
> > Ah, I see what you're thinking.
> >
> > Treating an EPT #VE as fatal was also considered as an option. IIUC it was
> > thought that finding every nook and cranny that could access a page, without
> >
On 2/12/21 12:54 PM, Sean Christopherson wrote:
> Ah, I see what you're thinking.
>
> Treating an EPT #VE as fatal was also considered as an option. IIUC it was
> thought that finding every nook and cranny that could access a page, without
> forcing the kernel to pre-accept huge swaths of
On Fri, Feb 12, 2021, Dave Hansen wrote:
> On 2/12/21 12:37 PM, Sean Christopherson wrote:
> > There needs to be a mechanism for lazy/deferred/on-demand acceptance of
> > pages.
> > E.g. pre-accepting every page in a VM with hundreds of GB of memory will be
> > ridiculously slow.
> >
> > #VE is
On 2/12/21 12:37 PM, Sean Christopherson wrote:
> There needs to be a mechanism for lazy/deferred/on-demand acceptance of pages.
> E.g. pre-accepting every page in a VM with hundreds of GB of memory will be
> ridiculously slow.
>
> #VE is the best option to do that:
>
> - Relatively sane
On Fri, Feb 12, 2021, Andy Lutomirski wrote:
>
> > On Feb 12, 2021, at 12:06 PM, Sean Christopherson wrote:
> >
> > On Fri, Feb 12, 2021, Andy Lutomirski wrote:
> >>> On Fri, Feb 5, 2021 at 3:39 PM Kuppuswamy Sathyanarayanan
> >>> wrote:
> >>>
> >>> From: "Kirill A. Shutemov"
> >>>
> >>>
On Fri, Feb 12, 2021, Dave Hansen wrote:
> On 2/12/21 12:06 PM, Sean Christopherson wrote:
> >> What happens if the guest attempts to access a secure GPA that is not
> >> ACCEPTed? For example, suppose the VMM does THH.MEM.PAGE.REMOVE on a
> >> secure
> >> address and the guest accesses it, via
> On Feb 12, 2021, at 12:06 PM, Sean Christopherson wrote:
>
> On Fri, Feb 12, 2021, Andy Lutomirski wrote:
>>> On Fri, Feb 5, 2021 at 3:39 PM Kuppuswamy Sathyanarayanan
>>> wrote:
>>>
>>> From: "Kirill A. Shutemov"
>>>
>>> The TDX module injects #VE exception to the guest TD in cases of
On 2/12/21 12:06 PM, Sean Christopherson wrote:
>> What happens if the guest attempts to access a secure GPA that is not
>> ACCEPTed? For example, suppose the VMM does THH.MEM.PAGE.REMOVE on a secure
>> address and the guest accesses it, via instruction fetch or data access.
>> What happens?
>
On Fri, Feb 12, 2021, Andy Lutomirski wrote:
> On Fri, Feb 5, 2021 at 3:39 PM Kuppuswamy Sathyanarayanan
> wrote:
> >
> > From: "Kirill A. Shutemov"
> >
> > The TDX module injects #VE exception to the guest TD in cases of
> > disallowed instructions, disallowed MSR accesses and subset of CPUID
>
On Fri, Feb 5, 2021 at 3:39 PM Kuppuswamy Sathyanarayanan
wrote:
>
> From: "Kirill A. Shutemov"
>
> The TDX module injects #VE exception to the guest TD in cases of
> disallowed instructions, disallowed MSR accesses and subset of CPUID
> leaves. Also, it's theoretically possible for CPU to
On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote:
> More details on cases where #VE exceptions are allowed/not-allowed:
>
> The #VE exception do not occur in the paranoid entry paths, like NMIs.
> While other operations during an NMI might cause #VE, these are in the
> NMI code that can handle
On 2/8/21 8:59 AM, Peter Zijlstra wrote:
'cute', might be useful to have that mentioned somewhere.
we will add a note for it in comments.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
On Mon, Feb 08, 2021 at 08:46:23AM -0800, Sean Christopherson wrote:
> On Mon, Feb 08, 2021, Peter Zijlstra wrote:
> > On Mon, Feb 08, 2021 at 08:23:01AM -0800, Andi Kleen wrote:
> > > > > +#ifdef CONFIG_INTEL_TDX_GUEST
> > > > > +DEFINE_IDTENTRY(exc_virtualization_exception)
> > > > > +{
> > > >
On Mon, Feb 08, 2021, Peter Zijlstra wrote:
> On Mon, Feb 08, 2021 at 08:23:01AM -0800, Andi Kleen wrote:
> > > > +#ifdef CONFIG_INTEL_TDX_GUEST
> > > > +DEFINE_IDTENTRY(exc_virtualization_exception)
> > > > +{
> > > > + struct ve_info ve;
> > > > + int ret;
> > > > +
> > > > +
> > > So what happens if NMI happens here, and triggers a nested #VE ?
> >
> > Yes that's a gap. We should probably bail out and reexecute the original
> > instruction. The VE handler would need to set a flag for that.
> >
> > Or alternatively the NMI always gets the VE information and puts
> >
On Mon, Feb 08, 2021 at 08:23:01AM -0800, Andi Kleen wrote:
> > Which is supposedly then set up to avoid #VE during the syscall gap,
> > yes? Which then results in #VE not having to be IST.
>
> Yes that is currently true because all memory is pre-accepted.
>
> If we ever do lazy accept we would
> Which is supposedly then set up to avoid #VE during the syscall gap,
> yes? Which then results in #VE not having to be IST.
Yes that is currently true because all memory is pre-accepted.
If we ever do lazy accept we would need to make sure the memory accessed in
the syscall gap is already
On Fri, Feb 05, 2021 at 03:38:22PM -0800, Kuppuswamy Sathyanarayanan wrote:
> From: "Kirill A. Shutemov"
>
> The TDX module injects #VE exception to the guest TD in cases of
> disallowed instructions, disallowed MSR accesses and subset of CPUID
> leaves. Also, it's theoretically possible for CPU
From: "Kirill A. Shutemov"
The TDX module injects #VE exception to the guest TD in cases of
disallowed instructions, disallowed MSR accesses and subset of CPUID
leaves. Also, it's theoretically possible for CPU to inject #VE
exception on EPT violation, but the TDX module makes sure this does
not
23 matches
Mail list logo
