Re: [libvirt] Re: [PATCH] Add huge page support to libvirt, v2..

On Tue, Jul 28, 2009 at 08:04:31AM -0400, Stephen Smalley wrote: > On Mon, 2009-07-27 at 22:55 +0100, Daniel P. Berrange wrote: > > > > In light of what Chris said about extended attribute support > > for SELinux I think we, sadly, have no choice by to mount > > a new instance of hugetlbfs per VM, labelled with the context > > of that VM. The problem is that this doesn't really fit into > > the internal architecture we have in the slightest. The > > SELinux support we have is focused around re-labelling > > existing resources. > > > > This hugetlbfs support implies that the SELinux driver is > > altering our command line arg generator, which is not an > > easy thing for us to support, given the code flow here. > > We might have to resort to sick gross hacks.... unless the > > kernel guys think its easy to add extended attribute support > > to hugetlbfs in no time at all. > > There is a vfs fallback for setxattr of the security.* namespace to the > security module, which would work for hugetlbfs if not for the fact that > policy defines it as a genfscon-labeled filesystem. We only started > prohibiting setxattr on genfscon-labeled filesystems in 2.6.30; prior to > that we only did that for mountpoint-labeled filesystems. I can > actually chcon a file in a hugetlbfs mount on 2.6.29. Ahh, I can get that to work too on 2.6.29, I had previously been testing 2.6.30 :-) > To convert hugetlbfs to fully support labeling we'd need > hugetlbfs_mknod() to call security_inode_init_security() to set up new > inode security labels, just like shmem_mknod() does for tmpfs. And then > we'd need to switch over the policy from genfscon to fs_use_trans. This sounds like a preferrable plan to me - avoids having to have 100s, if not 1000s, of isntances of hugetlbfs mounted on large machines, then John's latest patch for libvirt would pretty much be sufficient.