(Nearly) All Your Computers Run MINIX

Are you reading this on a machine running a GNU/Linux distribution? A Windows machine? Or perhaps an Apple OS? It doesn’t really matter, because your computer is probably running MINIX anyway.

There once was a time when microprocessors were relatively straightforward devices, capable of being understood more or less in their entirety by a single engineer without especially God-like skills. They had buses upon which hung peripherals, and for code to run on them, one of those peripherals had better supply it.

A modern high-end processor is a complex multicore marvel of technological achievement, so labyrinthine in fact that unlike those simple devices of old it may need to contain a dedicated extra core whose only job is to manage the rest of the onboard functions. Intel processors have had one for years, it’s called the Management Engine, or ME, and it has its own firmware baked into the chip. It is this firmware, that according to a discovery by [Ronald Minnich], contains a copy of the MINIX operating system.

If you are not the oldest of readers, it’s possible that you may not have heard of MINIX. Or if you have, it might be in connection with the gestation of [Linus Torvalds]’ first Linux kernel. It’s a UNIX-like operating system created in the 1980s as a teaching aid, and for a time it held a significant attraction as the closest you could get to real UNIX on some of the affordable 16-bit desktop and home computers. Amiga owners paid for copies of it on floppy disks, it was even something of an object of desire. It’s still in active development, but it’s fair to say its attraction lies in its simplicity rather than its sophistication.

It’s thus a worry to find it on the Intel ME, because in that position it lies at the most privileged level of access to your computer’s hardware. Your desktop operating system, by contrast, sees the hardware through several layers of abstraction in the name of security, so a simple OS with full networking and full hardware access represents a significant opportunity to anyone with an eye to compromising it. Placing tinfoil hats firmly on your heads as the unmistakable thwop of black helicopters eases into the soundscape you might claim that this is exactly what they want anyway. We would hope that if they wanted to compromise our PCs with a backdoor they’d do it in such a way as to make it a little less easy for The Other Lot. We suspect it’s far more likely that this is a case of the firmware being considered to be an out-of-sight piece of the hardware that nobody would concern themselves with, rather than a potential attack vector that everyone should. It would be nice to think that we’ll see some abrupt updates, but we suspect that won’t happen.

Intel I7 processor underside: smial [FAL].

