2019-05-19 15:08:55 +03:00
// SPDX-License-Identifier: GPL-2.0-only
2007-05-11 09:23:11 +04:00
/*
* fs / anon_inodes . c
*
* Copyright ( C ) 2007 Davide Libenzi < davidel @ xmailserver . org >
*
* Thanks to Arnd Bergmann for code review and suggestions .
* More changes for Thomas Gleixner suggestions .
*
*/
2009-10-04 16:11:37 +04:00
# include <linux/cred.h>
2007-05-11 09:23:11 +04:00
# include <linux/file.h>
# include <linux/poll.h>
2009-10-04 16:11:37 +04:00
# include <linux/sched.h>
2007-05-11 09:23:11 +04:00
# include <linux/init.h>
# include <linux/fs.h>
# include <linux/mount.h>
# include <linux/module.h>
# include <linux/kernel.h>
# include <linux/magic.h>
# include <linux/anon_inodes.h>
2019-03-25 19:38:23 +03:00
# include <linux/pseudo_fs.h>
2007-05-11 09:23:11 +04:00
2016-12-24 22:46:01 +03:00
# include <linux/uaccess.h>
2007-05-11 09:23:11 +04:00
2023-10-11 19:55:00 +03:00
static struct vfsmount * anon_inode_mnt __ro_after_init ;
static struct inode * anon_inode_inode __ro_after_init ;
2007-05-11 09:23:11 +04:00
2009-11-21 01:28:35 +03:00
/*
* anon_inodefs_dname ( ) is called from d_path ( ) .
*/
static char * anon_inodefs_dname ( struct dentry * dentry , char * buffer , int buflen )
{
2022-01-30 23:03:49 +03:00
return dynamic_dname ( buffer , buflen , " anon_inode:%s " ,
2009-11-21 01:28:35 +03:00
dentry - > d_name . name ) ;
}
2011-01-13 00:59:34 +03:00
static const struct dentry_operations anon_inodefs_dentry_operations = {
. d_dname = anon_inodefs_dname ,
} ;
2019-03-25 19:38:23 +03:00
static int anon_inodefs_init_fs_context ( struct fs_context * fc )
2012-03-17 10:52:29 +04:00
{
2019-03-25 19:38:23 +03:00
struct pseudo_fs_context * ctx = init_pseudo ( fc , ANON_INODE_FS_MAGIC ) ;
if ( ! ctx )
return - ENOMEM ;
ctx - > dops = & anon_inodefs_dentry_operations ;
return 0 ;
2012-03-17 10:52:29 +04:00
}
static struct file_system_type anon_inode_fs_type = {
. name = " anon_inodefs " ,
2019-03-25 19:38:23 +03:00
. init_fs_context = anon_inodefs_init_fs_context ,
2012-03-17 10:52:29 +04:00
. kill_sb = kill_anon_super ,
} ;
2021-01-09 01:22:21 +03:00
static struct inode * anon_inode_make_secure_inode (
const char * name ,
const struct inode * context_inode )
2007-05-11 09:23:11 +04:00
{
2021-01-09 01:22:21 +03:00
struct inode * inode ;
const struct qstr qname = QSTR_INIT ( name , strlen ( name ) ) ;
int error ;
inode = alloc_anon_inode ( anon_inode_mnt - > mnt_sb ) ;
if ( IS_ERR ( inode ) )
return inode ;
inode - > i_flags & = ~ S_PRIVATE ;
error = security_inode_init_security_anon ( inode , & qname , context_inode ) ;
if ( error ) {
iput ( inode ) ;
return ERR_PTR ( error ) ;
}
return inode ;
}
2007-05-11 09:23:11 +04:00
2021-01-09 01:22:21 +03:00
static struct file * __anon_inode_getfile ( const char * name ,
const struct file_operations * fops ,
void * priv , int flags ,
const struct inode * context_inode ,
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
bool make_inode )
2021-01-09 01:22:21 +03:00
{
struct inode * inode ;
struct file * file ;
2007-05-11 09:23:11 +04:00
2008-12-02 13:16:03 +03:00
if ( fops - > owner & & ! try_module_get ( fops - > owner ) )
2009-09-23 03:43:57 +04:00
return ERR_PTR ( - ENOENT ) ;
2007-05-11 09:23:11 +04:00
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
if ( make_inode ) {
2021-01-09 01:22:21 +03:00
inode = anon_inode_make_secure_inode ( name , context_inode ) ;
if ( IS_ERR ( inode ) ) {
file = ERR_CAST ( inode ) ;
goto err ;
}
} else {
inode = anon_inode_inode ;
if ( IS_ERR ( inode ) ) {
file = ERR_PTR ( - ENODEV ) ;
goto err ;
}
/*
* We know the anon_inode inode count is always
* greater than zero , so ihold ( ) is safe .
*/
ihold ( inode ) ;
}
file = alloc_file_pseudo ( inode , anon_inode_mnt , name ,
2018-06-09 16:58:23 +03:00
flags & ( O_ACCMODE | O_NONBLOCK ) , fops ) ;
2012-09-13 07:11:55 +04:00
if ( IS_ERR ( file ) )
2021-01-09 01:22:21 +03:00
goto err_iput ;
2018-06-09 16:58:23 +03:00
2021-01-09 01:22:21 +03:00
file - > f_mapping = inode - > i_mapping ;
2007-05-11 09:23:11 +04:00
file - > private_data = priv ;
2009-09-23 03:43:57 +04:00
return file ;
2021-01-09 01:22:21 +03:00
err_iput :
iput ( inode ) ;
2018-06-09 16:58:23 +03:00
err :
2009-09-23 03:43:57 +04:00
module_put ( fops - > owner ) ;
2012-09-13 07:11:55 +04:00
return file ;
2009-09-23 03:43:57 +04:00
}
/**
2021-01-09 01:22:21 +03:00
* anon_inode_getfile - creates a new file instance by hooking it up to an
* anonymous inode , and a dentry that describe the " class "
* of the file
2009-09-23 03:43:57 +04:00
*
* @ name : [ in ] name of the " class " of the new file
* @ fops : [ in ] file operations for the new file
* @ priv : [ in ] private data for the new file ( will be file ' s private_data )
* @ flags : [ in ] flags
*
* Creates a new file by hooking it on a single inode . This is useful for files
* that do not need to have a full - fledged inode in order to operate correctly .
2021-01-09 01:22:21 +03:00
* All the files created with anon_inode_getfile ( ) will share a single inode ,
2009-09-23 03:43:57 +04:00
* hence saving memory and avoiding code duplication for the file / inode / dentry
2021-01-09 01:22:21 +03:00
* setup . Returns the newly created file * or an error pointer .
2009-09-23 03:43:57 +04:00
*/
2021-01-09 01:22:21 +03:00
struct file * anon_inode_getfile ( const char * name ,
const struct file_operations * fops ,
void * priv , int flags )
{
return __anon_inode_getfile ( name , fops , priv , flags , NULL , false ) ;
}
EXPORT_SYMBOL_GPL ( anon_inode_getfile ) ;
2024-04-26 10:58:54 +03:00
/**
* anon_inode_getfile_fmode - creates a new file instance by hooking it up to an
* anonymous inode , and a dentry that describe the " class "
* of the file
*
* @ name : [ in ] name of the " class " of the new file
* @ fops : [ in ] file operations for the new file
* @ priv : [ in ] private data for the new file ( will be file ' s private_data )
* @ flags : [ in ] flags
* @ f_mode : [ in ] fmode
*
* Creates a new file by hooking it on a single inode . This is useful for files
* that do not need to have a full - fledged inode in order to operate correctly .
* All the files created with anon_inode_getfile ( ) will share a single inode ,
* hence saving memory and avoiding code duplication for the file / inode / dentry
* setup . Allows setting the fmode . Returns the newly created file * or an error
* pointer .
*/
struct file * anon_inode_getfile_fmode ( const char * name ,
const struct file_operations * fops ,
void * priv , int flags , fmode_t f_mode )
{
struct file * file ;
file = __anon_inode_getfile ( name , fops , priv , flags , NULL , false ) ;
if ( ! IS_ERR ( file ) )
file - > f_mode | = f_mode ;
return file ;
}
EXPORT_SYMBOL_GPL ( anon_inode_getfile_fmode ) ;
2021-02-02 03:22:44 +03:00
/**
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
* anon_inode_create_getfile - Like anon_inode_getfile ( ) , but creates a new
2021-02-02 03:22:44 +03:00
* ! S_PRIVATE anon inode rather than reuse the
* singleton anon inode and calls the
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
* inode_init_security_anon ( ) LSM hook .
2021-02-02 03:22:44 +03:00
*
* @ name : [ in ] name of the " class " of the new file
* @ fops : [ in ] file operations for the new file
* @ priv : [ in ] private data for the new file ( will be file ' s private_data )
* @ flags : [ in ] flags
* @ context_inode :
* [ in ] the logical relationship with the new inode ( optional )
*
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
* Create a new anonymous inode and file pair . This can be done for two
* reasons :
*
* - for the inode to have its own security context , so that LSMs can enforce
* policy on the inode ' s creation ;
*
* - if the caller needs a unique inode , for example in order to customize
* the size returned by fstat ( )
*
2021-02-02 03:22:44 +03:00
* The LSM may use @ context_inode in inode_init_security_anon ( ) , but a
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
* reference to it is not held .
*
* Returns the newly created file * or an error pointer .
2021-02-02 03:22:44 +03:00
*/
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
struct file * anon_inode_create_getfile ( const char * name ,
2021-02-02 03:22:44 +03:00
const struct file_operations * fops ,
void * priv , int flags ,
const struct inode * context_inode )
{
return __anon_inode_getfile ( name , fops , priv , flags ,
context_inode , true ) ;
}
KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory
Introduce an ioctl(), KVM_CREATE_GUEST_MEMFD, to allow creating file-based
memory that is tied to a specific KVM virtual machine and whose primary
purpose is to serve guest memory.
A guest-first memory subsystem allows for optimizations and enhancements
that are kludgy or outright infeasible to implement/support in a generic
memory subsystem. With guest_memfd, guest protections and mapping sizes
are fully decoupled from host userspace mappings. E.g. KVM currently
doesn't support mapping memory as writable in the guest without it also
being writable in host userspace, as KVM's ABI uses VMA protections to
define the allow guest protection. Userspace can fudge this by
establishing two mappings, a writable mapping for the guest and readable
one for itself, but that’s suboptimal on multiple fronts.
Similarly, KVM currently requires the guest mapping size to be a strict
subset of the host userspace mapping size, e.g. KVM doesn’t support
creating a 1GiB guest mapping unless userspace also has a 1GiB guest
mapping. Decoupling the mappings sizes would allow userspace to precisely
map only what is needed without impacting guest performance, e.g. to
harden against unintentional accesses to guest memory.
Decoupling guest and userspace mappings may also allow for a cleaner
alternative to high-granularity mappings for HugeTLB, which has reached a
bit of an impasse and is unlikely to ever be merged.
A guest-first memory subsystem also provides clearer line of sight to
things like a dedicated memory pool (for slice-of-hardware VMs) and
elimination of "struct page" (for offload setups where userspace _never_
needs to mmap() guest memory).
More immediately, being able to map memory into KVM guests without mapping
said memory into the host is critical for Confidential VMs (CoCo VMs), the
initial use case for guest_memfd. While AMD's SEV and Intel's TDX prevent
untrusted software from reading guest private data by encrypting guest
memory with a key that isn't usable by the untrusted host, projects such
as Protected KVM (pKVM) provide confidentiality and integrity *without*
relying on memory encryption. And with SEV-SNP and TDX, accessing guest
private memory can be fatal to the host, i.e. KVM must be prevent host
userspace from accessing guest memory irrespective of hardware behavior.
Attempt #1 to support CoCo VMs was to add a VMA flag to mark memory as
being mappable only by KVM (or a similarly enlightened kernel subsystem).
That approach was abandoned largely due to it needing to play games with
PROT_NONE to prevent userspace from accessing guest memory.
Attempt #2 to was to usurp PG_hwpoison to prevent the host from mapping
guest private memory into userspace, but that approach failed to meet
several requirements for software-based CoCo VMs, e.g. pKVM, as the kernel
wouldn't easily be able to enforce a 1:1 page:guest association, let alone
a 1:1 pfn:gfn mapping. And using PG_hwpoison does not work for memory
that isn't backed by 'struct page', e.g. if devices gain support for
exposing encrypted memory regions to guests.
Attempt #3 was to extend the memfd() syscall and wrap shmem to provide
dedicated file-based guest memory. That approach made it as far as v10
before feedback from Hugh Dickins and Christian Brauner (and others) led
to it demise.
Hugh's objection was that piggybacking shmem made no sense for KVM's use
case as KVM didn't actually *want* the features provided by shmem. I.e.
KVM was using memfd() and shmem to avoid having to manage memory directly,
not because memfd() and shmem were the optimal solution, e.g. things like
read/write/mmap in shmem were dead weight.
Christian pointed out flaws with implementing a partial overlay (wrapping
only _some_ of shmem), e.g. poking at inode_operations or super_operations
would show shmem stuff, but address_space_operations and file_operations
would show KVM's overlay. Paraphrashing heavily, Christian suggested KVM
stop being lazy and create a proper API.
Link: https://lore.kernel.org/all/20201020061859.18385-1-kirill.shutemov@linux.intel.com
Link: https://lore.kernel.org/all/20210416154106.23721-1-kirill.shutemov@linux.intel.com
Link: https://lore.kernel.org/all/20210824005248.200037-1-seanjc@google.com
Link: https://lore.kernel.org/all/20211111141352.26311-1-chao.p.peng@linux.intel.com
Link: https://lore.kernel.org/all/20221202061347.1070246-1-chao.p.peng@linux.intel.com
Link: https://lore.kernel.org/all/ff5c5b97-acdf-9745-ebe5-c6609dd6322e@google.com
Link: https://lore.kernel.org/all/20230418-anfallen-irdisch-6993a61be10b@brauner
Link: https://lore.kernel.org/all/ZEM5Zq8oo+xnApW9@google.com
Link: https://lore.kernel.org/linux-mm/20230306191944.GA15773@monkey
Link: https://lore.kernel.org/linux-mm/ZII1p8ZHlHaQ3dDl@casper.infradead.org
Cc: Fuad Tabba <tabba@google.com>
Cc: Vishal Annapurve <vannapurve@google.com>
Cc: Ackerley Tng <ackerleytng@google.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Maciej Szmigiero <mail@maciej.szmigiero.name>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: David Hildenbrand <david@redhat.com>
Cc: Quentin Perret <qperret@google.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: Wang <wei.w.wang@intel.com>
Cc: Liam Merwick <liam.merwick@oracle.com>
Cc: Isaku Yamahata <isaku.yamahata@gmail.com>
Co-developed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Co-developed-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Co-developed-by: Chao Peng <chao.p.peng@linux.intel.com>
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Co-developed-by: Ackerley Tng <ackerleytng@google.com>
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Co-developed-by: Isaku Yamahata <isaku.yamahata@intel.com>
Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
Co-developed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Co-developed-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20231027182217.3615211-17-seanjc@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-13 13:42:34 +03:00
EXPORT_SYMBOL_GPL ( anon_inode_create_getfile ) ;
2021-02-02 03:22:44 +03:00
2021-01-09 01:22:21 +03:00
static int __anon_inode_getfd ( const char * name ,
const struct file_operations * fops ,
void * priv , int flags ,
const struct inode * context_inode ,
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
bool make_inode )
2009-09-23 03:43:57 +04:00
{
int error , fd ;
struct file * file ;
error = get_unused_fd_flags ( flags ) ;
if ( error < 0 )
return error ;
fd = error ;
2021-01-09 01:22:21 +03:00
file = __anon_inode_getfile ( name , fops , priv , flags , context_inode ,
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
make_inode ) ;
2009-09-23 03:43:57 +04:00
if ( IS_ERR ( file ) ) {
error = PTR_ERR ( file ) ;
goto err_put_unused_fd ;
}
2007-05-11 09:23:11 +04:00
fd_install ( fd , file ) ;
2008-02-23 14:46:49 +03:00
return fd ;
2007-05-11 09:23:11 +04:00
err_put_unused_fd :
put_unused_fd ( fd ) ;
return error ;
}
2021-01-09 01:22:21 +03:00
/**
* anon_inode_getfd - creates a new file instance by hooking it up to
* an anonymous inode and a dentry that describe
* the " class " of the file
*
* @ name : [ in ] name of the " class " of the new file
* @ fops : [ in ] file operations for the new file
* @ priv : [ in ] private data for the new file ( will be file ' s private_data )
* @ flags : [ in ] flags
*
* Creates a new file by hooking it on a single inode . This is
* useful for files that do not need to have a full - fledged inode in
* order to operate correctly . All the files created with
* anon_inode_getfd ( ) will use the same singleton inode , reducing
* memory use and avoiding code duplication for the file / inode / dentry
* setup . Returns a newly created file descriptor or an error code .
*/
int anon_inode_getfd ( const char * name , const struct file_operations * fops ,
void * priv , int flags )
{
return __anon_inode_getfd ( name , fops , priv , flags , NULL , false ) ;
}
2007-06-28 16:38:16 +04:00
EXPORT_SYMBOL_GPL ( anon_inode_getfd ) ;
2007-05-11 09:23:11 +04:00
2021-01-09 01:22:21 +03:00
/**
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
* anon_inode_create_getfd - Like anon_inode_getfd ( ) , but creates a new
2021-01-15 15:03:42 +03:00
* ! S_PRIVATE anon inode rather than reuse the singleton anon inode , and calls
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
* the inode_init_security_anon ( ) LSM hook .
2021-01-15 15:03:42 +03:00
*
* @ name : [ in ] name of the " class " of the new file
* @ fops : [ in ] file operations for the new file
* @ priv : [ in ] private data for the new file ( will be file ' s private_data )
* @ flags : [ in ] flags
* @ context_inode :
* [ in ] the logical relationship with the new inode ( optional )
*
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
* Create a new anonymous inode and file pair . This can be done for two
* reasons :
*
* - for the inode to have its own security context , so that LSMs can enforce
* policy on the inode ' s creation ;
*
* - if the caller needs a unique inode , for example in order to customize
* the size returned by fstat ( )
*
2021-01-15 15:03:42 +03:00
* The LSM may use @ context_inode in inode_init_security_anon ( ) , but a
* reference to it is not held .
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
*
* Returns a newly created file descriptor or an error code .
2021-01-09 01:22:21 +03:00
*/
fs: Rename anon_inode_getfile_secure() and anon_inode_getfd_secure()
The call to the inode_init_security_anon() LSM hook is not the sole
reason to use anon_inode_getfile_secure() or anon_inode_getfd_secure().
For example, the functions also allow one to create a file with non-zero
size, without needing a full-blown filesystem. In this case, you don't
need a "secure" version, just unique inodes; the current name of the
functions is confusing and does not explain well the difference with
the more "standard" anon_inode_getfile() and anon_inode_getfd().
Of course, there is another side of the coin; neither io_uring nor
userfaultfd strictly speaking need distinct inodes, and it is not
that clear anymore that anon_inode_create_get{file,fd}() allow the LSM
to intercept and block the inode's creation. If one was so inclined,
anon_inode_getfile_secure() and anon_inode_getfd_secure() could be kept,
using the shared inode or a new one depending on CONFIG_SECURITY.
However, this is probably overkill, and potentially a cause of bugs in
different configurations. Therefore, just add a comment to io_uring
and userfaultfd explaining the choice of the function.
While at it, remove the export for what is now anon_inode_create_getfd().
There is no in-tree module that uses it, and the old name is gone anyway.
If anybody actually needs the symbol, they can ask or they can just use
anon_inode_create_getfile(), which will be exported very soon for use
in KVM.
Suggested-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-03 13:47:51 +03:00
int anon_inode_create_getfd ( const char * name , const struct file_operations * fops ,
2021-01-09 01:22:21 +03:00
void * priv , int flags ,
const struct inode * context_inode )
{
return __anon_inode_getfd ( name , fops , priv , flags , context_inode , true ) ;
}
2024-04-26 10:58:54 +03:00
2007-05-11 09:23:11 +04:00
static int __init anon_inode_init ( void )
{
anon_inode_mnt = kern_mount ( & anon_inode_fs_type ) ;
2014-03-26 09:20:14 +04:00
if ( IS_ERR ( anon_inode_mnt ) )
panic ( " anon_inode_init() kernel mount failed (%ld) \n " , PTR_ERR ( anon_inode_mnt ) ) ;
2007-05-11 09:23:11 +04:00
2014-03-26 09:20:14 +04:00
anon_inode_inode = alloc_anon_inode ( anon_inode_mnt - > mnt_sb ) ;
if ( IS_ERR ( anon_inode_inode ) )
panic ( " anon_inode_init() inode allocation failed (%ld) \n " , PTR_ERR ( anon_inode_inode ) ) ;
return 0 ;
2007-05-11 09:23:11 +04:00
}
fs_initcall ( anon_inode_init ) ;