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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 05, 2009 at 03:50:56PM +0100, Daniel P. Berrange wrote:
> 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. 

FYI, for those interested, we're going to try & fix the kernel support
as part of Fedora 12 work. If you want to track progress, the BZ is
here

https://bugzilla.redhat.com/show_bug.cgi?id=515741

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]