68 thoughts on “(Nearly) All Your Computers Run MINIX

  1. Before reading… I’m guessing it has something to do with the embedded microcontrollers responsible for?: (Platform/generation dependent) intel ME, the bring-up processor(s), Intel Bootguard (Secureboot before secureboot), some others I forgot.

    I’ll now read the article…

    1. Read the article,
      nice write-up as usual, with good references.

      Oh, it lead me dow the rabbit hole to A writeup on bypassing BootGuard[link] and now I’d wished I hadn’t stripped that Hudl2 tablet for parts/recycling: the one that failed to power after a halt-n-go-hot mod to the 16-bit area.

      .
      .

      Just chucking some ideas out there, maybe Intel can implement this as a one-up against AMD:
      .
      Intel’s fun and games… Why not they allow us to use these processors/embedded-controllers as a powerful “connected-standby” extension for linux: Think, downloading your (Legal copy of) music and the only time the machine turns on is to write to system RAM or HDD. Massive power savings for on the go… or a CPU-less mode that allows OEMs to turn off the main CPU cores and the power hungry stuff by allowing a minimal GPU setup for some mini-apps to run…

      Office applications(executes on the embedded processor):
      48-hour battery (display backlight may reduce this)

      Youtube videos (Main CPU enabled):
      5h-battery (the cores are on and full GPU implementation mode enabled)

    2. The great irony of course lies in that the “bodyguard” is having a weaker security than the system it is supposed to “protect” (it was “protected” by obscurity, buyt no longer).

  2. Efficient, secure, flexible – pick two. A simple solution doesn’t have to be insecure – each level of abstraction introduces it’s own attack surface. A micro controller doesn’t need to support arbitrary data, packets, device drivers, hardware, or even protocols.

    For example, if their ethernet MAC was one time configured to DMA packets matching a certain specification into a fixed size buffer, kept well away from other data, then it’s easily conceivable that many buffer related exploits would simply be impossible. Similarly, using constrained parameters and data layouts within packets would seriously limit opportunities for attack, especially if the interpreting code eschewed the stack and heap and used entirely static memory allocation.

    1. Well, that gap between packets and data…
      well packets are data and will be processed by code at some point.
      Explicitly creating a packet that tricks the code into another branch of execution can also be turned into an ROP exploit by allowing the code execution to read the buffer overflow…
      essentially a ROP virtual-execution-machine layer atop of the packet management system.
      See the old stuff from Fail0verflow on the PS4 hacking scene for a better description (Explicitly highlighted the word OLD as that is how not so fresh in my mind it is).

      As for stopping overflows between data and code: well why not segment the two completely away from each other as such so the code is in a near-side section (beginning of RAM) and the data is in the far side of ram (but above the reset vector of x86), segment the critical data with boundaries of a few meg between them (the only time bloat is good for anything!).

      Better still:
      Heard of ring buffers?
      Well why not serial-ringbuffers?
      That is a network of controllers that only communicate via the UART buses independently of each other and only data passing gets done by the dedicated controllers (that can be switched dead off at command via software/kernel of the main OS). That way, nefarious hackers would have to wrap their heads around all the segmented controllers, even then, due to the handling of the data and the restrictions at each layer… may be impossible to exploit the “god-mode” parts of this modular design.
      .
      .
      .
      .
      .
      .
      Tl;DR:

      Your idea is OK but see the OLD Fail0verflow (CTurt) PS4 scene for why it’s somewhat flawed.

      Segregation/isolation is an improvement, but see above statement… still similar flaws.

      Complete modular approach with hardware isolation of the software stacks… major improvement… but badly implemented can be a gaping shotgun wound!

      1. What buffer overflow? Design it right, and the DMA controller will simply abort the transfer and the packet will be discarded before it even gets close to the end of the buffer. Don’t scatter/gather – KISS, work on one packet at a time, only one buffer in the whole system. Remove the option of flexibility, and there’ll be no packet management to trick. These are low level embedded systems, and should be designed as such. Run the code out of ROM, operate as a state machine and never load a branch address. Don’t flexibly parse the packet, just checksum the predefined slice and pull data from fixed offsets. If the protocols make that too hard, then they’re not protocols that should be used by low level ultra secure systems.

        The problem with all these techniques is they’d require decent bare metal hackers to implement correctly, not some subcontractor who’s diploma came free in a packet of cereal, and that’s why you see vulnerable weak code in most production systems.

  3. Does this include Arm devices??? If not then your opening statement may not be as probable as you think. I’m using a chrome book, arm based version. Then there are all the iOS and android devices where only a very, VERY small number have an Intel chip. I would say it’s just as probable that a reader is using an Arm based device.

    Question is, is there an Arm alternative to Intel ME???

    1. P.s I have one Intel system and more than 10 Arm based ones. Chromebook, phone, tablet and many raspberry pi’s.

      “(NEARLY) ALL YOUR COMPUTERS RUN MINIX” No they don’t

        1. Actually I don’t think they are in a minority. Many people don’t even have an intel laptop or desktop as they are happy with an ARM based Tablet. Most people have a smart phone, many have a smart TV or some sort of set-top-box/DVR. Intel based computers are getting less common.

          1. Nitpicking aside, it doesn’t have to be called “management engine” to be dangerous; all it needs is a binary only firmware blob running at higher privilege than any system or user software. Intel has it, AMD has it and ARM has it even if it may appear in the form of a binary GPU driver blob. It’s just firmware which runs at top priority, no matter how it’s called, and it can access everything.

          2. And let’s not forget game consoles. Nintendo uses ARM this generation, but Sony’s as well as MS’ offerings are basically locked down PC-ish platforms. I’d guess they do not contain the ME due to cost cutting, but I’m not sure. Anyone happen to know?

        2. “You’re a vast, vast minority trying to look smug but just ending up acting like a idiot.

          Discuss the article instead of projecting your superiority complex.”

          I was pointing out that the title was making a big and inaccurate assumption.

          That has to be the biggest over reaction I have ever read to a comment. Your insults invalidates any point you may have had.

          Smart phones, which are computers, out number Intel based PC’s by a vast, vast, vast number. Not the minority as you seem to think.

          1. … and the number of ARM processors shipped to date, outnumber people on this planet. It is estimated that around 10 billion ARM processors have been manufactured. Some no doubt will have been scrapped, and not all are used in personal devices, but Richard’s point is valid, as the vast, vast majority of us smug idiots agree.
            Intel is not the only option, despite what they might like us all to believe. (Nearly) all your intel boxes run minux, sure, but by the same token (nearly) all your mobile devices.. don’t.
            Refrain from trolling and personal insults, and stick to the topic.

    2. I might be wrong but I guess ARM TrustZone virtual cores are somewhat like an ME. They are protected cores running unknown code. Also manufacturer can customize ARM architecture/processors and so add as much backdoors they want too. (China (and surely the US) I’m looking at you…)

      This aside, it’s sad we live in a world where you don’t own your computer. At least my laptop and server are running libreboot.

      1. Security and convenience are kind of opposites. MEs are for avoiding the inconvenience of having to sit at the computer to do one’s work. MEs are also geared towards those who’s knowledge of computers is a pay grade above finding the power switch.

    3. There is only a handful of tablet/phones that I’d call somewhat a “Computer”… as much as an ATMEGA is a computer, or a PIC32 is!
      Heck, it needs to support other operating systems natively (Not just a hacked together android on android booting an android android type implementation, nor just a burnt-in unsupported kernel).

      A phone is a phone, but with some gimmicks added on these days. Tablet PC, well still the stock firmware is just that: firmware that disguises itself as an “OS”… yes firmware is a form of OS, but not an OS in a choice-friendly manner.
      Think of those windows tablet PCs without UEFI-setup access and permanent secure-boot, It may be windows 10 Pro on an x86 compatible, but it is not a “tablet PC” in my books… heck it isn’t a PC as where is the P for personal when there isn’t any personalization? Instead the “OS” called Windows 10 Pro… is firmware (i.e. stuck there… cannot be changed) and may as well be sold as “windows embedded 10 pro” or just labeled as a glorified PDA!

      On the other hand, I have a washing machine that contains a computer (probably a STM32), but guessing it won’t be running Minix? Though I’d probably won’t be browsing the internet or installing Linux on it anytime soon (I’d rather leave it with WashingMachineOS, as that is the most useful OS/firmware for it)

      Sorry about the rant, but I’m extremely pro-choice/freedom: A locked down machine is just a mere tool for one job: like a hammer (Though I’m sure I’ve seen people use one as a screwdriver before!)

    1. His take on the efficacy of the BSD license (as opposed to GPL) is interesting. Back when TiVo found a workaround for GPLv2, the FSF people went up in arms and made another revision just to stop loopholes. It was an insane bloodbath.

      Meanwhile Andrew obviously dislikes the application, but is flatly pleased with the success of the license : )

  4. I don’t agree with the (implied) statement that simplicity means insecurity. And the article does not even mention that MINIX is a micro-kernel where userland AND drivers are isolated. Thus it is fair to say that MINIX was built with security in mind. That being said, I still consider this whole setup to be insecure for the same reason it was before: a lot of code that has access to the whole hardware and is unlikely to be upgraded in the future, someone will eventually find a nasty exploit.

      1. It is Minix 3.
        I find the write up to be really annoying.
        1. Minix 3 is open source. it uses the BSD license.
        2. It is not known to be insecure.
        The annoying thing is that Intel has not dumped a lot of cash into Minix 3 and or development. Minix 3 is a really interesting project and I would like to see it move forward.

    1. Simplicity doesn’t have to mean insecure, but the kind of simplicity that _is_ secure requires a ton of work to ensure that it is. And since it has never been the intention of this kernel to be particularily secure it has never has even been in focus. So it is higly likely that it isn’t very secure, security has ben thorougly demonstreated to not happen by chance..

      1. I generally agree with the fact that it has received less attention, thus is more likely to have bugs. However Minix3 was designed with intention of being very secure and reliable. The kernel only has a few thousand lines of code, the drivers run in isolated processes and cannot access arbitrary i/o ports or memory or run privileged instructions or crash the kernel. Though to be honest, I don’t understand why Intel does not use something like seL4.

    1. Unfortunately it’s *NOT* that simple.

      A modern PC operating system has an absolutely massive attack surface even when designed with security in mind rather than just ‘painted’ on top as an after thought.

      Not being connected to the internet or filtering network traffic isn’t going to help if some idiot plugs a usb flash drive (s)he found in the car park into a machine.

        1. Quite true. In secure computing environments access to USB ports and even FDD is forbidden except by IT peeps. If you try and get around it by trying to use a USB port, it sets off a alarm and you get a visit from IT and security people real fast.

          And probably lose your job over it.

      1. What if the modern system detected the plug, recognized it for whatever it represented itself as and then notified the user that it was ready but not active?

        While the USB design isn’t really designed for security most of the problems with security is on the OS side because users are lazy. They don’t want even basic security.

        But the USB standard is partially to blame – if one could reliably connect to a device knowing that it is indeed a device inserted and acknowledged before things could be better. First time a new keyboard is connected the user have to tell the OS that it is indeed a device that he/she knows about and want installed, later use would be simply plug and play and any rogue devices would be shown as unknown.

  5. All of mine do not. I have here a Dell Dimension running Slackware-12.2, a laptop made by the same company, running Slack-11, it is a P2 device. And a SPARC box. Also this laptop is from the period immediately before that silly idea of Intel. But I recall the discussion on the list Jenny, and it was a disturbing rout. Now there’s an effort to clean up that mess before it compromises the entire coreboot method.

  6. Saying that minix is insecure because it is simple is nonsense. Complexity increase bugs and surface attack not simplicity.
    And by the way micro-kernel OS are designed with security in mind at first and it is what minix 3 is. If Intel ME use minix 3 I would consider it as secure as it can be. That said there is always a possible exploit in any system.

  7. Jenny, I think you should limit yourself to things you know anything about (assuming this isn’t an intentional troll).

    Minix 3 isn’t the old Minix that Linus once used. It is a system designed as a secure and reliable base, not as an educational system the old versions were.

    It is a microkernel system where drivers are separated from the kernel and where most kinds of attacks need to go through several layers of individually protected modules communicating with little exposed surface.

    In a monolithic system drivers, kernel and networking subsystems are all in one common protection module with little hindering an attack on e.g. the networking driver from doing whatever it wants.

    And simplicity combined with (hardware enforced) modularity is the best way to get something that just work. Security 101.

    1. I think what’s bothering people isn’t so much the OS chosen, as the opaque nature of the current implementation. People want to see the source code, and be able to control any keys, otherwise as people say, it’s not their machine.

      1. We were writing drivers for Minix3 in school, and the memory allocation for the system was vulnerable to fuzzing.
        Despite the message passing setup it was still possible to crash the OS hard from user space in a virtual machine.

        I suspect a shell-shock style exploit will be in the wild soon.
        We’ll keep the ancient pre-ME dual CPU server racks for now, as having a backup not vulnerable to nerd-plague is wise.

    1. Intel ME is not only guarded for ‘pay-wall’ purposes, but it’s also a big security vulnerability, and a backdoor for the spooks many believe. So they don’t want you to know more than they think you need to know.

      to quote wikipedia:
      “critics like the Electronic Freedom Foundation (EFF) and security expert Damien Zammit accuse the ME as being a backdoor and a privacy concern”

    2. Part of the function of ME is to sell the same product many ways, and to sell partially functioning, or partially broken depending on your point of view, chips, that would be binned otherwise (and that higher failure rate would otherwise raise the cost of all CPU’s). Instead of making Intel X, Intel Y and Intel Z processors they make a generic Intel XYZ processor, then based upon testing allocate them to different product lines. Say every CPU is made with 16 cores, but there is a 50% failure rate in cores, so they sell the partially failed chips as 2 cores, 4 cores, 6 cores, 8 cores, 10 cores, 12 cores, 14 cores and then have the ME “lie” about what is actually inside the silicon package.

  8. IME is not about a necessity to control a CPU, nor about protecting it, it’s all about remote management – and of course shenanigans for the spooks and other such unsavory entities.

Leave a Reply to DarrenCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.