PSOS. Now that was something I never expected to see again.
I'd worked on the previous system, KSOS, mentioned in the article. I wrote the file system and all of the drivers, while at an aerospace company. We'd used formal specifications in SPECIAL.
Nobody could prove anything about SPECIAL yet, but I wrote a compiler-like syntax and type checker, so it was at least type valid. It was a good language for writing down invariants. I used it to
describe file system consistency and recovery.
Another group started work on PSOS, but never got past the design stage.
I managed to avoid getting sucked into that, because it looked like a death march.
SRI, which was a think tank, just did abstract designs. It was extreme waterfall.
One group wrote a spec, and a contractor implemented it. This did not work too well.
They did have Boyer and Moore, and those two made real progress on proof systems.
I used their prover for another project, and talked to them a lot.
But they were not closely associated with PSOS. Specifications in SPECIAL, which is quantifier-oriented were not
compatible with Boyer-Moore theory, which uses constructive mathematics and recursive functions.
The big problem in that era was that the hardware wasn't ready for secure operating systems. KSOS was for the 16-bit PDP-11 line, and it took a cram job to make it fit. The Modula I compiler wasn't very space-efficient. Optimizations had to come out to make it fit, and the result was too slow.
Microprocessors weren't quite ready yet. Neither Intel nor Motorola had a decent MMU.
The suitable target machines were all minicomputers, which were on the way out.
PSOS never got far enough to pick an implementation target.
Capability-based systems work, but they create a new problem - ticket management. You have lots of tickets which let some piece of software do something, and now you have to track and manage them. It's like physical key control. It's the same reason that Windows access control lists are little used.
You also still have the delegation problem - A can't do X, but A can talk to B, which can do X. Most modern attacks involve that approach.
Most of the early secure OS work was funded by NSA. NSA had an internal division in those Cold War days - the important stuff was at Fort Meade, and the less-important stuff was some distance away at FANX, an annex out by Friendship (now BWI) Airport. FANX had personnel ("HR" today), training (including the cryptographic school), safe and lock testing and evaluation, networking, and computer security. Being exiled to FANX was bad for careers. This set back the computer security work.
There was also industry pushback. The operating system testing criteria were borrowed from the safe and lock people. Something submitted for testing got two tries. First try, the evaluators told the vendor what was wrong. Second try was pass/fail with no feedback. That's how locks for vaults were evaluated. Computer vendors (there was not much of a separate OS industry yet) hated this. They eventually got a testing system where "certified labs" did the testing, and a vendor could have as many tries as they were willing to pay for.
Some good secure OSs came out of that, and passed testing. But they were obscure, and for obscure hardware - Prime, Honeywell, etc. If you dig, you can find the approved products list from the 1980s.
What really killed all that was the growth of the computer industry. In the 1960s and 1970s, the government was the biggest purchaser of computers and electronics. As the industry grew, the government became a minor purchaser with a slow update cycle, and could not get design-level attention from major vendors.
There was much grumbling about this from military people, especially the USAF, as they were sidelined during the 1980s.
Good overview except for the last part. I've heard multiple things from people of the time:
1. In "If A1 was the answer, what was the question," thr author pointed out that features and assurance levels were mandated together. Buyers often didn't need specific features which made it more costly and slow to develop for nothing. The festures the market demanded weren't present. So, TCSEC-certified, high security was unmarketable.
2. In a similar vein, Lipner's "Ethics of Perfectiom" talked about how it took two to three quarters to make a significant change to the VAX Security Kernel. The market was wanting major features every quarter. They couldn't afford to lag behind all the competition in velocity.
3. Another person mentioned changes in DOD (other government?) purchasing policy to order COTS products from many vendors. Those vendors were also sometimes paying campaign contributions or hiring ex-Pentagon people to be favored. Their products weren't TCSEC A1. So, corruption and supplier diversity both forced government agencies to use insecure products which made secure products less competitive.
4. Similarly, the NSA started pushing lower-assurance like CC EAL4 and later Commercial Solutions for Classified. They were also selling GOTS gear guaranteed to get their approval. In these ways, they caused a surge of low-assurance competition with high-assurance vendors.
5. They promoted, required expensive certs for, and basically killed the Seperation Kernel Protection Profile. Spending millions on something that ultinately didn't matter to them doesn't inspire more EAL6+ certifications.
I understand why in 1979 and perhaps until mid 1990s capability OS architecture might have been irrelevant and excessive. But after that, it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere. Instead, we're stuck with legacy systems, which now contain layers of layers of abstractions and security measures. User rights, anti-virus software, vetting (signatures, hashes, app-store verification) - all become obsolete or near-obsolete in a capability-based system where a program simply doesn't have access to anything by default. Part of the appeal of virtualization is also due to the fact that it isolates programs (for instance, I only run npm inside Docker container these days, because chances are some package will contain malware at some point).
Part of it is inertia, but part of it is ignorance. Enthusiasts spend tons of money and effort building another GPU enabled terminal or safe programming languages - and maybe that's fine, but I wonder what we could've accomplished if people were simply aware what a well-designed capability OS could be like, because this is literally the only OS paradigm in existence (that I know of) that's even worth any serious effort.
If you go through old CS OS texts on the matter, they really didn't have the same understanding of capabilities then as the later object-capabilities (ocap) model would introduce. Typically they would show an access control matrix, note that acls were rows and capabilities columns and note that they are duals of one another. They're the same, acls are easier to manage, done.
I’m not going to argue against much of the content of this paper, but it should be pointed out that their argument in the middle section against the “confinement myth” seems pretty bogus. They say that you can isolate the capability read/write resource from the data read/write resource, but… this makes absolutely no sense. Bits are bits. If you assume some out-of-band isolation of capability distribution then you’ve changed the game, but even that isn’t enough for me to believe that isolation is possible.
We kind of have the taste of what capability-based OS would look like in form of a web browser: you can open a web page with a potentially-malicious code and it doesn't have access to any of your files or sensitive data unless you explicitly allow it to.
We also have it on mobile operating systems, although some things are a rather coarse-grained.
On desktop there's just a lot of inertia. Everyone switching to a new thing is kind of impossible, and some simple add-on to existing systems would look like containers/docker.
I think capability-oriented programming languages might actually be an easier way to switch to that model, as it's much easier to adopt a new application than a new OS. E.g. with language-level capabilities (ocaps) you can implement a safe plugin system. That's pretty much non-existent now and is quite relevant - e.g. getting pwned via an IDE plugin is the reality.
So maybe a "new Emacs" can be a way to get people to adopt capabilities beyond what we already have in the browser/cloud/etc. - IDE written in a new programming stack which is inherently secure to the point of running potentially-unsafe plugins.
None of those things become obsolete with capabilities.
You still need code signing because users need to be able to grant privileges in a way that sticks across upgrades. The object they want to privilege isn't a set of files on disk but a logical app as defined by (more or less) a brand name+app name even as it changes over time.
You still need antivirus software because users can be tricked into giving capabilities to programs that appear legit but are actually malicious.
Modern operating systems (iOS, Android) are capability oriented operating systems to the extent that makes sense. For some reason there's a meme that says capabilities are a magic wand that solves all security problems, but it's not the case.
Yeah not least of which because statically defined capabilities struggle when you have dynamic needs. Imagine you have S3 buckets. If your buckets are partitioned by application, that’s easy to protect with capabilities. Now what if you have an application that’s dynamically assigning buckets by tenant. You can’t statically assign that and you can’t even restrict yourself to buckets you created in the first place because you need a meta system to keep track of which buckets were created by which application but it’s doable (eg store data within the bucket indicating which app). But now you’ve got delegation challenges if you have two applications that need access to overlapping resources. There’s no consistent design solution. Everything is a special case to figure out.
> it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere
Wasn’t that the reason why Microsoft went allout against Java? Write once, run anywhere. JVM was a “trojan horse”
and theoretically
could have dominated the world.
I didn't mean it in the Java way. I meant that whatever operating system you're on, you can download random programs from the internet (compiled specifically for your OS or portable) and run it on your machine. It doesn't matter what they're written in or how they're run, it's possible on any OS connected to the internet and an OS with capabilities as first class citizens would isolate any program by default, denying it access to anything by default and severely limiting program's ability to cause harm, intentionally or unintentionally.
In case of updating the binary, yes, you generally want to make sure it comes from the same source and therefore cannot do damage to things it already has access to. But when you install a new program, it shouldn't have access to any resources other than the ones it creates itself, so there's no need to sign it. Further more, when installing a new program, you still have to download/import the pubkey to verify the signature from somewhere, so it's almost meaningless on the first installation. Signatures wouldn't be obsolete, but they also wouldn't be the only line of defense. Furthermore, updating can now be performed by the program itself and the program might already contain the pubkey needed to check the validity of updates.
In addition to capabilities, which implemented the principle of least privilege (and keep untrusted code sandboxed by default) there is a need for binary verification.
A check that a whatever is downloaded cannot exceed it's capabilities.
Part of the challenge is that hardware tried and has failed to be trustworthy in implementing security boundaries. The failure appears to be because a misalignment of incentives.
I think the premise of a capability based operating system can help a lot, but for something to work in the long term the incentives need to aligned.
Your point of view has an insidious lie at its core; that the user perfectly knows what she wants. That if we only give the user the ability to set capabilities, we will not need any other protection for her.
The reality is that we're water meatballs, we're so easy to fool, and we need the cold calculating power of code to protect us from ourselves.
OS design basically stagnated in the 90s. Sure, we had NT, but that was putting a dos flavoured suit on VMS. BeOS was promising, but fizzled out quickly. Everything else has either been research or for the embedded market.
Android and iOS increased security, but at the cost of much flexibility and user agency. It's some kind of progress, but I certainly wouldn't want them for Real Computers.
The Market has spoken, and people use standard consumer CPU/GPU-bodge architecture in cloud data centers. Sure there are a few quality of life features different from budget retail products, but we abandoned what Sun solved with a simple encrypted mmu decades ago.
The paper adds little to TCSEC/"Orange Book"/FOLDOC publications. Yet the poster doesn't deserve all the negative karma.
On a consumer CPU/GPU/NPU, software just isn't going to be enough to fix legacy design defects. Have a great day. =3
in larger systems the utility of sharing a single cpu/gpu complex between independent authorization domains kind of goes away. if you have 10,000 units of allocation, it never makes sense to try to share one of those until you have more than 10,000 jobs, and even then.
so it seems a lot more feasible to control access and sharing between those units and write of off the intranode case as a lost cause
It looks like you you may be interested in Qubes OS, security oriented operating system relying on strong, hardware-assisted virtualization: https://qubes-os.org. My daily driver, can't recommend it enough.
I know about it, but I'm not interested in QubeOS approach. It's VMs all the way down, while what I'm talking about is no VMs and capabilities as first class citizens and no vurtualization.
Qubes for sure not. Xen seperation on top of Linux sounds nice, but there's still this huge, insecure monolith below. Genode, Harmony or Fuchsia sound much better. And now with a secure language for the surface and drivers it would be even better.
But even better no OS, and no attack surface. Only what you need, and properly isolated.
The problem with any secure system is that they're not usable systems. Real applications and users expect to access anything from anywhere. That's the opposite of security.
One of my friends had his credentials stolen from a trojan infostealer masquerading as a video game, sent from a rando who he mistakenly trusted. If only it had to request user permission to access files outside of its folder. There's a spectrum between full access and full lockdown.
PSOS's capability-based architecture was way ahead of its time. The core idea, tag memory with unforgeable access tokens at the hardware level instead of leaning on software-defined access control lists, is finally getting real implementation, forty-plus years later. seL4 is the obvious modern inheritor. It’s a formally verified microkernel where capabilities are the basic access primitive. The seL4 team proved, in Isabelle/HOL, that the kernel's C implementation matches its formal specification exactly, no buffer overflows, no null pointer derefs, no privilege escalation. That’s the PSOS vision, actually built. CHERI, out of Cambridge and SRI, and a bit ironically building on the same institution's heritage, pushes the idea into hardware: 128-bit fat pointers with encoded bounds and permissions, enforced at the CPU level. ARM's Morello prototype showed this in silicon. A CHERI-extended CPU literally can’t forge a pointer outside its authorized memory region, the hardware traps it. The frustrating part is Miagg's point, we had the blueprint in 1979. What killed capability systems wasn’t technical, it was the Unix monoculture and the network effect of "good enough" security. Now we’re slowly rediscovering capabilities under names like "object capabilities" and "hardware enclaves." Better late than never, tbh, but it’s hard not to wonder what the internet would look like if PSOS's architecture had won.
> The core idea, tag memory with unforgeable access tokens at the hardware level instead of leaning on software-defined access control lists, is finally getting real implementation, forty-plus years later.
The IBM System/38 did this around the same time, along with its successor - the AS/400. When the AS/400 switched to POWER (or PowerPC AS), they started using standard RAM, but are still able to have a tag bit for each 16byte(?) pointer using ECC, but the instructions to do that aren't privileged. The AS/400 or "i" as it's now called is still around.
The difference between ambient authority systems, like Windows and Linux, and capability systems is the difference between a program that only uses global variables and a program that uses local variables and function parameters.
In a capability system, you pass resource capabilitys to subsystems. You can not use resource handles that were not passed to you just like a function can not access variables that were not passed to it (except for explicit global variables.
In ambient authority systems, as a common example, you can just blindly convert what are effectively strings into resource handles (the metaphorical equivalent of casting integers to raw pointers). Your access is mediated by a orthogonal system that tells you which resource handles/pointers you are allowed to use. That is like having a program that runtime checks every pointer access is allowed instead of just preventing you from manufacturing pointers.
You coordinate across subsystems by naming certain resources in the global ambient space in a coordinated fashion (effectively a global variable which is basically just a named memory location in the common memory space). That way the subsystem knows the global you put their parameters/resources in.
While you can still program like that, everybody now knows it is a terrible way to live. Parameter passing and local variables with explicit global variables is almost always the way to go. That same lesson should be learned for operating systems.
I too would like an OS where called programs don't need to call open() on strings. The shell already has <input >output redirection, but hamstrung so few ever use them. So many programs recreate the functionality with -i -o in some manner to make up for the flaws (read multiple inputs, avoid creating a file on error). Graphical programs could request a fd from a trusted file picker instead of requesting a string to call open() immediately after. That just scratches the surface, so much security and convenience to gain.
If you are interested in this I highly recommend studying SeL4. A practical industrial proven correct micro kernel used by billions of devices worldwide.
Might be people just flagging so mods can make an "Is this an LLM not?" determination. I see a lot of new accounts get flagged like this (and scanning the previous comments, ehhhhh yea maybe?).
PSOS. Now that was something I never expected to see again.
I'd worked on the previous system, KSOS, mentioned in the article. I wrote the file system and all of the drivers, while at an aerospace company. We'd used formal specifications in SPECIAL. Nobody could prove anything about SPECIAL yet, but I wrote a compiler-like syntax and type checker, so it was at least type valid. It was a good language for writing down invariants. I used it to describe file system consistency and recovery. Another group started work on PSOS, but never got past the design stage. I managed to avoid getting sucked into that, because it looked like a death march.
SRI, which was a think tank, just did abstract designs. It was extreme waterfall. One group wrote a spec, and a contractor implemented it. This did not work too well. They did have Boyer and Moore, and those two made real progress on proof systems. I used their prover for another project, and talked to them a lot. But they were not closely associated with PSOS. Specifications in SPECIAL, which is quantifier-oriented were not compatible with Boyer-Moore theory, which uses constructive mathematics and recursive functions.
The big problem in that era was that the hardware wasn't ready for secure operating systems. KSOS was for the 16-bit PDP-11 line, and it took a cram job to make it fit. The Modula I compiler wasn't very space-efficient. Optimizations had to come out to make it fit, and the result was too slow.
Microprocessors weren't quite ready yet. Neither Intel nor Motorola had a decent MMU. The suitable target machines were all minicomputers, which were on the way out. PSOS never got far enough to pick an implementation target.
Capability-based systems work, but they create a new problem - ticket management. You have lots of tickets which let some piece of software do something, and now you have to track and manage them. It's like physical key control. It's the same reason that Windows access control lists are little used. You also still have the delegation problem - A can't do X, but A can talk to B, which can do X. Most modern attacks involve that approach.
Most of the early secure OS work was funded by NSA. NSA had an internal division in those Cold War days - the important stuff was at Fort Meade, and the less-important stuff was some distance away at FANX, an annex out by Friendship (now BWI) Airport. FANX had personnel ("HR" today), training (including the cryptographic school), safe and lock testing and evaluation, networking, and computer security. Being exiled to FANX was bad for careers. This set back the computer security work.
There was also industry pushback. The operating system testing criteria were borrowed from the safe and lock people. Something submitted for testing got two tries. First try, the evaluators told the vendor what was wrong. Second try was pass/fail with no feedback. That's how locks for vaults were evaluated. Computer vendors (there was not much of a separate OS industry yet) hated this. They eventually got a testing system where "certified labs" did the testing, and a vendor could have as many tries as they were willing to pay for.
Some good secure OSs came out of that, and passed testing. But they were obscure, and for obscure hardware - Prime, Honeywell, etc. If you dig, you can find the approved products list from the 1980s.
What really killed all that was the growth of the computer industry. In the 1960s and 1970s, the government was the biggest purchaser of computers and electronics. As the industry grew, the government became a minor purchaser with a slow update cycle, and could not get design-level attention from major vendors. There was much grumbling about this from military people, especially the USAF, as they were sidelined during the 1980s.
Good overview except for the last part. I've heard multiple things from people of the time:
1. In "If A1 was the answer, what was the question," thr author pointed out that features and assurance levels were mandated together. Buyers often didn't need specific features which made it more costly and slow to develop for nothing. The festures the market demanded weren't present. So, TCSEC-certified, high security was unmarketable.
2. In a similar vein, Lipner's "Ethics of Perfectiom" talked about how it took two to three quarters to make a significant change to the VAX Security Kernel. The market was wanting major features every quarter. They couldn't afford to lag behind all the competition in velocity.
3. Another person mentioned changes in DOD (other government?) purchasing policy to order COTS products from many vendors. Those vendors were also sometimes paying campaign contributions or hiring ex-Pentagon people to be favored. Their products weren't TCSEC A1. So, corruption and supplier diversity both forced government agencies to use insecure products which made secure products less competitive.
4. Similarly, the NSA started pushing lower-assurance like CC EAL4 and later Commercial Solutions for Classified. They were also selling GOTS gear guaranteed to get their approval. In these ways, they caused a surge of low-assurance competition with high-assurance vendors.
5. They promoted, required expensive certs for, and basically killed the Seperation Kernel Protection Profile. Spending millions on something that ultinately didn't matter to them doesn't inspire more EAL6+ certifications.
So, those are the examples I remember.
I understand why in 1979 and perhaps until mid 1990s capability OS architecture might have been irrelevant and excessive. But after that, it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere. Instead, we're stuck with legacy systems, which now contain layers of layers of abstractions and security measures. User rights, anti-virus software, vetting (signatures, hashes, app-store verification) - all become obsolete or near-obsolete in a capability-based system where a program simply doesn't have access to anything by default. Part of the appeal of virtualization is also due to the fact that it isolates programs (for instance, I only run npm inside Docker container these days, because chances are some package will contain malware at some point).
Part of it is inertia, but part of it is ignorance. Enthusiasts spend tons of money and effort building another GPU enabled terminal or safe programming languages - and maybe that's fine, but I wonder what we could've accomplished if people were simply aware what a well-designed capability OS could be like, because this is literally the only OS paradigm in existence (that I know of) that's even worth any serious effort.
If you go through old CS OS texts on the matter, they really didn't have the same understanding of capabilities then as the later object-capabilities (ocap) model would introduce. Typically they would show an access control matrix, note that acls were rows and capabilities columns and note that they are duals of one another. They're the same, acls are easier to manage, done.
OP is arguably the first paper that introduces ocaps. Some of the issues are discussed in "Capability Myths Demolished" https://papers.agoric.com/assets/pdf/papers/capability-myths...
I’m not going to argue against much of the content of this paper, but it should be pointed out that their argument in the middle section against the “confinement myth” seems pretty bogus. They say that you can isolate the capability read/write resource from the data read/write resource, but… this makes absolutely no sense. Bits are bits. If you assume some out-of-band isolation of capability distribution then you’ve changed the game, but even that isn’t enough for me to believe that isolation is possible.
17 replies →
We kind of have the taste of what capability-based OS would look like in form of a web browser: you can open a web page with a potentially-malicious code and it doesn't have access to any of your files or sensitive data unless you explicitly allow it to.
We also have it on mobile operating systems, although some things are a rather coarse-grained.
On desktop there's just a lot of inertia. Everyone switching to a new thing is kind of impossible, and some simple add-on to existing systems would look like containers/docker.
I think capability-oriented programming languages might actually be an easier way to switch to that model, as it's much easier to adopt a new application than a new OS. E.g. with language-level capabilities (ocaps) you can implement a safe plugin system. That's pretty much non-existent now and is quite relevant - e.g. getting pwned via an IDE plugin is the reality.
So maybe a "new Emacs" can be a way to get people to adopt capabilities beyond what we already have in the browser/cloud/etc. - IDE written in a new programming stack which is inherently secure to the point of running potentially-unsafe plugins.
None of those things become obsolete with capabilities.
You still need code signing because users need to be able to grant privileges in a way that sticks across upgrades. The object they want to privilege isn't a set of files on disk but a logical app as defined by (more or less) a brand name+app name even as it changes over time.
You still need antivirus software because users can be tricked into giving capabilities to programs that appear legit but are actually malicious.
Modern operating systems (iOS, Android) are capability oriented operating systems to the extent that makes sense. For some reason there's a meme that says capabilities are a magic wand that solves all security problems, but it's not the case.
Yeah not least of which because statically defined capabilities struggle when you have dynamic needs. Imagine you have S3 buckets. If your buckets are partitioned by application, that’s easy to protect with capabilities. Now what if you have an application that’s dynamically assigning buckets by tenant. You can’t statically assign that and you can’t even restrict yourself to buckets you created in the first place because you need a meta system to keep track of which buckets were created by which application but it’s doable (eg store data within the bucket indicating which app). But now you’ve got delegation challenges if you have two applications that need access to overlapping resources. There’s no consistent design solution. Everything is a special case to figure out.
> it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere
Wasn’t that the reason why Microsoft went allout against Java? Write once, run anywhere. JVM was a “trojan horse” and theoretically could have dominated the world.
I didn't mean it in the Java way. I meant that whatever operating system you're on, you can download random programs from the internet (compiled specifically for your OS or portable) and run it on your machine. It doesn't matter what they're written in or how they're run, it's possible on any OS connected to the internet and an OS with capabilities as first class citizens would isolate any program by default, denying it access to anything by default and severely limiting program's ability to cause harm, intentionally or unintentionally.
Why do signatures/hashes/app-store verification become obsolete with a capability-based system?
If a binary has the capability to withdraw money from my account, I don't want that capability given to just any binary.
In case of updating the binary, yes, you generally want to make sure it comes from the same source and therefore cannot do damage to things it already has access to. But when you install a new program, it shouldn't have access to any resources other than the ones it creates itself, so there's no need to sign it. Further more, when installing a new program, you still have to download/import the pubkey to verify the signature from somewhere, so it's almost meaningless on the first installation. Signatures wouldn't be obsolete, but they also wouldn't be the only line of defense. Furthermore, updating can now be performed by the program itself and the program might already contain the pubkey needed to check the validity of updates.
I'll insert my standard plug for Genode/Sculpt OS here... Capability based, and used/maintained commercially:
https://genode.org/
I also like HarmonyOS, the most advanced secure OS nowadays. If they just would have fixed deadlocks also.
1 reply →
In addition to capabilities, which implemented the principle of least privilege (and keep untrusted code sandboxed by default) there is a need for binary verification.
A check that a whatever is downloaded cannot exceed it's capabilities.
Part of the challenge is that hardware tried and has failed to be trustworthy in implementing security boundaries. The failure appears to be because a misalignment of incentives.
I think the premise of a capability based operating system can help a lot, but for something to work in the long term the incentives need to aligned.
Your point of view has an insidious lie at its core; that the user perfectly knows what she wants. That if we only give the user the ability to set capabilities, we will not need any other protection for her.
The reality is that we're water meatballs, we're so easy to fool, and we need the cold calculating power of code to protect us from ourselves.
OS design basically stagnated in the 90s. Sure, we had NT, but that was putting a dos flavoured suit on VMS. BeOS was promising, but fizzled out quickly. Everything else has either been research or for the embedded market.
Android and iOS increased security, but at the cost of much flexibility and user agency. It's some kind of progress, but I certainly wouldn't want them for Real Computers.
3 replies →
The Market has spoken, and people use standard consumer CPU/GPU-bodge architecture in cloud data centers. Sure there are a few quality of life features different from budget retail products, but we abandoned what Sun solved with a simple encrypted mmu decades ago.
The paper adds little to TCSEC/"Orange Book"/FOLDOC publications. Yet the poster doesn't deserve all the negative karma.
On a consumer CPU/GPU/NPU, software just isn't going to be enough to fix legacy design defects. Have a great day. =3
in larger systems the utility of sharing a single cpu/gpu complex between independent authorization domains kind of goes away. if you have 10,000 units of allocation, it never makes sense to try to share one of those until you have more than 10,000 jobs, and even then.
so it seems a lot more feasible to control access and sharing between those units and write of off the intranode case as a lost cause
2 replies →
It looks like you you may be interested in Qubes OS, security oriented operating system relying on strong, hardware-assisted virtualization: https://qubes-os.org. My daily driver, can't recommend it enough.
I know about it, but I'm not interested in QubeOS approach. It's VMs all the way down, while what I'm talking about is no VMs and capabilities as first class citizens and no vurtualization.
15 replies →
One word: Qubes.
Qubes for sure not. Xen seperation on top of Linux sounds nice, but there's still this huge, insecure monolith below. Genode, Harmony or Fuchsia sound much better. And now with a secure language for the surface and drivers it would be even better.
But even better no OS, and no attack surface. Only what you need, and properly isolated.
The problem with any secure system is that they're not usable systems. Real applications and users expect to access anything from anywhere. That's the opposite of security.
One of my friends had his credentials stolen from a trojan infostealer masquerading as a video game, sent from a rando who he mistakenly trusted. If only it had to request user permission to access files outside of its folder. There's a spectrum between full access and full lockdown.
4 replies →
PSOS's capability-based architecture was way ahead of its time. The core idea, tag memory with unforgeable access tokens at the hardware level instead of leaning on software-defined access control lists, is finally getting real implementation, forty-plus years later. seL4 is the obvious modern inheritor. It’s a formally verified microkernel where capabilities are the basic access primitive. The seL4 team proved, in Isabelle/HOL, that the kernel's C implementation matches its formal specification exactly, no buffer overflows, no null pointer derefs, no privilege escalation. That’s the PSOS vision, actually built. CHERI, out of Cambridge and SRI, and a bit ironically building on the same institution's heritage, pushes the idea into hardware: 128-bit fat pointers with encoded bounds and permissions, enforced at the CPU level. ARM's Morello prototype showed this in silicon. A CHERI-extended CPU literally can’t forge a pointer outside its authorized memory region, the hardware traps it. The frustrating part is Miagg's point, we had the blueprint in 1979. What killed capability systems wasn’t technical, it was the Unix monoculture and the network effect of "good enough" security. Now we’re slowly rediscovering capabilities under names like "object capabilities" and "hardware enclaves." Better late than never, tbh, but it’s hard not to wonder what the internet would look like if PSOS's architecture had won.
> The core idea, tag memory with unforgeable access tokens at the hardware level instead of leaning on software-defined access control lists, is finally getting real implementation, forty-plus years later.
The IBM System/38 did this around the same time, along with its successor - the AS/400. When the AS/400 switched to POWER (or PowerPC AS), they started using standard RAM, but are still able to have a tag bit for each 16byte(?) pointer using ECC, but the instructions to do that aren't privileged. The AS/400 or "i" as it's now called is still around.
This book has many of them:
https://homes.cs.washington.edu/~levy/capabook/
The difference between ambient authority systems, like Windows and Linux, and capability systems is the difference between a program that only uses global variables and a program that uses local variables and function parameters.
In a capability system, you pass resource capabilitys to subsystems. You can not use resource handles that were not passed to you just like a function can not access variables that were not passed to it (except for explicit global variables.
In ambient authority systems, as a common example, you can just blindly convert what are effectively strings into resource handles (the metaphorical equivalent of casting integers to raw pointers). Your access is mediated by a orthogonal system that tells you which resource handles/pointers you are allowed to use. That is like having a program that runtime checks every pointer access is allowed instead of just preventing you from manufacturing pointers.
You coordinate across subsystems by naming certain resources in the global ambient space in a coordinated fashion (effectively a global variable which is basically just a named memory location in the common memory space). That way the subsystem knows the global you put their parameters/resources in.
While you can still program like that, everybody now knows it is a terrible way to live. Parameter passing and local variables with explicit global variables is almost always the way to go. That same lesson should be learned for operating systems.
I too would like an OS where called programs don't need to call open() on strings. The shell already has <input >output redirection, but hamstrung so few ever use them. So many programs recreate the functionality with -i -o in some manner to make up for the flaws (read multiple inputs, avoid creating a file on error). Graphical programs could request a fd from a trusted file picker instead of requesting a string to call open() immediately after. That just scratches the surface, so much security and convenience to gain.
If you are interested in this I highly recommend studying SeL4. A practical industrial proven correct micro kernel used by billions of devices worldwide.
I would honestly like to understand why Miagg's comment has been flagged.
Might be people just flagging so mods can make an "Is this an LLM not?" determination. I see a lot of new accounts get flagged like this (and scanning the previous comments, ehhhhh yea maybe?).
Idk, just guessing
At a guess, looking at his history, it's AI slop. Basic facts appear correct though.
Which history? it's their only comment.
It's probably a bot nonetheless, which poses the question: why do people do that? What do they gain by posting resume comments on HN with LLM bots?
2 replies →
[flagged]
My modern take on (un)secure operating system for the future : https://news.ycombinator.com/item?id=48167846
Rebuild everything from scratch, with AI agents. Then make them prove what they wrote.