Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

qemu-advent-calendar.org

Post reply on HN
Print view View original

11–20 of 37 posts

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

#11

Post by LeonM »

xaduha wrote: post #9
LeonM wrote: post #3

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.

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.

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 ;-)

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

#12

Post by [deleted] »

xaduha wrote: post #9
LeonM wrote: post #3

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.

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.

[deleted]

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

#13

Post by ljcn »

LeonM wrote: post #3

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.

Specifically, for those wondering

http://boot.netboot.xyz

which in turn does

http[s]://boot.netboot.xyz/menu.ipxe

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

#14

Post by PyroLagus »

xaduha wrote: post #9
LeonM wrote: post #3

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.

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.

I don't know about other ones, but you can netboot the Raspberry Pi 3: https://www.raspberrypi.org/documentation/hardware/raspberry...

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

#15

Post by theantonym »

LeonM wrote: post #3

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.

Hi, owner of 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.

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

#17

Post by LeonM »

theantonym wrote: post #15
LeonM wrote: post #3

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.

Hi, owner of 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 t…

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.

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

#18

Post by syn0byte »

jai_ wrote: post #6
LeonM wrote: post #3

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.

Is there significant risk in booting untrusted OS images within Qemu?

Short Answer: Yes.

Historic(2015) VM escape example 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'.

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

#19

Post by m-p-3 »

LeonM wrote: post #17
theantonym wrote: post #15

Earlier quoted context omitted.

Hi, owner of 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 t…

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.

I even used it successfully on a VPS which had a limited about of OSes available. Awesome project!

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

#20

Post by candiodari »

ljcn wrote: post #13
LeonM wrote: post #3

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.

Specifically, for those wondering http://boot.netboot.xyz which in turn does http[s]://boot.netboot.xyz/menu.ipxe

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

Post reply on HN