6 ms·

QEMU Advent Calendar: A surprise disk image each day until Christmas

274 points by stefanha 8y ago

stefanha 8y ago
QEMU 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.
LeonM 8y ago
Today'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.
- jai_ 8y ago
  Is there significant risk in booting untrusted OS images within Qemu?
  - AnthonBerg 8y ago
    It is unknown. It might be unknowable.
    - AnthonBerg 8y ago
      Due to a couple downvotes I want to explain by way of a question: Can it to your knowledge be proven that QEMU is fully secure? Given that bugs which have been found in it previously have been fixed, can we know from now on that it’s 100% safe? As far as I know there does not exist a way of rigorously proving that. fwiw my interest in theoretical computers and formal verification based on this fundamental aspect.
  - rwmj 8y ago
    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 ...
    - rbanffy 8y ago
      This sounds like a lot of fun. What are you doing with those VMs?
      - rwmj 8y ago
        I work for Red Hat and this is how VMs are configured by default if you buy RHV, RHOSP, KubeVirt or similar on-prem or public virtualization or cloud products from us. You can turn some of these mitigations off if you want, although I wouldn't personally recommend it - at some time of another there has been a security critical bug which has been mitigated by each one of these changes. Some of our customers are running untrusted VMs in their public clouds using this configuration. Others will be running on-premises virtualization set ups with VMs from across their companies which can be equally risky. SELinux is probably the most important mitigation in the list, and while it has a bad reputation that's mostly from people who haven't used it for over a decade. I have SELinux enforcing on every machine I use, and it rarely causes an issue.
    - nerpderp82 8y ago
      Please make a gist or blog post!
  - syn0byte 8y ago
    Short Answer: Yes. Historic(2015) VM escape example https://venom.crowdstrike.com/ https://venom.crowdstrike.com/ I doubt anyone is wasting a good zero-day on disposable qemu netboot images. Someone may try a venom(like) image for 'fun'.
- xaduha 8y ago
  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.
  - LeonM 8y ago
    The latest rPi can do PXE (ethernet boot) over wired ethernet (no support for PXE over WiFi yet). I have set this up and it is pretty cool to quickly boot images over the network this way, and experiment with them without having to write SD cards. In fact: my rPI doesn't even have a SD card inserted. The ethernet performance in the RPI is still poor though, the USB-to-ethernet bridge is suboptimal. I guess we're almost back at running RPi 'terminals' on our desktop and have a centralised (cloud?) storage solution to boot from and persist files to. We're almost back at 90's level computing ;-)
  - deleted 8y ago
    [deleted]
  - PyroLagus 8y ago
    I don't know about other ones, but you can netboot the Raspberry Pi 3: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md https://www.raspberrypi.org/documentation/hardware/raspberry...
    - pnutjam 8y ago
      I use an APU, but with any netboot small computer, I find it easier to netboot a simple linux build and dd the image via netcat, vs plugging and unplugging the card. My notes for pfsense: receiving machine: netcat -l 2222 | gzip -dc | dd of=/dev/sda sending machine: dd if=pfSense-2.2.4-RELEASE-2g-i386-nanobsd.img.gz |netcat 10.10.10.101 2222
      - namibj 8y ago
        replace dd with shell redirection or cat...
