CHERI-based computer runs KDE for the first time Wayland and the KDE Plasma desktop now run on CheriBSD, the special version of FreeBSD for Arm's experimental Morello hardware. The University of Cambridge's Capability Hardware Enhanced RISC Instructions project, or CHERI for short, has been underway for some years, and usable results are starting to emerge. It aims to bake …
> I agree with Tony Hoare.
"Many years later we asked our customers whether they wished us to provide an option to switch off [bounds] checks in the interest of efficiency on production runs. Unanimously, they urged us not to—they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
The bottom line is that by ignoring most of the available hardware protection capabilities in an attempt to make software appear to run slightly faster, Microsoft et al. have left their systems vulnerable to any amount of bugs and malware. Even ignoring the cost of theft and extortion, the time wasted scanning for potential problems and fixing any that get through is vastly greater than the time they were able to save.
Even though capability-based security is almost as old as computer science itself, it has become increasingly in vogue with the almost endless patching of software, hacking, spying and ransomware.
I long for a world where computers are essentially unhackable. I hereby predict that when that day comes intelligence agencies will once again clamor for backdoored operating systems and CPU's.
I ported a few C & C++ OpenGL games to CheriBSD as part of my PhD thesis (I wrote a distributed implementation of OpenGL and wanted to test on novel platforms).
It is a fun platform albeit I only used the qemu-cheri emulator from the FreeBSD ports collection rather than actual hardware. Though to be fair, since I didn't go too low level or close to the hardware (I.e kept to C and C++), I didn't really even notice I was on such an experimental platform most of the time.
CHERI's biggest drawback is that it merely protects a system from abuse and hacking, but doesn't reduce the chances of programming errors or increase a program's stability.
In that respect I believe Rust is much more of a paradigm-shift than CHERI will merely enable companies like Microsoft to secure their sloppy programmed operating systems from takeover.
> You mean like the Manchester MU5 of the late sixties?
...which shipped in '74, some fifteen years after Burroughs started working on their descriptor-based architecture which was released commercially in I think '63.
I admit to being slightly dubious about the ultimate provenance of that architecture. The tag that indicated whether a word in memory was data or a descriptor might have been a side-effect of designing hardware to run ALGOL, which later turned out to have broader applicability.
I've used both ICL 2966 mainframes running VME/B and IBM AS/400 running OS/400. Both were very reliable and showed a refreshing unwillingness to crash.
IOW, both implemented first-class memory protection that did exactly what it said on the tin.
They had other nice similarities too, in that both had compilable job control languages and carefully thought-out command names (IOW once you know how command names are constructed you can guess seldom-used command names with good accuracy), decent source editors and well-designed program fault analysis tools that made program development easy. And both used excellent full-screen command prompting combined with an online command lookup capability.
However, both had what seemed, even then, like a major fault: neither had a hierarchic filing system, though at least VME/B used nice long names for commands and files.
I thought OS/400 blotted its copybook by restricting all names to nine characters, which made command names difficult to remember despite enforcing a consistent naming system - the PL/I compiler was called CRTPLIPGM - line noise for sure at 1st or even 2nd reading.
True.
I'm not sure how widespread such things were outside of Multics at the time. Also there is the "These are business machines, they don't need anything below a single level filing system"
That said i-series nams were not quite that restrictive. Files normally had "members" so "COBOL" is the COBOL source file for all programs in the system
The systematic naming of system commands was also another sign of a highly controlled system (I suspect similar in the HP 3000 series, which were also hardware+OS+database systems) but that's quite attractive as well, once you get used to the conventions, like everything happening by "readers" and "writers" accessing queues (using just Q in the name) and systems commands and roles starting with a Q(supposedly the least common letter used in the english language, so unlikely to clash with something in some customers system already Eg QSECOFR for ). If in doubt, throw the vowles out.
I'd been using hierarchic filing systems from 1971: ICL 1900s running George 3, so not particularly rare systems.
Thw 190 series also used an secure solution for memory guarding - in a 1902/3/4 there were just two hardware registers: DATUM and LIMIT, which which pointed to the base and highest address in the running program and provided a hard limit to the addresses the program could access. The 8 registers, PC,CC etc were the first few words in the running program. This also made moving a program in memory or swapping a quiescent program to or from disk very simple - its complete state was automatically transferred because it was recorded in the first 32 words of the image being moved.
I'm certain the 1905-6,9 models did something similar despite having faster discrete accumulators, but I never used nor was admin for them.
OS/400 did get an additional hierarchical file system (HFS, the ... Hierarchical File System) after a few years. IIRC, this was even before the move to POWER-AS CPUs and the introduction of PASC, which was basically AIX-under-OS/400.
Of course HFS was basically useful for POSIXy just-a-stream-of-bytes data files. You still had to use IFS (Integrated File System) for normal OS/400 objects, like Program Files (executables), Commands (things you could actually invoke directly from the command line with prompting and such), Source Files (those collections of source code "members"), Database Files, and so forth.
The agglutinative command-and-menu naming in OS/400 was largely a relic of IBM's failed Future Systems project, according to some old IBMers I used to work with.
From the article: The S/38 evolved into the AS/400, today known as IBM i, but the designers of those later systems dropped the security mechanism. That's not precisely right. While the '400 didn't have a true capability architecture, it did use tagged, secured pointers in userspace. Pointers (in EPM, and I think this was true of OPM and ILE) were 80 bits, and (if memory serves) were essentially a "memory space", offset, limit tuple. Attempting to alter a pointer's value directly (e.g. by bit-twiddling or accessing its representation using another unsigned char * pointer, in EPM C) would invalidate it, because user-mode code was compiled to a pseudo-assembly language (ML, Machine Language) where various restrictions could be enforced.
So muck up a pointer, or an offset (e.g. with array indexing), and you'd get a Program Check or the like, with a helpful message in your message queue about what went wrong and where it happened. Sure, there's overhead – early AS/400s in particular were ponderous beasts – but it often meant problems were found earlier and were so much easier to debug.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
