It is so cool to see some bare metal OSs being built. Do projects like this pave the way for a better standard ISA and less driver code, like the problem described in Casey Muratori's video "the 30 million line code problem"? I'm a bit new to this space, but this seems like a step in that direction.
To study how chips work, MIT researchers built their own operating system
41–50 of 64 posts
Re: To study how chips work, MIT researchers built their own operating system
#42It is so cool to see some bare metal OSs being built. Do projects like this pave the way for a better standard ISA and less driver code, like the problem described in Casey Muratori's video "the 30 million line code problem"? I'm a bit new to this space, but this seems like a step in that direction.
Hardware is getting more specialized these days. It's becoming more difficult than ever to write bare metal code. I don't think most (any?) software wants to manage the details a BSP solves for them.
Re: To study how chips work, MIT researchers built their own operating system
#43Earlier quoted context omitted.
At the risk of sounding extremely dumb, I have a question for you: if the hardware is susceptible to something that you can't actually reproduce with the software everyone runs on it, who should care, and why? Is it even really fair to call it a vulnerability at that point? Is the idea that this is supposed to help identify a different mechanism of exploiting the vulnerabilities with the shipped OS too? To give an an…
Great analogy. Li-ion batteries have several layers of defense against exploding, one of which are vents that, if all else fails, let the hydrogen gas safely escape rather than building up. It's perfectly fair for independent testers to say "we haven't found any flaws in the protection circuitry yet, but we should bypass it to see if the vents work as designed".
I'm not disputing that it's fair to investigate that. What I'm asking is if it's fair to then call it a vulnerability without establishing that the thing is, in fact, vulnerable as a result.
I would say it's like calling the battery a fire hazard if the vents don't work, but actually that's not analogous because the necessity for vents doesn't merely arise from the need to protect against bad design of the protection circuitry. They're needed for safety even if your circuitry design is flawless. So the analogy is actually kind of poor in that regard.
Re: To study how chips work, MIT researchers built their own operating system
#44It is so cool to see some bare metal OSs being built. Do projects like this pave the way for a better standard ISA and less driver code, like the problem described in Casey Muratori's video "the 30 million line code problem"? I'm a bit new to this space, but this seems like a step in that direction.
The only way to lessen the need of drivers would be to have more standardized and stable hardware interfaces and peripherals.
Re: To study how chips work, MIT researchers built their own operating system
#45Not to take away from the authors' work, but this was actually the approach taken by some engineers while Spectre / Meltdown were still under embargo. Not sure if they ever mentioned their work publicly so I will avoid naming them, but some talented folks from Microsoft who basically came to the same conclusion that a specialized environment free of noise was necessary both to test mitigations and find variants.
Related (2019): https://gamozolabs.github.io/metrology/2019/08/19/sushi_roll... https://gamozolabs.github.io/metrology/2019/12/30/load-port-...
I suppose they did make their work public after all :)
Thank you for pulling up the references.
Re: To study how chips work, MIT researchers built their own operating system
#46[dead]
Re: To study how chips work, MIT researchers built their own operating system
#47 The "outer kernel thread" idea -- userspace memory but kernel privileges --
is such an obviously good idea in retrospect that I'm surprised nobody
did it before. You spend half your time in microarchitecture research
just trying to control for OS noise.
The Apple M1 phantom speculation finding is wild. I wonder if this is
actually a bug in Apple's implementation or if CSV2 just has a
fundamental race condition between the protection and the i-cache fill.
The paper makes it sound like the latter.
Also, 31k LOC for a from-scratch kernel supporting three ISAs is...
not a lot. That's either very impressive or they're skipping a lot of
stuff a production kernel needs. Curious which.Re: To study how chips work, MIT researchers built their own operating system
#48Earlier quoted context omitted.
Great analogy. Li-ion batteries have several layers of defense against exploding, one of which are vents that, if all else fails, let the hydrogen gas safely escape rather than building up. It's perfectly fair for independent testers to say "we haven't found any flaws in the protection circuitry yet, but we should bypass it to see if the vents work as designed".
I'm not disputing that it's fair to investigate that. What I'm asking is if it's fair to then call it a vulnerability without establishing that the thing is, in fact, vulnerable as a result. I would say it's like calling the battery a fire hazard if the vents don't work, but actually that's not analogous because the necessity for vents doesn't merely arise from the need to protect against bad design of the protection…
This is why a distinction is often drawn between vulnerabilities and exploits — many more things can be weaknesses in a system that can only be exploited in combination with other vulnerabilities.
An obvious example is web browsers, where a vulnerability can easily be uninteresting because it lives in a sandboxed process… until you find a sandbox escape, then it is critical.
As long as you suspect there may be other vulnerabilities in the other layers, it is worthwhile investigating and fixing them, because defence in depth only works until someone manages to put together a full chain.
Re: To study how chips work, MIT researchers built their own operating system
#49Hi everyone, Joseph (paper author) here. You can find Fractal on Github: https://github.com/jprx/fractal The full paper, slides from my S&P talk, and all our experiment data can be found at the Fractal project website here: https://fractal-os.com We've been building Fractal internally for a very long time (first commit was almost exactly 2 years ago), so it's exciting to finally share it with the world. Let me know w…
have you considered forking existing OS and implementing changes that you needed instead?
it's hard for me to justify the tremendous effort of implementing the OS from scratch, instead of adding the functionality that you need to for example linux or xv6.
> (it) exposes primitives that let a single experiment switch privilege levels at runtime while executing the same instructions in the same address space.
i think that it can be achieved by following linux modifications:
- make all executable pages executable both in user and kernel mode
- define a new syscall number, let's call it 'fractal'
- upon 'svc' trap (syscall), if it's a fractal syscall, just branch to instruction after the 'svc' (still in kernel mode! no 'eret', as opposed to no-fractal syscalls)
and.. that's it?
Re: To study how chips work, MIT researchers built their own operating system
#50Hi everyone, Joseph (paper author) here. You can find Fractal on Github: https://github.com/jprx/fractal The full paper, slides from my S&P talk, and all our experiment data can be found at the Fractal project website here: https://fractal-os.com We've been building Fractal internally for a very long time (first commit was almost exactly 2 years ago), so it's exciting to finally share it with the world. Let me know w…
have you considered forking existing OS and implementing changes that you needed instead? it's hard for me to justify the tremendous effort of implementing the OS from scratch, instead of adding the functionality that you need to for example linux or xv6. > (it) exposes primitives that let a single experiment switch privilege levels at runtime while executing the same instructions in the same address space. i think t…
From the article:
> [...] they usually run their experiments on top of an operating system that was never built for the job. They open up macOS or Linux, patch the kernel by hand, and hope the modifications hold. The approach is unstable, hard to reproduce, and on Apple’s platforms, slated for deprecation.
I'd also like to hear more about why that's a problem, not because I disagree, but because I don't know jack about this and it's fascinating. However, I could imagine at least a couple of advantages to this approach.
* It's not a general purpose OS. It doesn't have to support 10,000,000 different accessories, just enough to get the kernel booted so researchers can interact with the hardware.
* You don't have to deal with general purpose constraints here. Who needs something like a fair scheduler when the goal is to give researchers direct access to the hardware for minutes at a time?
* If broad hardware support and universal use case support aren't goals, you can write something vastly simpler that basically loads a program and turns it loose on the underlying bare metal. I imagine that'd make repeatability vastly easier, with no "oops, an Ethernet packet came in so I need to service that mid-test" interrupt{,ion}s.
Those would seem like good reasons to make a minimal kernel that doesn't get between the researchers and their work.