lkml.org 
[lkml]   [2015]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] kdbus for 4.1-rc1
On Tue 21-04-15 12:17:49, David Herrmann wrote:
> Hi
>
> On Tue, Apr 21, 2015 at 11:35 AM, One Thousand Gnomes
> <gnomes@lxorguk.ukuu.org.uk> wrote:
> >> On top of that, I think that someone into resource management needs to
> >> seriously consider whether having a broadcast send do get_user_pages
> >> or the equivalent on pages supplied by untrusted recipients (plural!)
> >> is a good idea.
> >
> > Oh but its so much fun if you pass pages belonging to a device driver, or
> > pass bits of a GEM object thereby keeping entire graphics textures
> > referenced 8)
>
> We do not use GUP, nor do we pass around pinned pages. All we use is
> __vfs_read() / __vfs_write() on shmem. Whether generic_file_write() /
> copy_from_user() internally relies on GUP or not, is an orthogonal
> issue that does not belong here.

It kind of does AFAIU. If for nothing else then the memcg reasons mentioned in
other email (http://marc.info/?l=linux-kernel&m=142953380508188). If an
untrusted user is allowed to hand over a shmem backed buffer which hasn't
been charged yet (read faulted in) and then kdbus forced to fault it in
a different user's context then you basically allow to hide memory
allocations from the memcg. That is a clear show stopper.

Or have I misunderstood the way how shmem buffers are used here?

--
Michal Hocko
SUSE Labs


\
 
 \ /
  Last update: 2015-04-21 15:01    [W:0.102 / U:2.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site