Re: [libvirt] Re: [PATCH] Add huge page support to libvirt, v2..
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