Talk:QEMU

egrep -E
Isn't it redundant to say "egrep -E"? "egrep" is supposed to just be a shorter/alternative way of saying "grep -E". -- Luiji 03:43, 31 December 2014 (UTC)
 * According to grep(1), "egrep is the same as grep -E" and direct egrep invocation is deprecated. So changed "egrep" to "grep" in the article. -- 0x6177 17:30, 31 December 2014 (UTC)

file capabilities
Is there some documentation on USE="filecaps" actually needing DebugFS in kernel? I see DebugFS used for perf stats, but filecaps seems unrelated. Petteyg (talk) 19:16, 13 March 2015 (UTC)

Try:

https://packages.gentoo.org/useflags/filecaps and:

https://devmanual.gentoo.org/eclass-reference/fcaps.eclass/index.html

--MiroR (talk) 19:52, 7 August 2016 (UTC)

I did more research, as:

/usr/portage/profiles/use.desc:

caps - Use Linux capabilities library to control privilege

filecaps - Use Linux file capabilities to control privilege rather than set*id (this is orthogonal to USE=caps which uses capabilities at runtime e.g. libcap)

didn't tell me enough.

On Gentoo Wiki:

https://wiki.gentoo.org/wiki/Hardened/Overview_of_POSIX_capabilities

(and that link should be included in the article IMO)

It's the same capabilities in both the flags, caps and filecaps, just in caps, they are applied on the fly (strace

( emerge strace

if you don't have it installed )

the /bin/ping command and you'll see capget and capset called for the command, and /bin/ping is not suid and it does not have filecaps set, not in my machine)

and the:

/usr/libexec/qemu-bridge-helper

from your qemu installation has those capabilities set in file attributes (if you set the filecaps on, still uncertain if that is the good way to go for a grsecurity-hardened, because it cost me the CONFIG_GRKERNSEC_KMEM (see: Use Tor browser on grsecurity-hardened system?))

The base address for understanding of file capabilities is the inventor's page:

http://www.friedhoff.org/posixfilecaps.html#POSIX%20Capabilities%20-%20Capability%20Rules

( or http://www.friedhoff.org/posixfilecaps.html from top of page for those who have the time )

Also worth reading is the:

Archlinux Wiki Page on Capabilities

It is very good and important to know that capabilites can be very much abused:

False Boundaries and Arbitrary Code Execution

And also there's something wrongly named that has nothing to do with Linux Capabilites too:

A concept wrongly named (capabilities were invented previous)

--MiroR (talk) 12:55, 14 August 2016 (UTC)

very frustrating
I had a very frustrating time trying to get this working. I don't want to be all crappy criticism, so I'll come back after I have things working well. There are a lot of kernel options that are missing from this page. I found http://www.linux-kvm.org/page/Tuning_Kernel this little guide] that gave a lot more, but some of this seems to be outdated already. Also, this section needs to distinguish between the kernel config on the host & guest. I finally had to boot the livecd and carefully examine lspci, /proc/config.gz, etc. to figure out what it was doing 'right' and that my guest kernel was doing 'wrong'.

Further, I suspect that grub2 with --target=i386-qemu may be preferable (I haven't actually gotten it working yet), but I was baffled by the lack of documentation, OH MY FUCKING GOD! One of the reasons that I suspect that it may be preferable is that it will install on a device (or image file) that is not fdisk-ed, because you may just want to put a single file system on an image file. Grub2 does not like installing there, but it doesn't seem to mind if --target=i386-qemu. The flip side of this mystery I think I've figured out today -- when you start qemu, you can pass -bios xxx. But xxx isn't just "qemu", it wants a bios file! I had no fucking clue where that was, now I think it's /usr/share/qemu/bios.bin (ran qlist qemu|grep -i bios). I'll try this one out later. Daniel Santos (talk) 23:57, 27 January 2016 (UTC)

Daniel Santos (talk) 23:57, 27 January 2016 (UTC)

/dev/kvm line to change more to the point
This line:

If KVM support is available there should be a "kvm" device listed at /dev/kvm should read:

If KVM support is available there should be a "kvm" device listed as /dev/kvm after you boot into the kvm enabled kernel.

It does not show before, as one might interpret the line as it currently is.--MiroR (talk) 20:06, 7 August 2016 (UTC)