All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@linux.intel.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v6 00/22] Support ext4 on NV-DIMMs
Date: Thu, 27 Feb 2014 11:29:23 -0500	[thread overview]
Message-ID: <20140227162923.GH5744@linux.intel.com> (raw)
In-Reply-To: <530F451F.9020107@redhat.com>

On Thu, Feb 27, 2014 at 03:01:03PM +0100, Florian Weimer wrote:
> On 02/25/2014 03:18 PM, Matthew Wilcox wrote:
> >One of the primary uses for NV-DIMMs is to expose them as a block device
> >and use a filesystem to store files on the NV-DIMM.  While that works,
> >it currently wastes memory and CPU time buffering the files in the page
> >cache.  We have support in ext2 for bypassing the page cache, but it
> >has some races which are unfixable in the current design.  This series
> >of patches rewrite the underlying support, and add support for direct
> >access to ext4.
> 
> I'm wondering if there is a potential security issue lurking here.
> 
> Some distributions use udisks2 to grant permission to local console
> users to create new loop devices from files.  File systems on these
> block devices are then mounted.  This is a replacement for several
> file systems implemented in user space, and for the users, this is a
> good thing because the in-kernel implementations are generally of
> higher quality.

Just to be sure I understand; the user owns the file (so can change any
bit in it at will), and the loop device is used to present that file
to the filesystem as a block device to be mounted?  Have we fuzz-tested
all the filesystems enough to be sure that's safe?  :-)

> What happens if we have DAX support in the entire stack, and an
> enterprising user mounts a file system?  Will she be able to fuzz
> the file system or binfmt loaders concurrently, changing the bits
> while they are being read?
> 
> Currently, it appears that the loop device duplicates pages in the
> page cache, so this does not seem to be possible, but DAX support
> might change this.

I haven't looked at adding DAX support to the loop device, although
that would make sense.  At the moment, neither ext2 nor ext4 (our only
DAX-supporting filesystems) use DAX for their metadata, only for user
data.  As far as fuzzing the binfmt loaders ... are these filesystems not
forced to be at least nosuid?  I might go so far as to make them noexec.

Thanks for thinking about this.  I didn't know allowing users to mount
files they owned was something distros actually did.  Have we considered
prohibiting the user from modifying the file while it's mounted, eg
forcing its permissions to 0 or pretending it's immutable?


WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@linux.intel.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v6 00/22] Support ext4 on NV-DIMMs
Date: Thu, 27 Feb 2014 11:29:23 -0500	[thread overview]
Message-ID: <20140227162923.GH5744@linux.intel.com> (raw)
In-Reply-To: <530F451F.9020107@redhat.com>

On Thu, Feb 27, 2014 at 03:01:03PM +0100, Florian Weimer wrote:
> On 02/25/2014 03:18 PM, Matthew Wilcox wrote:
> >One of the primary uses for NV-DIMMs is to expose them as a block device
> >and use a filesystem to store files on the NV-DIMM.  While that works,
> >it currently wastes memory and CPU time buffering the files in the page
> >cache.  We have support in ext2 for bypassing the page cache, but it
> >has some races which are unfixable in the current design.  This series
> >of patches rewrite the underlying support, and add support for direct
> >access to ext4.
> 
> I'm wondering if there is a potential security issue lurking here.
> 
> Some distributions use udisks2 to grant permission to local console
> users to create new loop devices from files.  File systems on these
> block devices are then mounted.  This is a replacement for several
> file systems implemented in user space, and for the users, this is a
> good thing because the in-kernel implementations are generally of
> higher quality.

Just to be sure I understand; the user owns the file (so can change any
bit in it at will), and the loop device is used to present that file
to the filesystem as a block device to be mounted?  Have we fuzz-tested
all the filesystems enough to be sure that's safe?  :-)

> What happens if we have DAX support in the entire stack, and an
> enterprising user mounts a file system?  Will she be able to fuzz
> the file system or binfmt loaders concurrently, changing the bits
> while they are being read?
> 
> Currently, it appears that the loop device duplicates pages in the
> page cache, so this does not seem to be possible, but DAX support
> might change this.

