It was a great little device.

It truly was. It just felt good. The UI brings me such positive nostalgia. I was obsessed playing solitaire on that thing.

"There is only a single reference5 dated to 2010 indicating that Microsoft might use a similar approach for its NT kernel."

Googling for it brings up a ton of results.

Not instructions per se. Rosetta is a software based binary translator, and one of the most intensive parts about translating x86 to ARM is having to make sure all load/store instructions are strictly well ordered. To alleviate this pressure, Apple implemented the Total Store Ordering (TSO) feature in hardware, which makes sure that all ARM load and store instructions (transparently) follow the same memory ordering rules as x86.

It is funny to hear sometimes though:

"Apple created a chip which is not an X86! Its awesome! And the best thing about it is ... it does TSO does like an X86! Isn't that great?"

Only some of the time.

I think the last time I ran amd64 on my mac was months ago, a game.

You can self host with Headscale.

If the application in the container wants to add more restrictive rules then it should be allowed to. But it should not be able to mess with the existing rules imposed by the container manager. This would be the ideal outcome.

There is nothing to do here. Landlock already a guarantees that you can't undo rules that were already applied. Your application can further restrict itself but it can't unrestrict itself.

Just need the container manager to not block the landlock system call

I use them on Teams on macOS (and Windows) every day and is the main reason I have them. What you say is simply not true.

It's not open. It's not really about devices. And it's certainly not a partnership.

Open as in "open for business".

So they are using RISC-V already for some embedded cores. For application cores, they are participating in the RISC-V consortium to keep the pressure on ARM and also to be ready for the long game.

I do not expect to see Qualcomm made RISC-V application cores until Android or Windows is completely ported to it, which I think rules out the next several years.

Second bus?

CHERI fundamentally relies on capabilities living in memory that is architecturally separate from program memory. You could do so using a bus firewall, but then you're at the same place as MIE with the SPTM.

That's not true. Capabilities are in main memory as much as any other data. The tags are in separate memory (whether a wider SRAM, DRAM ECC bits, or a separate table off on the side in a fraction of memory that's managed by the memory controller; all three schemes have been implemented and have trade-offs). But this is also true of MTE; you do not want those tags in normal software-visible main memory either, they need to be protected.

A CHERI capability is stored in main memory but with the tag bit for that location set. The tags are stored in separate memory pages, also in main memory in current designs.

Maybe you've been confused by a description of how it works inside a processor. In early CHERI designs, capabilities were in different architectural processor registers from integers.

In recent CHERI designs, the same register numbers are used for capabilities and other registers. A micro-architecture could be designed to have either all registers be capability registers with the tag bit, or use register renaming to separate integer and capability registers.

I suppose a CHERI MCU for embedded systems with small memory could theoretically have tag pages in separate SRAM instead of caching main memory, but I have not seen that.

So something like having built in RAM for the pagetables that aren’t part of the normal pool? That way no matter what kind of attack you come up with user space cannot pass a pointer to it?

10 years late is better than never.