4 ms·

That's the idea. If the OS is immutable, where do you put them? They would be in the PXE image. There was one time I flubbed on this actually. I had to chang

That's the idea. If the OS is immutable, where do you put them? They would be in the PXE image. There was one time I flubbed on this actually. I had to change export options on our PXE servers to fix something and I forgot to change it back adding my poor excuse of multitasking and being lazy. This was in a Dev environment we also used PXE in production believe it or not. A developer sitting across from me said he changed something in the image by mistake and I said, "That's not possi... oh crap." It was cool of them to call it out right away. Attackers probably won't be so kind.

jchw 3y ago
For what it's worth though, that's possible to mitigate. I don't believe Mullvad uses PXE and they do have a "secure boot" validation chain, starting from Coreboot on the hardware. https://mullvad.net/en/blog/2022/1/12/diskless-infrastructure-beta-system-transparency-stboot https://mullvad.net/en/blog/2022/1/12/diskless-infrastructur...
- ignoramous 3y ago
  It is an improvement, for sure. secure boot, as painful it is to get right, doesn't help when the vendor runs its own things with elevated privileges, like they are known to do: https://news.ycombinator.com/item?id=34085635 https://news.ycombinator.com/item?id=34085635 Doubly so, when the said things are not only closed source but vulnerable themselves: https://archive.is/6ClWm https://archive.is/6ClWm Does coreboot help in mitigating vuln in privilged vendor blobs?
  - jchw 3y ago
    Well, with Coreboot, you at least know the very first instructions executed by the x86 cores are under your control. That's all it can really do. Whatever else lurks beneath is really impossible for anyone to scrutinize without insane capital or insider knowledge. Mitigating the risk of Intel ME is obviously something that is complicated. The "state of the art" so-to-speak is really just rendering it non-functional. This isn't strictly related to Coreboot; that said, Coreboot has a page about ME: https://www.coreboot.org/Intel_Management_Engine https://www.coreboot.org/Intel_Management_Engine And in general, when you're running Coreboot, you're running significantly less privileged blackbox blobs (possibly none in some rare cases), and in general, the surface area of Coreboot is going to be dramatically tinier than any typical UEFI system firmware. So it's absolutely worth it in that regard. There's never going to be a "perfect" option here with how complex things have gotten, but I think that you can at least say that Mullvad has taken almost any reasonable step, and perhaps a few steps that are beyond what many would consider reasonable, towards developing effective mitigation of the risks of rootkits, bootkits and malicious/unwanted vendor code running on their "diskless" architecture. Of course, you still have to trust Mullvad. Trust is definitely a meaty human-y experience, and the cold rational part of our brain craves some kind of technically-bulletproof way to prove that it's truly safe, secure, and private, but that's just not possible. Best you can do is layer enough assurances on top of each-other in a way that at least some layers are completely independent of others for maintaining your operational security. Far easier said than done, and obviously how rigorously one approaches this will vary on paranoia. At some point you have to pick your middle-ground I suppose.
    - ignoramous 3y ago
      Thank you. Appreciate your answers.
generalizations 3y ago
> we also used PXE in production believe it or not Wait why would this be a bad thing?
- LinuxBender 3y ago
  It depends on your use case, SLA's and configuration management role/structure discipline. There are different schools of thought on diskless boot which is not truly diskless as the images have to be shared from somewhere meaning that disk availability goes from 1:1 to many to one increasing the blast radius of outages when the NAS fails or network re-convergence occurs. They all fail regardless of how many millions one spends and in my experience the more millions the more glorious the failure that should never happen. For some companies this is fine if they have the discipline to balance their servers across many NAS servers in a strict hierarchy that facilitates a smaller predictable POD structure blast radius. But that's a bigger topic than I could possibly cover in a HN comment. It also depends on how the OS is being used and how writable spaces tmpfs vs disk are being used. This will all vary wildly across different business models.

jchw 3y ago

For what it's worth though, that's possible to mitigate. I don't believe Mullvad uses PXE and they do have a "secure boot" validation chain, starting from Coreboot on the hardware. https://mullvad.net/en/blog/2022/1/12/diskless-infrastructure-beta-system-transparency-stboot https://mullvad.net/en/blog/2022/1/12/diskless-infrastructur...

ignoramous 3y ago
It is an improvement, for sure. secure boot, as painful it is to get right, doesn't help when the vendor runs its own things with elevated privileges, like they are known to do: https://news.ycombinator.com/item?id=34085635 https://news.ycombinator.com/item?id=34085635 Doubly so, when the said things are not only closed source but vulnerable themselves: https://archive.is/6ClWm https://archive.is/6ClWm Does coreboot help in mitigating vuln in privilged vendor blobs?
- jchw 3y ago
  Well, with Coreboot, you at least know the very first instructions executed by the x86 cores are under your control. That's all it can really do. Whatever else lurks beneath is really impossible for anyone to scrutinize without insane capital or insider knowledge. Mitigating the risk of Intel ME is obviously something that is complicated. The "state of the art" so-to-speak is really just rendering it non-functional. This isn't strictly related to Coreboot; that said, Coreboot has a page about ME: https://www.coreboot.org/Intel_Management_Engine https://www.coreboot.org/Intel_Management_Engine And in general, when you're running Coreboot, you're running significantly less privileged blackbox blobs (possibly none in some rare cases), and in general, the surface area of Coreboot is going to be dramatically tinier than any typical UEFI system firmware. So it's absolutely worth it in that regard. There's never going to be a "perfect" option here with how complex things have gotten, but I think that you can at least say that Mullvad has taken almost any reasonable step, and perhaps a few steps that are beyond what many would consider reasonable, towards developing effective mitigation of the risks of rootkits, bootkits and malicious/unwanted vendor code running on their "diskless" architecture. Of course, you still have to trust Mullvad. Trust is definitely a meaty human-y experience, and the cold rational part of our brain craves some kind of technically-bulletproof way to prove that it's truly safe, secure, and private, but that's just not possible. Best you can do is layer enough assurances on top of each-other in a way that at least some layers are completely independent of others for maintaining your operational security. Far easier said than done, and obviously how rigorously one approaches this will vary on paranoia. At some point you have to pick your middle-ground I suppose.
  - ignoramous 3y ago
    Thank you. Appreciate your answers.

generalizations 3y ago

> we also used PXE in production believe it or not Wait why would this be a bad thing?

LinuxBender 3y ago
It depends on your use case, SLA's and configuration management role/structure discipline. There are different schools of thought on diskless boot which is not truly diskless as the images have to be shared from somewhere meaning that disk availability goes from 1:1 to many to one increasing the blast radius of outages when the NAS fails or network re-convergence occurs. They all fail regardless of how many millions one spends and in my experience the more millions the more glorious the failure that should never happen. For some companies this is fine if they have the discipline to balance their servers across many NAS servers in a strict hierarchy that facilitates a smaller predictable POD structure blast radius. But that's a bigger topic than I could possibly cover in a HN comment. It also depends on how the OS is being used and how writable spaces tmpfs vs disk are being used. This will all vary wildly across different business models.