I haven't looked at adding DAX support to the loop device, although
that would make sense.  At the moment, neither ext2 nor ext4 (our only
DAX-supporting filesystems) use DAX for their metadata, only for user
data.  As far as fuzzing the binfmt loaders ... are these filesystems not
forced to be at least nosuid?  I might go so far as to make them noexec.

Thanks for thinking about this.  I didn't know allowing users to mount
files they owned was something distros actually did.  Have we considered
prohibiting the user from modifying the file while it's mounted, eg
forcing its permissions to 0 or pretending it's immutable?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-02-27 16:29 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-25 14:18 [PATCH v6 00/22] Support ext4 on NV-DIMMs Matthew Wilcox
2014-02-25 14:18 ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 01/22] Fix XIP fault vs truncate race Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 02/22] Allow page fault handlers to perform the COW Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 03/22] axonram: Fix bug in direct_access Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 04/22] Change direct_access calling convention Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 05/22] Introduce IS_DAX(inode) Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 06/22] Replace XIP read and write with DAX I/O Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-03-11  0:32   ` Toshi Kani
2014-03-11  0:32     ` Toshi Kani
2014-03-11 12:53     ` Matthew Wilcox
2014-03-11 12:53       ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 07/22] Replace the XIP page fault handler with the DAX page fault handler Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-28 17:49   ` Toshi Kani
2014-02-28 17:49     ` Toshi Kani
2014-02-28 20:20     ` Matthew Wilcox
2014-02-28 20:20       ` Matthew Wilcox
2014-02-28 22:18       ` Toshi Kani
2014-02-28 22:18         ` Toshi Kani
2014-02-28 22:18         ` Toshi Kani
2014-03-02 23:30       ` Dave Chinner
2014-03-02 23:30         ` Dave Chinner
2014-03-03 23:07         ` Ross Zwisler
2014-03-03 23:07           ` Ross Zwisler
2014-03-04  0:56           ` Dave Chinner
2014-03-04  0:56             ` Dave Chinner
2014-03-20 19:38             ` Matthew Wilcox
2014-03-20 19:38               ` Matthew Wilcox
2014-03-20 23:55               ` Dave Chinner
2014-03-20 23:55                 ` Dave Chinner
2014-02-25 14:18 ` [PATCH v6 08/22] Replace xip_truncate_page with dax_truncate_page Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 09/22] Remove mm/filemap_xip.c Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 10/22] Remove get_xip_mem Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 11/22] Replace ext2_clear_xip_target with dax_clear_blocks Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 12/22] ext2: Remove ext2_xip_verify_sb() Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 13/22] ext2: Remove ext2_use_xip Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 14/22] ext2: Remove xip.c and xip.h Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 15/22] Remove CONFIG_EXT2_FS_XIP and rename CONFIG_FS_XIP to CONFIG_FS_DAX Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 16/22] ext2: Remove ext2_aops_xip Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 17/22] Get rid of most mentions of XIP in ext2 Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 18/22] xip: Add xip_zero_page_range Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 19/22] ext4: Make ext4_block_zero_page_range static Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 20/22] ext4: Add DAX functionality Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 21/22] ext4: Fix typos Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-25 14:18 ` [PATCH v6 22/22] dax: Add reporting of major faults Matthew Wilcox
2014-02-25 14:18   ` Matthew Wilcox
2014-02-26 15:07 ` [PATCH v6 23/22] Bugfixes Matthew Wilcox
2014-02-26 15:07   ` Matthew Wilcox
2014-02-27 14:01 ` [PATCH v6 00/22] Support ext4 on NV-DIMMs Florian Weimer
2014-02-27 14:01   ` Florian Weimer
2014-02-27 16:29   ` Matthew Wilcox [this message]
2014-02-27 16:29     ` Matthew Wilcox
2014-02-27 16:36     ` Florian Weimer
2014-02-27 16:36       ` Florian Weimer
2014-03-02  8:22 ` Pavel Machek
2014-03-02  8:22   ` Pavel Machek
     [not found] ` <CF4DEE22.25C8F%matthew.r.wilcox@intel.com>
2014-03-18 18:45   ` [PATCH v6 20/22] ext4: Add DAX functionality Ross Zwisler
2014-03-18 18:45     ` Ross Zwisler

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=20140227162923.GH5744@linux.intel.com \
    --to=willy@linux.intel.com \
    --cc=fweimer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.r.wilcox@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.