linux-kernel - Re: Security issues with local filesystem caching

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1162575034.5629.24.camel@lade.trondhjem.org>
Date:	Fri, 03 Nov 2006 12:30:34 -0500
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	David Howells <dhowells@...hat.com>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	Karl MacMillan <kmacmill@...hat.com>, jmorris@...ei.org,
	chrisw@...s-sol.org, selinux@...ho.nsa.gov,
	linux-kernel@...r.kernel.org, aviro@...hat.com
Subject: Re: Security issues with local filesystem caching

On Fri, 2006-11-03 at 15:23 +0000, David Howells wrote:
> Trond Myklebust <trond.myklebust@....uio.no> wrote:
> 
> > It is not as if we care about an extra context switch here,
> 
> Avoiding context switches aren't the main problem; avoiding serialisation is.

Why? It is a backing cache. The only case where serialisation ought to
bother you is the case where the client has to invalidate the cache due
to a server-side update of the file.

> > and we really don't want to do that file i/o in the context of the rpciod
> > process if we can avoid it.
> 
> We aren't doing file I/O in the context of the rpciod process, at least not to
> the cache.  It's either done in the context of the process that issued the
> read, write or pagefault.

Once the RPC calls have been launched, the process returns to the VM
layer and just waits for the next page to be unlocked. It never returns
to the filesystem layer. So where are you using the process context to
write out the cached data?

> The security problems come from the lookups, creates, xattr ops that we have to
> do when acquiring a cookie.  All of these are done in the context of the
> process that called iget5 for NFS.  We could farm them out to another process
> to avoid the security, but that would then cause serialisation and context
> switches.

The cookie lookups need to be synchronous, but why would the file
creation need to be synchronous? Creating the cachefs file and waiting
on that to complete etc are all utterly useless activities as far as
satisfying the user request for data goes. Just start the process of
creating a backing file, and then get on with the actual syscall.

> Writing data to the cache is done by the pagecache at the moment.  I'd really
> like to use direct I/O instead as that'd mean I wouldn't need shadow pages in
> the page cache and I'd also be able to avoid the page-to-page copy I'm
> currently doing.

Agreed.

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/