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