Re: [PATCHv11 6/9] efi/unaccepted: Avoid load_unaligned_zeropad() stepping into unaccepted memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 17 May 2023 at 00:00, Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>
> On 5/16/23 14:52, Kirill A. Shutemov wrote:
> > On Tue, May 16, 2023 at 01:03:32PM -0700, Dave Hansen wrote:
> >> On 5/16/23 11:35, Ard Biesheuvel wrote:
> >>>>> Does this mean that the kernel maps memory before accepting it? As
> >>>>> otherwise, I would assume that such an access would page fault inside
> >>>>> the guest before triggering an exception related to the unaccepted
> >>>>> state.
> >>>> Yes, the kernel maps memory before accepting it (modulo things like
> >>>> DEBUG_PAGEALLOC).
> >>>>
> >>> OK, and so the architecture stipulates that prefetching or other
> >>> speculative accesses must never deliver exceptions to the host
> >>> regarding such ranges?
> >> I don't know of anywhere that this is explicitly written.  It's probably
> >> implicit _somewhere_ in the reams of VMX/TDX and base SDM docs, but heck
> >> if I know where it is. 😄
> > It is not specific to TDX: on x86 (and all architectures with precise
> > exceptions) exception handling is delayed until instruction retirement and
> > will not happen if speculation turned out to be wrong. And prefetching
> > never generates exceptions.
>
> Not to be Debbie Downer too much here, but it's *totally* possible for
> speculative execution to go read memory that causes you to machine
> check.  We've had such bugs in Linux.
>
> We just happen to be lucky in this case that the unaccepted memory
> exceptions don't generate machine checks *AND* TDX hardware does not
> machine check on speculative accesses that would _just_ violate TDX
> security properties.
>
> You're right for normal, sane exceptions, though.

Same thing on ARM, although I'd have to check their RME stuff in more
detail to see how it behaves in this particular case.

But Kyrill is right that it doesn't really matter for the logic in
this patch - it just accepts some additional pages. The relevant
difference between implementations will likely be whether unaccepted
memory gets mapped beforehand in the first place, but we'll deal with
that once we have to.

As long as we only accept memory that appears in the bitmap as
'unaccepted', this kind of rounding seems safe and reasonable to me.

Reviewed-by: Ard Biesheuvel <ardb@xxxxxxxxxx>





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux