lkml.org 
[lkml]   [2022]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv7 10/14] x86/mm: Avoid load_unaligned_zeropad() stepping into unaccepted memory
    On Sat, Aug 13, 2022 at 09:04:58AM -0700, Andy Lutomirski wrote:
    >
    >
    > On Wed, Aug 3, 2022, at 7:02 AM, Dave Hansen wrote:
    > > On 8/2/22 16:46, Dave Hansen wrote:
    > >> To sum it all up, I'm not happy with the complexity of the page
    > >> acceptance code either but I'm not sure that it's bad tradeoff compared
    > >> to greater #VE complexity or fragility.
    > >>
    > >> Does anyone think we should go back and really reconsider this?
    > >
    > > One other thing I remembered as I re-read my write up on this.
    > >
    > > In the "new" mode, guests never get #VE's for unaccepted memory. They
    > > just exit to the host and can never be reentered. They must be killed.
    > >
    > > In the "old" mode, I _believe_ that the guest always gets a #VE for
    > > non-EPT-present memory. The #VE is basically the same no matter if the
    > > page is unaccepted or if the host goes out and makes a
    > > previously-accepted page non-present.
    > >
    > > One really nasty implication of this "old" mode is that the host can
    > > remove *accepted* pages that are used in the syscall gap. That means
    > > that the #VE handler would need to be of the paranoid variety which
    > > opens up all kinds of other fun.
    > >
    > > * "Old" - #VE's can happen in the syscall gap
    > > * "New" - #VE's happen at better-defined times. Unexpected ones are
    > > fatal.
    > >
    > > There's a third option which I proposed but doesn't yet exist. The TDX
    > > module _could_ separate the behavior of unaccepted memory #VE's and
    > > host-induced #VEs. This way, we could use load_unaligned_zeropad() with
    > > impunity and handle it in the #VE handler. At the same time, the host
    > > would not be allowed to remove accepted memory and cause problems in the
    > > syscall gap. Kinda the best of both worlds.
    > >
    > > But, I'm not sure how valuable that would be now that we have the
    > > (admittedly squirrelly) code to avoid load_unaligned_zeropad() #VE's.
    >
    > How would that be implemented? It would need to track which GPAs *were*
    > accepted across a host-induced unmap/remap cycle. This would involve
    > preventing the host from ever completely removing a secure EPT table
    > without the guest’s help, right?
    >
    > Admittedly this would IMO be better behavior. Is it practical to implement?

    I don't think it is better if you look from host POV. It owns resources of
    the machine and it has to have a way to pull memory from uncooperative TD
    at any point.

    It also would require more complicated private->shared conversion as guest
    has to notify TDX module about the change, not only host as we do now.

    --
    Kiryl Shutsemau / Kirill A. Shutemov

    \
     
     \ /
      Last update: 2022-08-13 22:56    [W:4.968 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site