From: Ira Weiny <ira.weiny@intel.com>
To: Paul Moore <paul@paul-moore.com>, Mike Rapoport <rppt@kernel.org>
Cc: Ackerley Tng <ackerleytng@google.com>,
<linux-security-module@vger.kernel.org>,
<selinux@vger.kernel.org>, <kvm@vger.kernel.org>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<x86@kernel.org>, <linux-fsdevel@vger.kernel.org>, <aik@amd.com>,
<ajones@ventanamicro.com>, <akpm@linux-foundation.org>,
<amoorthy@google.com>, <anthony.yznaga@oracle.com>,
<anup@brainfault.org>, <aou@eecs.berkeley.edu>,
<bfoster@redhat.com>, <binbin.wu@linux.intel.com>,
<brauner@kernel.org>, <catalin.marinas@arm.com>,
<chao.p.peng@intel.com>, <chenhuacai@kernel.org>,
<dave.hansen@intel.com>, <david@redhat.com>,
<dmatlack@google.com>, <dwmw@amazon.co.uk>,
<erdemaktas@google.com>, <fan.du@intel.com>, <fvdl@google.com>,
<graf@amazon.com>, <haibo1.xu@intel.com>, <hch@infradead.org>,
<hughd@google.com>, <ira.weiny@intel.com>,
<isaku.yamahata@intel.com>, <jack@suse.cz>, <james.morse@arm.com>,
<jarkko@kernel.org>, <jgg@ziepe.ca>, <jgowans@amazon.com>,
<jhubbard@nvidia.com>, <jroedel@suse.de>, <jthoughton@google.com>,
<jun.miao@intel.com>, <kai.huang@intel.com>, <keirf@google.com>,
<kent.overstreet@linux.dev>, <kirill.shutemov@intel.com>,
<liam.merwick@oracle.com>, <maciej.wieczor-retman@intel.com>,
<mail@maciej.szmigiero.name>, <maz@kernel.org>, <mic@digikod.net>,
<michael.roth@amd.com>, <mpe@ellerman.id.au>,
<muchun.song@linux.dev>, <nikunj@amd.com>, <nsaenz@amazon.es>,
<oliver.upton@linux.dev>, <palmer@dabbelt.com>,
<pankaj.gupta@amd.com>, <paul.walmsley@sifive.com>,
<pbonzini@redhat.com>, <pdurrant@amazon.co.uk>,
<peterx@redhat.com>, <pgonda@google.com>, <pvorel@suse.cz>,
<qperret@google.com>, <quic_cvanscha@quicinc.com>,
<quic_eberman@quicinc.com>, <quic_mnalajal@quicinc.com>,
<quic_pderrin@quicinc.com>, <quic_pheragu@quicinc.com>,
<quic_svaddagi@quicinc.com>, <quic_tsoni@quicinc.com>,
<richard.weiyang@gmail.com>, <rick.p.edgecombe@intel.com>,
<rientjes@google.com>, <roypat@amazon.co.uk>, <seanjc@google.com>,
<shuah@kernel.org>, <steven.price@arm.com>,
<steven.sistare@oracle.com>, <suzuki.poulose@arm.com>,
<tabba@google.com>, <thomas.lendacky@amd.com>,
<vannapurve@google.com>, <vbabka@suse.cz>,
<viro@zeniv.linux.org.uk>, <vkuznets@redhat.com>,
<wei.w.wang@intel.com>, <will@kernel.org>, <willy@infradead.org>,
<xiaoyao.li@intel.com>, <yan.y.zhao@intel.com>,
<yilun.xu@intel.com>, <yuzenghui@huawei.com>,
<zhiquan1.li@intel.com>
Subject: Re: [PATCH 1/2] fs: Provide function that allocates a secure anonymous inode
Date: Fri, 6 Jun 2025 10:09:11 -0500 [thread overview]
Message-ID: <68430497a6fbf_19ff672943@iweiny-mobl.notmuch> (raw)
In-Reply-To: <CAHC9VhR3dKsXYAxY+1Ujr4weO=iBHMPHsJ3-8f=wM5q_oo81wA@mail.gmail.com>
Paul Moore wrote:
> On Thu, Jun 5, 2025 at 1:50 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > secretmem always had S_PRIVATE set because alloc_anon_inode() clears it
> > anyway and this patch does not change it.
>
> Yes, my apologies, I didn't look closely enough at the code.
>
> > I'm just thinking that it makes sense to actually allow LSM/SELinux
> > controls that S_PRIVATE bypasses for both secretmem and guest_memfd.
>
> It's been a while since we added the anon_inode hooks so I'd have to
> go dig through the old thread to understand the logic behind marking
> secretmem S_PRIVATE, especially when the
> anon_inode_make_secure_inode() function cleared it. It's entirely
> possible it may have just been an oversight.
I'm jumping in where I don't know what I'm talking about...
But my reading of the S_PRIVATE flag is that the memory can't be mapped by
user space. So for guest_memfd() we need !S_PRIVATE because it is
intended to be mapped by user space. So we want the secure checks.
I think secretmem is the same.
Do I have that right?
Ira
[snip]
next prev parent reply other threads:[~2025-06-06 15:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-02 19:17 [PATCH 0/2] Use guest mem inodes instead of anonymous inodes Ackerley Tng
2025-06-02 19:17 ` [PATCH 1/2] fs: Provide function that allocates a secure anonymous inode Ackerley Tng
2025-06-02 20:02 ` David Hildenbrand
2025-06-03 4:52 ` Christoph Hellwig
2025-06-03 10:40 ` Shivank Garg
2025-06-04 7:59 ` Mike Rapoport
2025-06-04 21:13 ` Paul Moore
2025-06-05 5:49 ` Mike Rapoport
2025-06-05 18:23 ` Paul Moore
2025-06-06 15:09 ` Ira Weiny [this message]
2025-06-16 13:00 ` Shivank Garg
2025-06-19 5:36 ` Mike Rapoport
2025-06-04 8:02 ` Christian Brauner
2025-06-02 19:17 ` [PATCH 2/2] KVM: guest_memfd: Use guest mem inodes instead of anonymous inodes Ackerley Tng
2025-06-02 20:13 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=68430497a6fbf_19ff672943@iweiny-mobl.notmuch \
--to=ira.weiny@intel.com \
--cc=ackerleytng@google.com \
--cc=aik@amd.com \
--cc=ajones@ventanamicro.com \
--cc=akpm@linux-foundation.org \
--cc=amoorthy@google.com \
--cc=anthony.yznaga@oracle.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=bfoster@redhat.com \
--cc=binbin.wu@linux.intel.com \
--cc=brauner@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=chao.p.peng@intel.com \
--cc=chenhuacai@kernel.org \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=dmatlack@google.com \
--cc=dwmw@amazon.co.uk \
--cc=erdemaktas@google.com \
--cc=fan.du@intel.com \
--cc=fvdl@google.com \
--cc=graf@amazon.com \
--cc=haibo1.xu@intel.com \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=isaku.yamahata@intel.com \
--cc=jack@suse.cz \
--cc=james.morse@arm.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=jgowans@amazon.com \
--cc=jhubbard@nvidia.com \
--cc=jroedel@suse.de \
--cc=jthoughton@google.com \
--cc=jun.miao@intel.com \
--cc=kai.huang@intel.com \
--cc=keirf@google.com \
--cc=kent.overstreet@linux.dev \
--cc=kirill.shutemov@intel.com \
--cc=kvm@vger.kernel.org \
--cc=liam.merwick@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=maciej.wieczor-retman@intel.com \
--cc=mail@maciej.szmigiero.name \
--cc=maz@kernel.org \
--cc=mic@digikod.net \
--cc=michael.roth@amd.com \
--cc=mpe@ellerman.id.au \
--cc=muchun.song@linux.dev \
--cc=nikunj@amd.com \
--cc=nsaenz@amazon.es \
--cc=oliver.upton@linux.dev \
--cc=palmer@dabbelt.com \
--cc=pankaj.gupta@amd.com \
--cc=paul.walmsley@sifive.com \
--cc=paul@paul-moore.com \
--cc=pbonzini@redhat.com \
--cc=pdurrant@amazon.co.uk \
--cc=peterx@redhat.com \
--cc=pgonda@google.com \
--cc=pvorel@suse.cz \
--cc=qperret@google.com \
--cc=quic_cvanscha@quicinc.com \
--cc=quic_eberman@quicinc.com \
--cc=quic_mnalajal@quicinc.com \
--cc=quic_pderrin@quicinc.com \
--cc=quic_pheragu@quicinc.com \
--cc=quic_svaddagi@quicinc.com \
--cc=quic_tsoni@quicinc.com \
--cc=richard.weiyang@gmail.com \
--cc=rick.p.edgecombe@intel.com \
--cc=rientjes@google.com \
--cc=roypat@amazon.co.uk \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=selinux@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=steven.price@arm.com \
--cc=steven.sistare@oracle.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=thomas.lendacky@amd.com \
--cc=vannapurve@google.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=vkuznets@redhat.com \
--cc=wei.w.wang@intel.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
--cc=yan.y.zhao@intel.com \
--cc=yilun.xu@intel.com \
--cc=yuzenghui@huawei.com \
--cc=zhiquan1.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).