[HN Gopher] I have come to bury the BIOS, not to open it: The ne...
___________________________________________________________________
I have come to bury the BIOS, not to open it: The need for holistic
systems
Author : pclmulqdq
Score : 79 points
Date : 2022-10-09 21:14 UTC (1 hours ago)
(HTM) web link (www.osfc.io)
(TXT) w3m dump (www.osfc.io)
| lifeisstillgood wrote:
| Link to the other talk he references in this talk
|
| https://youtu.be/36myc8wQhLo
|
| And yes, this is (as ever) a call to arms on fixing a massive
| security problem we all have.
| pclmulqdq wrote:
| This is an amazing talk, and I think I have seen it on HN
| before. It lays out the problem of operating systems on modern
| computers well. I'm not sure that it offers the right solution
| by continuing to offer a system with the same set of
| abstraction layers as a solution to the problem of the
| "operating system" abstraction.
|
| I think the folks at Oxide are probably closer to the right
| track by silo-busting the BIOS, OS, and hypervisor layers of a
| modern VM-hosting stack.
|
| Edit: I should also add that this talk lays out a huge, gaping
| hole in the field of OS research, which might be its most
| important contribution.
| jstgord wrote:
| What is the truth of this ?
|
| I would really like to know if my x86 'linux PC', is actually
| running another 'hypervisor' OS that runs Linux - it seems like a
| recipe for security vulnerabilities.
|
| If so, there are a lot of Qns :
|
| - what OS, is it up to date ?
|
| - can this OS be communicated with from the network ?
|
| - on which chips does it run ?
|
| - can it be re-flashed / upgraded / replaced ?
|
| - can it interrupt/schedule my normal os ?
|
| - how much CPU/power does it use ?
|
| I would certainly trust an Oxide supplied (Rust) bare metal open-
| source low-level OS to host linux vms on my dev machine, than
| say, a totally opaque binary blob that the US government has
| forbidden xyz company from talking about.. just to speculate
| wildly.
|
| I also think Oxide has wider market that just the server space -
| eg. one has to do all sorts of shenanigans to get a core freed up
| so that you can run timing/latency sensitive apps, without
| getting interrupted by linux threads doing noisy housekeeping on
| each core.
| mlindner wrote:
| > I would really like to know if my x86 'linux PC', is actually
| running another 'hypervisor' OS that runs Linux - it seems like
| a recipe for security vulnerabilities.
|
| There's not so much a "hypervisor" OS, but instead a congealed
| set of many different OSes, some realtime OSes, some possibly
| old Linux variants, some possibly closed source proprietary
| one-off OSes. I suggest taking a look at the talk Bryan
| mentioned: https://www.youtube.com/watch?v=36myc8wQhLo
| userbinator wrote:
| Those summary paragraphs feel like they were written in a
| deliberately obfuscated style; not exactly a good first
| impression.
|
| _Rather than have one operating system that boots another that
| boots another, we have returned the operating system to its roots
| as the software that abstracts the hardware: we execute a single,
| holistic system from first instruction to running user-level
| application code._
|
| ...also known as single-purpose firmware for an embedded system.
| I 'm in agreement with the other comment here that this is not a
| good idea. Standardised interfaces like what the BIOS provides
| lets the OS not be tied to subtle differences in hardware.
| captainmuon wrote:
| Having worked with devicetrees and hated it, I don't like this
| idea. I don't like the modern world of ARM and embedded where you
| have hardcoded firmware images for every single device. I like
| the x86 model, where you have a one size fits all boot disk which
| just loads different drivers. You don't _port_ your OS to a new
| computer, you just write drivers for the new hardware parts. And
| your hardware describes itself to the OS.
|
| Granted, UEFI is grotesquely complicated. Probably you could
| replace most of it with a EEPROM that has a mapping of device ID
| to memory address, and some instructions how to speak to the
| embedded controller (basically, ACPI).
|
| Unfortunately, UEFI/ACPI or simliar seems to be going nowhere in
| the ARM world, so it doesn't seem installing Windows/Linux is
| going to be as easy on ARM as on x86 anytime soon.
| mlindner wrote:
| You realize that you're just moving the ball around on who
| provides what, right? Someone has to write that software that
| "describes itself to the OS" and rather than having the
| hardware describe itself to the OS, why can't the OS itself
| determine what hardware it has?
|
| That "describes itself to the OS" part is actually often being
| done by a complete OS as well.
|
| > Unfortunately, UEFI/ACPI or simliar seems to be going nowhere
| in the ARM world, so it doesn't seem installing Windows/Linux
| is going to be as easy on ARM as on x86 anytime soon.
|
| That's a really good thing. Bryan rants about ARM trying to go
| that way and thinks it's a terrible idea. I'm glad it's
| failing, assuming that's actually the case.
| gjsman-1000 wrote:
| > Bryan rants about ARM trying to go that way and thinks it's
| a terrible idea. I'm glad it's failing, assuming that's
| actually the case.
|
| I'd be curious why because the PC model seems to be _way_
| more user-friendly, competition-friendly, and long-term-
| reliable than the current ARM model. I wish I could just
| download an ISO of Android 13 and install it on almost any
| Android phone like I could Windows.
| mlindner wrote:
| Well it's in the talk, he spends considerable time on the
| subject in fact. I suggest taking a watch.
| catiopatio wrote:
| Historically, OpenFirmware provided exactly what you were
| asking for -- self-describing devices, device driver methods
| hanging off the device nodes, and portable, architecture-
| independent bytecode-based option ROM drivers on expansion
| cards.
|
| Devicetree is a paired down version of OF; they retained the
| tree containing key/value device metadata, and dropped all the
| good bits.
| tremon wrote:
| How are _architecture-independent bytecode-based option ROM
| drivers_ the good bits in the context of open source systems?
| catiopatio wrote:
| You could ship bootable PCI cards that worked on any OF-
| capable architecture.
|
| Open source doesn't mean not shipping binaries.
| vetinari wrote:
| It was Forth bytecode; the disassembly was pretty readable,
| without any fancy tools, straight from the OF console (at
| least on PPC Macs).
| userbinator wrote:
| _so it doesn 't seem installing Windows/Linux is going to be as
| easy on ARM as on x86 anytime soon._
|
| From firsthand experience, I can say that at least installing
| Linux on a UEFI ARM system of the type that QEMU emulates was
| _surprisingly_ straightforward, and even the ARM version of
| Windows seemed to detect the virtual hardware just fine.
|
| ...and I say this as someone who has worked on the PC platform
| for over 3 decades, and am a fan of the original BIOS. UEFI is
| a bloated mess, but it 's better than nothing.
| mort96 wrote:
| But most ARM hardware aren't "UEFI ARM system[s] of the type
| that QEMU emulates", which is the problem.
| bcantrill wrote:
| I think it can be fairly said that the thesis of the talk is
| that UEFI is not, in fact, better than nothing -- and that in
| a literal sense, having nothing (along with a well-documented
| part!) is vastly preferable to UEFI.
| zozbot234 wrote:
| Well-documented parts are few and far between in the ARM
| space. Anyway, if you have a really well-documented part,
| it will also be supported by lightweight solutions like
| coreboot (for x86) and U-Boot (for other archs). You're not
| going to be limited by UEFI either way.
| mlindner wrote:
| Really good talk by Bryan Cantrill (co-founder of Oxide Computer
| COmpany) on the problems with closed source firmware and the need
| to move away from BIOS and EFI and how they booted their own x86
| AMD custom board system all made with open source firmware and
| without using AMD's firmware.
| pclmulqdq wrote:
| I have booted a few SoCs without a BIOS or anything of the sort
| before (nothing nearly as big as an AMD Milan chip). Doing this
| with a huge, fast chip is really impressive from the folks at
| Oxide. DDR5 DRAM training is also a ridiculously complicated
| and touchy exercise, as is some of the PCIe link training that
| (according to the talk) Linux/Unix handles.
|
| Edit: this board uses DDR4, not DDR5.
| mustache_kimono wrote:
| I don't know about DDR5, etc., but coreboot apparently has
| its own DRAM training code if any one cares to take a look.
| mlindner wrote:
| Apparently the DRAM training is apparently one piece of AMD
| firmware I believe they re-used. Though I had trouble
| following that part. I think they said that, but they only
| didn't do it because they didn't need to because they had to
| pick and choose battles.
|
| Edit: Yes, I believe he says they used the AMD firmware for
| the PSP (Platform Security Processor).
|
| Edit2: This post may actually be incorrect. Please go watch
| the talk. I'm not sure anymore.
| bcantrill wrote:
| No, you're correct: the PSP does DIMM training. Also, note
| that this is AMD Milan, so it's DDR4, not DDR5 -- DDR5 is
| still forthcoming from both AMD and Intel.
| pclmulqdq wrote:
| DDR4 link training is a bit easier to comprehend than
| DDR5, but still a headache. I think almost every high-
| performance SoC uses an auxiliary processing core for
| link training at this point (including large FPGAs).
|
| I have been waiting for someone to find a security
| vulnerability in one of these cores.
| mlindner wrote:
| One part I couldn't follow on your talk is which software
| is Oxide designed and which is vendor supplied software?
| Have you really stripped out every piece of vendor
| software from the product? Or are there still some parts
| that are vendor supplied black boxes?
|
| The question after your talk implied that DIMM training
| was still being done by non-Oxide software.
| convolvatron wrote:
| I've worked on this before. We had explicit help from AMD -
| their documentation is better than Intels for this stuff, but
| still.
|
| if it weren't for linux's dependence on the bios pci and memory
| probes, you could really cut out all that crap. you need to
| program the memory controllers and bring in the kernel from
| storage.
| Teknoman117 wrote:
| Is Linux actually dependent on the firmware's PCIe probe? You
| can have the kernel do probe and enumeration if you want.
|
| (Outside of the process of getting into the kernel. Most x86
| users are going to be booting off of storage that's behind
| PCIe somehow.)
|
| Edit - for clarity, I mean calling back into firmware after
| boot for PCIe functionality.
| aidenn0 wrote:
| Anyone else worried by the title that Bryan is going to setup an
| autocratic triumvirate?
| encryptluks2 wrote:
| I'm not exactly worried but it wouldn't surprise me if he
| wanted to.
| xdmr wrote:
| No, I am Ole Torvalds the poet!
| rrss wrote:
| Here was the BIOS, when comes such another?
| lifeisstillgood wrote:
| Friends, Romans, Countrymen, lend me your binaries?
| waynecochran wrote:
| But the need the BIOS offers lives after it, and
| proprietary systems are interred within its bones.
| zokier wrote:
| Its kinda difficult to understand what are the key differences
| between their approach and what coreboot does with Linux payload,
| which afaik does not use any BIOS/UEFI layer in between and also
| is pretty minimal on coreboot size => boot as early as possible
| to Linux
| mlindner wrote:
| Someone from Oxide (maybe Bryan) talked a bunch about how the
| philosophy of Oxide differs from Coreboot somewhere. I remember
| either reading about it or hearing it, but I can't for the life
| of me remember where I heard/read it.
___________________________________________________________________
(page generated 2022-10-09 23:00 UTC)