linux-kernel - Re: [PATCH v2 4/9] mm/mshare: Add a read operation for msharefs files

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: <Yr4VVuCzCp50cu0O@magnolia>
Date:   Thu, 30 Jun 2022 14:27:50 -0700
From:   "Darrick J. Wong" <djwong@...nel.org>
To:     Khalid Aziz <khalid.aziz@...cle.com>
Cc:     akpm@...ux-foundation.org, willy@...radead.org,
        aneesh.kumar@...ux.ibm.com, arnd@...db.de, 21cnbao@...il.com,
        corbet@....net, dave.hansen@...ux.intel.com, david@...hat.com,
        ebiederm@...ssion.com, hagen@...u.net, jack@...e.cz,
        keescook@...omium.org, kirill@...temov.name, kucharsk@...il.com,
        linkinjeon@...nel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        longpeng2@...wei.com, luto@...nel.org, markhemm@...glemail.com,
        pcc@...gle.com, rppt@...nel.org, sieberf@...zon.com,
        sjpark@...zon.de, surenb@...gle.com, tst@...oebel-theuer.de,
        yzaikin@...gle.com
Subject: Re: [PATCH v2 4/9] mm/mshare: Add a read operation for msharefs files

On Wed, Jun 29, 2022 at 04:53:55PM -0600, Khalid Aziz wrote:
> When a new file is created under msharefs, allocate a new mm_struct
> that will hold the VMAs for mshare region. Also allocate structure
> to defines the mshare region and add a read operation to the file
> that returns this information about the mshare region. Currently
> this information is returned as a struct:
> 
> struct mshare_info {
> 	unsigned long start;
> 	unsigned long size;
> };
> 
> This gives the start address for mshare region and its size.
> 
> Signed-off-by: Khalid Aziz <khalid.aziz@...cle.com>
> ---
>  include/uapi/linux/mman.h |  5 +++
>  mm/mshare.c               | 64 ++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 68 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h
> index f55bc680b5b0..56fe446e24b1 100644
> --- a/include/uapi/linux/mman.h
> +++ b/include/uapi/linux/mman.h
> @@ -41,4 +41,9 @@
>  #define MAP_HUGE_2GB	HUGETLB_FLAG_ENCODE_2GB
>  #define MAP_HUGE_16GB	HUGETLB_FLAG_ENCODE_16GB
>  
> +struct mshare_info {
> +	unsigned long start;
> +	unsigned long size;

You might want to make these explicitly u64, since this is userspace
ABI and you never know when someone will want to do something crazy like
run 32-bit programs with mshare files.

Also you might want to add some padding fields for flags, future
expansion, etc.

> +};
> +
>  #endif /* _UAPI_LINUX_MMAN_H */
> diff --git a/mm/mshare.c b/mm/mshare.c
> index 2d5924d39221..d238b68b0576 100644
> --- a/mm/mshare.c
> +++ b/mm/mshare.c
> @@ -22,8 +22,14 @@
>  #include <uapi/linux/magic.h>
>  #include <uapi/linux/limits.h>
>  #include <uapi/linux/mman.h>
> +#include <linux/sched/mm.h>
>  
>  static struct super_block *msharefs_sb;
> +struct mshare_data {
> +	struct mm_struct *mm;
> +	refcount_t refcnt;
> +	struct mshare_info *minfo;
> +};
>  
>  static const struct inode_operations msharefs_dir_inode_ops;
>  static const struct inode_operations msharefs_file_inode_ops;
> @@ -34,8 +40,29 @@ msharefs_open(struct inode *inode, struct file *file)
>  	return simple_open(inode, file);
>  }
>  
> +static ssize_t
> +msharefs_read(struct kiocb *iocb, struct iov_iter *iov)
> +{
> +	struct mshare_data *info = iocb->ki_filp->private_data;
> +	size_t ret;
> +	struct mshare_info m_info;
> +
> +	if (info->minfo != NULL) {
> +		m_info.start = info->minfo->start;
> +		m_info.size = info->minfo->size;
> +	} else {
> +		m_info.start = 0;
> +		m_info.size = 0;

Hmmm, read()ing out the shared mapping information.  Heh.

When does this case happen?  Is it before anybody mmaps this file into
an address space?

> +	}
> +	ret = copy_to_iter(&m_info, sizeof(m_info), iov);
> +	if (!ret)
> +		return -EFAULT;
> +	return ret;
> +}
> +
>  static const struct file_operations msharefs_file_operations = {
>  	.open		= msharefs_open,
> +	.read_iter	= msharefs_read,
>  	.llseek		= no_llseek,
>  };
>  
> @@ -73,12 +100,43 @@ static struct dentry
>  	return ERR_PTR(-ENOMEM);
>  }
>  
> +static int
> +msharefs_fill_mm(struct inode *inode)
> +{
> +	struct mm_struct *mm;
> +	struct mshare_data *info = NULL;
> +	int retval = 0;
> +
> +	mm = mm_alloc();
> +	if (!mm) {
> +		retval = -ENOMEM;
> +		goto err_free;
> +	}
> +
> +	info = kzalloc(sizeof(*info), GFP_KERNEL);
> +	if (!info) {
> +		retval = -ENOMEM;
> +		goto err_free;
> +	}
> +	info->mm = mm;
> +	info->minfo = NULL;
> +	refcount_set(&info->refcnt, 1);
> +	inode->i_private = info;
> +
> +	return 0;
> +
> +err_free:
> +	if (mm)
> +		mmput(mm);
> +	kfree(info);
> +	return retval;
> +}
> +
>  static struct inode
>  *msharefs_get_inode(struct super_block *sb, const struct inode *dir,
>  			umode_t mode)
>  {
>  	struct inode *inode = new_inode(sb);
> -
>  	if (inode) {
>  		inode->i_ino = get_next_ino();
>  		inode_init_owner(&init_user_ns, inode, dir, mode);
> @@ -89,6 +147,10 @@ static struct inode
>  		case S_IFREG:
>  			inode->i_op = &msharefs_file_inode_ops;
>  			inode->i_fop = &msharefs_file_operations;
> +			if (msharefs_fill_mm(inode) != 0) {
> +				discard_new_inode(inode);
> +				inode = ERR_PTR(-ENOMEM);

Is it intentional to clobber the msharefs_fill_mm return value and
replace it with ENOMEM?

--D

> +			}
>  			break;
>  		case S_IFDIR:
>  			inode->i_op = &msharefs_dir_inode_ops;
> -- 
> 2.32.0
>