Hi On Tue, Apr 21, 2015 at 4:27 PM, Michal Hocko <mho...@suse.cz> wrote: > On Tue 21-04-15 16:01:01, David Herrmann wrote: >> On Tue, Apr 21, 2015 at 2:20 PM, Michal Hocko <mho...@suse.cz> wrote: >> > 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? >> >> ..as you mentioned memcg, lets figure that out here. shmem buffers are >> used as receive-buffers by kdbus peers. They are read-only to >> user-space. All allocations are done by the kernel on message passing. > > OK, so the shmem buffer is allocated on the kernels behalf and under > its control and no userspace can hand over one to kdbus. Do I get > it right? If yes then the memcg escape I was describing above is > not possible of course. This wasn't clear to me from the previous > discussion. Thanks for the clarification!
Exactly. Much appreciated! Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
