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

Stephen Smalley sds at tycho.nsa.gov
Tue Jul 28 12:04:31 UTC 2009


On Mon, 2009-07-27 at 22:55 +0100, Daniel P. Berrange wrote:
> On Thu, Jul 23, 2009 at 09:00:18PM -0400, john cooper wrote:
> > I've incorporated feedback received on the
> > prior version into the patch below.
> > 
> > The host mount point for hugetlbfs is queried by
> > default from /proc/mounts unless overridden in
> > qemu.conf via:
> > 
> >     hugepage_mount = "<path_to_mount_point>"
> > 
> > This should make the concern of establishing
> > a mount point path convention a non-issue for
> > the general case while still allowing the same
> > to be deterministically set if needed.
> 
> 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.

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.

-- 
Stephen Smalley
National Security Agency




More information about the libvir-list mailing list