Doubtless Computing is apparently the blogger's new startup.
He had previously co-founded the CPU startup VyperCore, which had been based around technology in his PhD thesis at the University of Bristol. The startup folded earlier this year.[1]
VyperCore's main selling point was that having garbage collection in hardware could run managed languages faster, and with less energy.
Apparently they came as far as running code in FPGA. Except for the object-addressing hardware, it was based on a RISC-V core.
I wonder which assets (patents and other) that the new company has been able to get from the old.
Both companies were/are apparently targeting the data centre... which I think is a bit bold.
I follow RISC-V, and have seen maybe a dozen announcements of designs for wide-issue cores that on paper could have been competitive with AMD and Intel ... if only they would have got to be manufactured in a competitive process. But that is something that would require significant investment.
BTW. I would love to read one of the articles or the PhD thesis from the University of Bristol, but have yet not been able to find a free copy.
I haven't come across this specific feature before. From reading about it, it seems closely related to Arm (E)MTE ISA extensions - Memory Tagging Extension?
What's interesting is that approach (software-defined 'random' numbers to associate memory regions and valid pointers) provides only probabilistic memory safety. A malicious actor may find a way to spoof/guess the tag needed to access a particular piece of memory. Given Arm MTE has been breached in the last year, it's hard to argue that it's a good enough security guarantee. EMTE may fix issues (e.g. side-channels) but leaves open the probabilistic pathway (i.e. "guess the tag") which is a hole MTE isn't designed to try to close (so, a software breach on top of a chip with EMTE can't necessarily be argued to be a violation of the hardware's security properties, though it may exploit the architectural security hole).
In contrast, CHERI and OMA (Object Memory Architecture) are both providing hardware-enforced guarantees of memory safety properties - unbreakable even if the attacker has perfect knowledge - backed up by formal proofs of these claims.
CHERI offers referential and spatial safety as hardware guarantees, with temporal being achievable in software. OMA offers referential, spatial and temporal safety as hardware guarantees.
Yeah the current closed nature of OMA means there's limited information at present. I am working on publishing more over the next year. It is essential the wider community starts to get access to at least the modified RISC-V ISA, to independently validate the security claims.
Kind of, with the difference that it has been in production since 2015 on Solaris SPARC systems, granted they aren't as widespread as they once were.
Sometimes the perfect is enemy from good, none of the memory tagging solutions has achieved mainstream widespread adoption outside iDevices.
Google apparently doesn't want to anger Android OEMs demanding it to be required by Android, thus it remains a Pixel only feature.
CHERI and OMA are going to still take years for mainstream adoption if ever comes to it.
I had hopes for whatever Microsoft was doing in CHERIoT to eventually come to Windows in some fashion, but best it has happened seems to be the adoption of Pluton in CoPilot+ PC, which anyway serves a different purpose.
Fil-C running on any x86 box is faster than any CHERI implementation that has ever existed.
That's likely to be true in embedded also, just because of the relationship between volume and performance in silicon. Fil-C runs on the high volume stuff, so it'll get better perf.
CHERI doubles the size of pointers, so it's not like it has a decisive advantage over Fil-C.
But seemingly on track to move from "large" to "significant" speed and memory overhead. It is already really useful especially for running tests in pipelines.
Could we also consider just not connecting critical systems to the internet at large? No reason, for example, for the Jaguar assembly line to depend on an internet connection.
Yep air-gapped security is a thing. But servicing, patching and communicating with air-gapped devices still needs to happen, which involves connecting to them somehow. Likely a manufacturing plant has started to connect everything together to streamline the process and created an attack surface that way.
You can see the appeal for not needing to go through all the issues, complexity and costs that entails.
He had previously co-founded the CPU startup VyperCore, which had been based around technology in his PhD thesis at the University of Bristol. The startup folded earlier this year.[1]
VyperCore's main selling point was that having garbage collection in hardware could run managed languages faster, and with less energy. Apparently they came as far as running code in FPGA. Except for the object-addressing hardware, it was based on a RISC-V core.
I wonder which assets (patents and other) that the new company has been able to get from the old.
Both companies were/are apparently targeting the data centre... which I think is a bit bold. I follow RISC-V, and have seen maybe a dozen announcements of designs for wide-issue cores that on paper could have been competitive with AMD and Intel ... if only they would have got to be manufactured in a competitive process. But that is something that would require significant investment.
BTW. I would love to read one of the articles or the PhD thesis from the University of Bristol, but have yet not been able to find a free copy.
1. https://ednutting.substack.com/p/vypercore-failed
https://docs.oracle.com/en/operating-systems/solaris/oracle-...
Although I do conceed, most folks aren't keen into picking up anything related to Oracle or Solaris nowadays.
What's interesting is that approach (software-defined 'random' numbers to associate memory regions and valid pointers) provides only probabilistic memory safety. A malicious actor may find a way to spoof/guess the tag needed to access a particular piece of memory. Given Arm MTE has been breached in the last year, it's hard to argue that it's a good enough security guarantee. EMTE may fix issues (e.g. side-channels) but leaves open the probabilistic pathway (i.e. "guess the tag") which is a hole MTE isn't designed to try to close (so, a software breach on top of a chip with EMTE can't necessarily be argued to be a violation of the hardware's security properties, though it may exploit the architectural security hole).
In contrast, CHERI and OMA (Object Memory Architecture) are both providing hardware-enforced guarantees of memory safety properties - unbreakable even if the attacker has perfect knowledge - backed up by formal proofs of these claims.
CHERI offers referential and spatial safety as hardware guarantees, with temporal being achievable in software. OMA offers referential, spatial and temporal safety as hardware guarantees.
Yeah the current closed nature of OMA means there's limited information at present. I am working on publishing more over the next year. It is essential the wider community starts to get access to at least the modified RISC-V ISA, to independently validate the security claims.
Sometimes the perfect is enemy from good, none of the memory tagging solutions has achieved mainstream widespread adoption outside iDevices.
Google apparently doesn't want to anger Android OEMs demanding it to be required by Android, thus it remains a Pixel only feature.
CHERI and OMA are going to still take years for mainstream adoption if ever comes to it.
I had hopes for whatever Microsoft was doing in CHERIoT to eventually come to Windows in some fashion, but best it has happened seems to be the adoption of Pluton in CoPilot+ PC, which anyway serves a different purpose.
You can have a memory safe Linux userland today in stock hardware. https://fil-c.org/pizlix
That's likely to be true in embedded also, just because of the relationship between volume and performance in silicon. Fil-C runs on the high volume stuff, so it'll get better perf.
CHERI doubles the size of pointers, so it's not like it has a decisive advantage over Fil-C.
- CHERI with a Linux on Top https://news.ycombinator.com/item?id=45487629
- Why not object capability languages? https://news.ycombinator.com/item?id=43956095
- Ask HN: Why isn't capability-based security more common? https://news.ycombinator.com/item?id=45261574
You can see the appeal for not needing to go through all the issues, complexity and costs that entails.