Intel CPUs run MINIX on them, in the Management Engine (2017) | Hacker News Reader

Intel CPUs run MINIX on them, in the Management Engine (2017)

web.archive.org

18 pointstanelpoder8 comments

MINIX 3 specifically, a microkernel research OS with a NetBSD userland that was focused more on research and less on teaching.

If Intel had any sense or were to revisit this area in the future, they probably should've selected a RTOS in the L4-family OS like seL4 that was formally-verified or went with negotiating a special deal on INTEGRITY-178B because this OS would be widely deployed on both billions of individual devices and on critical infrastructure.

MINIX 2 was a completely different OS. It was extremely simple and modeled after UNIX similar to Linux, but much more minimal. It was so minimal that the fundamental parts of the i386 protected mode kernel code were printed in their entirety in Andrew S. Tanenbaum's & Albert S. Woodhull's book.[0] In an operating systems course, I recall patching a university cluster machine running MINIX 2 to adjust the keyboard controller's repeat rate to the maximum. If you wanted more granular control over keyboard input, you could write an (real or protected mode, depending) interrupt handler to only look for make and break codes of individual keys and then report them at whatever rate you wanted to however your operating system accepted input events. Breakdowns in how this and how real hardware works is typically an explanation for duplicate or missing keypresses occur under virtualization, such as when a user task switches to and from a VM console on another machine during a virtualized key down state.

0. Operating Systems: Design and Implementation Second Edition, 1997, Tanenbaum & Woodhull, ISBN-10: 0136386776

https://minix1.woodhull.com/osdi2/

This is the part that people complain about, in that it can access RAM and other devices and communicate with the network, without the user's OS being able to be aware of it, I think.

From the article: "Now ME firmware includes a full-fledged operating system with processes, threads, memory manager, hardware bus driver, file system, and many other components."

This seems like the kind of thing that would benefit a great deal from rust usage.

Rust could be helpful, but it's just one leg of a table. Design, architecture, security concerns, hardware support, vendor support, cost, and compatibility are also important requirements.

If not already extant, a FOSS, capabilities-secure, formally-verified RTOS somewhere in the space of seL4 and MINIX 3 microkernel would be useful. Rust might help, but the problem is a lack of attention paid to formal verification all the way downstream, perhaps including symbolic execution and thorough verification of the resulting binaries.

In general, the biggest microkernel design challenges are efficient IPC and handling complex transactions across multiple tasks/processes.

seL4 and such solved IPC performance bottlenecks by proving their moves of message structures were sound under invariants. This is something Rust might be able to solve through moves and lifetimes, but it might not have enough power directly and some edge-cases of unsafe code might be needed for performance reasons.

When it comes to handling privileged events, transactions touching multiple each tasks components must be carefully locked or some privileged helper must step in that violates ordinary constraints. In largely-monolithic Linux, this is relatively easy because when lock-free patterns are unavailable, some or all of the world can be stopped and essentially anything can happen almost anywhere. This simplicity comes at a cost of low/no amounts of isolation that weakens the design goals of a "pure" microkernel architecture which leads to real, hybrid microkernels.

The entire premise that you need an MMU is about invalid memory accesses. Safe rust does much the same job with much finer grain and at compile time not runtime where dealing with page faults can lead to some strange loops.

No need for IPC or syscall marshalling when you can simply do function calls without the hassles of MMU permissioning.

Like why is a microkernel needed today for this sort of thing, if its purely for security of memory then... well there's other ways of solving that problem completely outside of hardware memory protection schemes at this point in my mind.

We're so steadfastly stuck in this mindset of needing memory protection and pointer protection (CHERI) because of the insanity that C and its like bring to the table. Restricting the software to safe rust does much the same job. Memory is protected, lifetimes are protected, and better still data races are protected.

E.g. see rtic-rs and how tasks are written. Without unsafe, no memory is accessible outside what is given explicitly to the task. And checking for unsafe rust can be done in an automated fashion at compile time.

Or maybe I'm totally wrong which is quite possible!

At Oxide, we have embedded projects with 100% Rust. We still have the kernel use an MPU (not even an MMU!) to protect each task's memory.

Defense in depth is good.

No doubt defense in depth is good, but frankly there's a cost to mpu/mmu (mpu does much the same in terms of memory protection but without the benefit of a dynamic page table...).

There's a cost to jump from memory protected context (user mode in effect) to supervisor mode, usually an interrupt at minimum. In reality there's typically some syscall mechanism which requires argument marshalling, verification, unmarshalling. Lest you catch a TOCTOU issue.

There's a cost to managing the memory regions... both in wasted memory (page aligned/mpu region aligned) and cpu requirements (reprogramming page tables/mpu regions).

None of that is free of charge and those costs add up quickly.

Reply on news.ycombinator.com