linux-kernel - Re: [PATCH v10 046/108] KVM: Add flags to struct kvm_gfn

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2938fd03dc253e83ec6528dfa2767701738647c9.camel@intel.com>
Date:   Thu, 15 Dec 2022 22:41:27 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "isaku.yamahata@...il.com" <isaku.yamahata@...il.com>
CC:     "Christopherson,, Sean" <seanjc@...gle.com>,
        "Shahar, Sagi" <sagis@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Aktas, Erdem" <erdemaktas@...gle.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        "dmatlack@...gle.com" <dmatlack@...gle.com>
Subject: Re: [PATCH v10 046/108] KVM: Add flags to struct kvm_gfn_range

On Thu, 2022-12-15 at 14:10 -0800, Isaku Yamahata wrote:
> On Wed, Dec 14, 2022 at 10:51:31AM +0000,
> "Huang, Kai" <kai.huang@...el.com> wrote:
> 
> > On Sat, 2022-10-29 at 23:22 -0700, isaku.yamahata@...el.com wrote:
> > > From: Isaku Yamahata <isaku.yamahata@...el.com>
> > > 
> > > kvm_unmap_gfn_range() needs to know the reason of the callback for TDX.
> > > mmu notifier, set memattr ioctl or restrictedmem notifier.  Based on the
> > > reason, TDX changes the behavior.  For mmu notifier, it's the operation on
> > > shared memory slot to zap shared PTE.  For set memattr, private<->shared
> > > conversion, zap the original PTE.  For restrictedmem, it's a hint that TDX
> > > can ignore.
> > 
> > Could you elaborate why restricted memfd notifier can be ignored? IIUC if
> > userspace punch a hole, the pages within the hole will be de-allocated.  So why
> > can such notifier be ignored?
> 
> Because set-memory-attribute ioctl is expected to follow the callback from
> restrictedmem.  So set memory attributes can do de-allocation. I wanted to avoid
> zapping twice.

Even this is true, the punch hole can be done alone w/o being followed by
set_memory_attribute(), correct?  Your explanation doesn't seem to be
reasonable?

At least, you need to explain the semantics of how to use "punch hole" and
set_memory_attributes() clearly in the changelog.  Otherwise it's hard for
people to review.