- ljcn 8y ago
  Specifically, for those wondering http://boot.netboot.xyz http://boot.netboot.xyz which in turn does http[s]://boot.netboot.xyz/menu.ipxe
  - candiodari 8y ago
    I don't understand the complaints about this. What does https buy you in this case ? Security against your client-server communications' contents being observed by third parties. So here https ... gives ... confidentiality ... to ... public ... images. Well that's useful ! It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ... So what's the point of https in this situation ? Certificate, cert pinning, ... are all useless in this situation (certificate only helps on repeat visits, which of course never applies in this situation. Cert pinning only helps for specific sites (not this one) and even if it did, only when the originating software is really up to date (which is just not going to be the case here). So you can just as well say that http is perfectly secure in this case. Or at least ... as secure as https is going to be. There's quite a bit more to security than "use https".
    - LeonM 8y ago
      > What does https buy you in this case ? It ensures the response from the webserver really is from netboot.xyz, and not from any mitm server. > It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ... Can you elaborate? How would you spoof the server response without having a valid certificate key for the netboot.xyz domain?
      - gsich 8y ago
        For this to work trusted CAs need to be compiled into the iPXE binary. Since those can change you'll need to update that binary from time to time. Or ignore cert warnings, which reduces the security to plain HTTP.
      - kpcyrd 8y ago
- theantonym 8y ago
  Hi, owner of https://netboot.xyz https://netboot.xyz here. netboot.xyz has https support, with http support still being in place for those that don't have https support compiled into iPXE as it's not compiled by default. I'd recommend checking out the site directly if this is something that interests you. All of the source code running the site is on github as well and we're always open to contributions. We also always try to retrieve the installer kernels directly from the OS supported mirrors when possible so that they are pulled from trusted sources.
  - LeonM 8y ago
    Hi, thanks for the work! I believe I first discovered netboot.xyz on a show HN. I have set up the DHCP in my lab to serve netboot.xyz, so I can experiment with different OS'es without much hassle. It has been great so far.
    - m-p-3 8y ago
      I even used it successfully on a VPS which had a limited about of OSes available. Awesome project!
  - bubblethink 8y ago
    netboot.xyz is great! My main use case is to boot things off of drac/ilo etc. If you have a remote server hosted in a datacenter and have struggled to use drac's virtual iso feature, boot the netboot iso. Since it's tiny, it works great for booting, and it switches to the primary NIC once the OS is booting. If you try to use your full iso with drac, it will be painfully slow because it goes through several layers of indirection (reverse proxies set up by your provider, the weird drac driver etc.)
  - rwmj 8y ago
    Do you serve the main images over tftp and is it reliable? We have been building an NBD server with this use case in mind and had on and off discussions with Foreman people about a similar case. In theory NBD should be much more efficient since it will only serve the main image on demand (but if you want you can still use it like tftp by copying /dev/nbd0 to a ram disk at boot). It also supports TLS. https://github.com/libguestfs/nbdkit https://github.com/libguestfs/nbdkit https://github.com/libguestfs/nbdkit/blob/master/plugins/floppy/nbdkit-floppy-plugin.pod https://github.com/libguestfs/nbdkit/blob/master/plugins/flo...
- foxhop 8y ago
  I always assumed people who use netboot are running a distribution mirror inside their "data center".
kashyapc 8y ago
This year also marks the 15th anniversary of QEMU.
rwmj 8y ago
The source for F-Bird the boot sector game (day 1) is here: https://github.com/nanochess/fbird https://github.com/nanochess/fbird and it's an incredible bit of engineering. 3 unused bytes too :-)
_RPM 8y ago
I’m surprised no one is complaining that mentioning Christmas is politically incorrect.
m-p-3 8y ago
netboot.xyz is such an awesome project. I added it to most of my USB boot disks as a grub entry (on my SystemRescueCD USB thumbdrive, etc), so I'm almost never stuck when I need to deploy an OS on the go.
sigjuice 8y ago
Hoping for some cool non-x86 and non-Linux systems.
kashyapc 8y ago
There are still a couple of open slots, so feel free to send ideas (or even better -- prepared images) to the contact e-mail address mentioned on the website.

274 points by stefanha 8y ago

QEMU 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.

LeonM 8y ago

Today'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.

jai_ 8y ago
Is there significant risk in booting untrusted OS images within Qemu?
- AnthonBerg 8y ago
  It is unknown. It might be unknowable.
  - AnthonBerg 8y ago
    Due to a couple downvotes I want to explain by way of a question: Can it to your knowledge be proven that QEMU is fully secure? Given that bugs which have been found in it previously have been fixed, can we know from now on that it’s 100% safe? As far as I know there does not exist a way of rigorously proving that. fwiw my interest in theoretical computers and formal verification based on this fundamental aspect.
- rwmj 8y ago
  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 ...
  - rbanffy 8y ago
    This sounds like a lot of fun. What are you doing with those VMs?
    - rwmj 8y ago
      I work for Red Hat and this is how VMs are configured by default if you buy RHV, RHOSP, KubeVirt or similar on-prem or public virtualization or cloud products from us. You can turn some of these mitigations off if you want, although I wouldn't personally recommend it - at some time of another there has been a security critical bug which has been mitigated by each one of these changes. Some of our customers are running untrusted VMs in their public clouds using this configuration. Others will be running on-premises virtualization set ups with VMs from across their companies which can be equally risky. SELinux is probably the most important mitigation in the list, and while it has a bad reputation that's mostly from people who haven't used it for over a decade. I have SELinux enforcing on every machine I use, and it rarely causes an issue.
  - nerpderp82 8y ago
    Please make a gist or blog post!
- syn0byte 8y ago
  Short Answer: Yes. Historic(2015) VM escape example https://venom.crowdstrike.com/ https://venom.crowdstrike.com/ I doubt anyone is wasting a good zero-day on disposable qemu netboot images. Someone may try a venom(like) image for 'fun'.
xaduha 8y ago
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.
- LeonM 8y ago
  The latest rPi can do PXE (ethernet boot) over wired ethernet (no support for PXE over WiFi yet). I have set this up and it is pretty cool to quickly boot images over the network this way, and experiment with them without having to write SD cards. In fact: my rPI doesn't even have a SD card inserted. The ethernet performance in the RPI is still poor though, the USB-to-ethernet bridge is suboptimal. I guess we're almost back at running RPi 'terminals' on our desktop and have a centralised (cloud?) storage solution to boot from and persist files to. We're almost back at 90's level computing ;-)
