lkml.org 
[lkml]   [2024]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 02/16] KVM: x86/mmu: Introduce a slot flag to zap only slot leafs on slot deletion
    Date
    On Wed, 2024-05-15 at 15:47 -0700, Sean Christopherson wrote:
    > > I didn't gather there was any proof of this. Did you have any hunch either
    > > way?
    >
    > I doubt the guest was able to access memory it shouldn't have been able to
    > access.
    > But that's a moot point, as the bigger problem is that, because we have no
    > idea
    > what's at fault, KVM can't make any guarantees about the safety of such a
    > flag.
    >
    > TDX is a special case where we don't have a better option (we do have other
    > options,
    > they're just horrible).  In other words, the choice is essentially to either:
    >
    >  (a) cross our fingers and hope that the problem is limited to shared memory
    >      with QEMU+VFIO, i.e. and doesn't affect TDX private memory.
    >
    > or
    >
    >  (b) don't merge TDX until the original regression is fully resolved.
    >
    > FWIW, I would love to root cause and fix the failure, but I don't know how
    > feasible
    > that is at this point.

    If we think it is not a security issue, and we don't even know if it can be hit
    for TDX, then I'd be included to go with (a). Especially since we are just
    aiming for the most basic support, and don't have to worry about regressions in
    the classical sense.

    I'm not sure how easy it will be to root cause it at this point. Hopefully Yan
    will be coming online soon. She mentioned some previous Intel effort to
    investigate it. Presumably we would have to start with the old kernel that
    exhibited the issue. If it can still be found...


    \
     
     \ /
      Last update: 2024-05-27 18:29    [W:5.433 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site