linux-kernel - Re: [PATCH v10 02/14] KVM: Cache as_id in kvm_memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 7 Jul 2020 16:38:23 -0400
From:   Peter Xu <peterx@...hat.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        Andrew Jones <drjones@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        Kevin Tian <kevin.tian@...el.com>
Subject: Re: [PATCH v10 02/14] KVM: Cache as_id in kvm_memory_slot

On Tue, Jul 07, 2020 at 01:26:23PM -0700, Sean Christopherson wrote:
> On Tue, Jul 07, 2020 at 04:15:08PM -0400, Peter Xu wrote:
> > On Tue, Jul 07, 2020 at 12:56:58PM -0700, Sean Christopherson wrote:
> > > > > It's a single line of code, and there's more than one
> > > > > "shouldn't" in the above.
> > > > 
> > > > If you want, I can both set it and add the comment.  Thanks,
> > > 
> > > Why bother with the comment?  It'd be wrong in the sense that the as_id is
> > > always valid/accurate, even if npages == 0.
> > 
> > Sorry I'm confused.. when npages==0, why as_id field is meaningful?  Even if
> > the id field is meaningless after the slot is successfully removed, or am I
> > wrong?
> > 
> > My understanding is that after your dynamic slot work, we'll only have at most
> > one extra memslot that was just removed, and that slot should be meaningless as
> > a whole.  Feel free to correct me.
> 
> Your understanding is correct.  What I'm saying is that if something goes
> awry and the memslots need to be debugged, having accurate info for that one
> defunct memslot could be helpful, if only to not confuse a future debugger
> that doesn't fully understand memslots or address spaces.  Sure, it could be
> manually added back in for debug, but it's literally a single line of code
> to carry and it avoids the need for a special comment.

Sure, will do.  But again, I hope you allow me to add at least some comment.
To me, it's still weird to set these in a destroying memslot...

-- 
Peter Xu