- deleted 8y ago
  [deleted]
- PyroLagus 8y ago
  I don't know about other ones, but you can netboot the Raspberry Pi 3: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md https://www.raspberrypi.org/documentation/hardware/raspberry...
  - pnutjam 8y ago
    I use an APU, but with any netboot small computer, I find it easier to netboot a simple linux build and dd the image via netcat, vs plugging and unplugging the card. My notes for pfsense: receiving machine: netcat -l 2222 | gzip -dc | dd of=/dev/sda sending machine: dd if=pfSense-2.2.4-RELEASE-2g-i386-nanobsd.img.gz |netcat 10.10.10.101 2222
    - namibj 8y ago
      replace dd with shell redirection or cat...
ljcn 8y ago
Specifically, for those wondering http://boot.netboot.xyz http://boot.netboot.xyz which in turn does http[s]://boot.netboot.xyz/menu.ipxe
- candiodari 8y ago
  I don't understand the complaints about this. What does https buy you in this case ? Security against your client-server communications' contents being observed by third parties. So here https ... gives ... confidentiality ... to ... public ... images. Well that's useful ! It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ... So what's the point of https in this situation ? Certificate, cert pinning, ... are all useless in this situation (certificate only helps on repeat visits, which of course never applies in this situation. Cert pinning only helps for specific sites (not this one) and even if it did, only when the originating software is really up to date (which is just not going to be the case here). So you can just as well say that http is perfectly secure in this case. Or at least ... as secure as https is going to be. There's quite a bit more to security than "use https".
  - LeonM 8y ago
    > What does https buy you in this case ? It ensures the response from the webserver really is from netboot.xyz, and not from any mitm server. > It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ... Can you elaborate? How would you spoof the server response without having a valid certificate key for the netboot.xyz domain?
    - gsich 8y ago
      For this to work trusted CAs need to be compiled into the iPXE binary. Since those can change you'll need to update that binary from time to time. Or ignore cert warnings, which reduces the security to plain HTTP.
    - kpcyrd 8y ago
theantonym 8y ago
Hi, owner of https://netboot.xyz https://netboot.xyz here. netboot.xyz has https support, with http support still being in place for those that don't have https support compiled into iPXE as it's not compiled by default. I'd recommend checking out the site directly if this is something that interests you. All of the source code running the site is on github as well and we're always open to contributions. We also always try to retrieve the installer kernels directly from the OS supported mirrors when possible so that they are pulled from trusted sources.
- LeonM 8y ago
  Hi, thanks for the work! I believe I first discovered netboot.xyz on a show HN. I have set up the DHCP in my lab to serve netboot.xyz, so I can experiment with different OS'es without much hassle. It has been great so far.
  - m-p-3 8y ago
    I even used it successfully on a VPS which had a limited about of OSes available. Awesome project!
- bubblethink 8y ago
  netboot.xyz is great! My main use case is to boot things off of drac/ilo etc. If you have a remote server hosted in a datacenter and have struggled to use drac's virtual iso feature, boot the netboot iso. Since it's tiny, it works great for booting, and it switches to the primary NIC once the OS is booting. If you try to use your full iso with drac, it will be painfully slow because it goes through several layers of indirection (reverse proxies set up by your provider, the weird drac driver etc.)
- rwmj 8y ago
  Do you serve the main images over tftp and is it reliable? We have been building an NBD server with this use case in mind and had on and off discussions with Foreman people about a similar case. In theory NBD should be much more efficient since it will only serve the main image on demand (but if you want you can still use it like tftp by copying /dev/nbd0 to a ram disk at boot). It also supports TLS. https://github.com/libguestfs/nbdkit https://github.com/libguestfs/nbdkit https://github.com/libguestfs/nbdkit/blob/master/plugins/floppy/nbdkit-floppy-plugin.pod https://github.com/libguestfs/nbdkit/blob/master/plugins/flo...
foxhop 8y ago
I always assumed people who use netboot are running a distribution mirror inside their "data center".

kashyapc 8y ago

This year also marks the 15th anniversary of QEMU.

rwmj 8y ago

The source for F-Bird the boot sector game (day 1) is here: https://github.com/nanochess/fbird https://github.com/nanochess/fbird and it's an incredible bit of engineering. 3 unused bytes too :-)

_RPM 8y ago

I’m surprised no one is complaining that mentioning Christmas is politically incorrect.

m-p-3 8y ago

netboot.xyz is such an awesome project. I added it to most of my USB boot disks as a grub entry (on my SystemRescueCD USB thumbdrive, etc), so I'm almost never stuck when I need to deploy an OS on the go.

sigjuice 8y ago

Hoping for some cool non-x86 and non-Linux systems.

kashyapc 8y ago

There are still a couple of open slots, so feel free to send ideas (or even better -- prepared images) to the contact e-mail address mentioned on the website.