Messages in this thread | | | Date | Tue, 21 Apr 2015 14:20:31 +0200 | From | Michal Hocko <> | Subject | Re: [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
| |