QEMU Advent Calendar: A surprise disk image each day until Christmas
qemu-advent-calendar.org
QEMU Advent Calendar: A surprise disk image each day until Christmas
1–10 of 37 posts
Re: QEMU Advent Calendar: A surprise disk image each day until Christmas
#2QEMU Advent Calendar is back again this year with a surprise disk image each day until Christmas.
It features disk images of interest to hackers or to show off features from the many emulated hardware platforms that QEMU supports.
Happy holidays! And if you have a bootable image you'd like to contribute, check out the calendar website to get in touch.
Re: QEMU Advent Calendar: A surprise disk image each day until Christmas
#3Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time.
It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.
Re: QEMU Advent Calendar: A surprise disk image each day until Christmas
#4This year also marks the 15th anniversary of QEMU.
Re: QEMU Advent Calendar: A surprise disk image each day until Christmas
#5The source for F-Bird the boot sector game (day 1) is here: https://github.com/nanochess/fbird and it's an incredible bit of engineering. 3 unused bytes too :-)
Re: QEMU Advent Calendar: A surprise disk image each day until Christmas
#6Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time. It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.
Is there significant risk in booting untrusted OS images within Qemu?
Re: QEMU Advent Calendar: A surprise disk image each day until Christmas
#7Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time. It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.
Is there significant risk in booting untrusted OS images within Qemu?
It is unknown. It might be unknowable.
Re: QEMU Advent Calendar: A surprise disk image each day until Christmas
#8I’m surprised no one is complaining that mentioning Christmas is politically incorrect.
Re: QEMU Advent Calendar: A surprise disk image each day until Christmas
#9Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time. It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.
I wish something like that existed for various single-board computers that are getting popular nowadays. Any sort of flexibility would be welcome, writing big images on a SD card gets old very fast. Yes, many things probably won't boot, but I'd rather find out that they don't quickly.
Re: QEMU Advent Calendar: A surprise disk image each day until Christmas
#10Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time. It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.
Is there significant risk in booting untrusted OS images within Qemu?
You need to take steps to harden qemu - I wouldn't do it with qemu out of the box using the command line. In RHEL (eg for Red Hat's OpenStack) we do:
* Aggressively compile out unused features/devices.
* Confine each VM with separate SELinux contexts (sVirt).
* Run qemu as a special non-root user.
* Use seccomp to confine the system calls.
* Pass in pre-opened file descriptors to qemu, so qemu doesn't need to open files (helps with writing tightly confined SELinux policy).
* Run qemu in a cgroup.
* Run qemu-img with resource limits.
* Compile qemu with all hardening features enabled like RELRO, PIE, etc.
* Audit the code manually and with Coverity.
* Take security reports seriously and have a fast patching mechanism (you can effectively "live patch" qemu by migrating a VM off the old qemu and on to the new qemu).
Probably more that I've forgotten about ...