linux-kernel - Re: [PATCH v3 0/3] cgroup: add xattr support

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 18 Jul 2012 13:02:03 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Tejun Heo <tj@...nel.org>
cc:	Aristeu Rozanski <aris@...hat.com>, linux-kernel@...r.kernel.org,
	Li Zefan <lizefan@...wei.com>, Hillf Danton <dhillf@...il.com>
Subject: Re: [PATCH v3 0/3] cgroup: add xattr support

On Tue, 17 Jul 2012, Tejun Heo wrote:
> On Mon, Jul 02, 2012 at 10:29:25AM -0400, Aristeu Rozanski wrote:
> > This series are a refreshed version of a patchset submitted by Li Zefan back
> > in march:
> > 	https://lkml.org/lkml/2012/3/1/13
> > 
> > With Li's permission, I refreshed the patches to apply over the latest upstream
> > and added the modifications suggested by others in the thread:
> > - using a mount option instead of config option to enable the xattr support
> > - reinitialize the list in kmem_xattrs_free()
> > - renamed functions to simple_xattr_*()
> > 
> > Signed-off-by: Li Zefan <lizefan@...wei.com>
> > Signed-off-by: Aristeu Rozanski <aris@...hat.com>
> 
> I raised this point before but I'm worried about directly exposing
> kernel memory through xattr interface to userland.

Quite rightly.

> Maybe it's okay as long as !root users are kept from creating them.

That's how I see it with tmpfs.

> I don't know.  I
> really hope it used anonymous page cache instead of kmem tho.  Hugh,
> would something like that be difficult?

Yes, it would be difficult.

You don't use the word "swappable", but I take that to be implicit
when you say "anonymous ... instead of kmem": it might as well be
kmem if it cannot be swapped.

So you're wondering whether to introduce a new category of swappable
memory: not the original anon pages mapped into userspace, not shmem
use of swappable pages, but xattrs in the cgroup filesystem?

I think it would be foolish to add that dimension of complication
just for cgroupfs xattrs - the shmem/tmpfs case gives enough surprises
as it is.

If we were going to consider swappable kernel memory, we'd be choosing
easier targets (page tables and stacks), than something that at present
is being served by slab objects.

Or am I misunderstanding, or looking at this from the wrong angle?

If there's not a reasonable upper bound on what gets stored here
(did I see the word "icon" earlier in the thread?  which made me
think people would be loading their photo albums into these xattrs),
maybe the problem does need turning around.

Let userspace manage a tmpfs hierarchy parallel to the cgroupfs one?

Hugh
--
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/