MINIX: Intel's hidden in-chip operating system | Hacker News Reader

MINIX: Intel's hidden in-chip operating system

zdnet.com

286 pointsjugalps109 comments

While the backdoor and surveillance arguments are good, and the chips are very likely backdoored (if not deliberately then by undetected bugs) there are other issues with this closed source firmware.

Let's say another bug [1] is found that lets anyone remotely control your computer, but Intel becomes bankrupt, or just doesn't see it as a big enough threat to roll out a firmware update. You then essentially have a computer that you can't use, due to the fact it's not secure and anything done on it could be compromised.

Maybe not a massive deal for the average home user who would just buy another laptop. But let's say a large company buys 10k laptops all with an Intel chip inside it. Then Intel goes bankrupt, becomes incompetent (i.e. can not resolve bugs), refuses to upgrade firmware, or something else. When the next massive security bug is found (which is inevitable with all code, open source or closed) you are left essentially with 10k unusable laptops.

If the code was open sourced, the large company could pay someone else to fix the problem, or what's more likely is someone in the open source community would fix it for us.

The fact you have another processor running beside your main one, that has full access to everything you do without your permission, knowledge or ability to stop it should worry everyone. Even if there are no backdoors or bugs in the code right now, it's a very dangerous precedent to set that we buy hardware we can not control. Maybe one day Intel decides to put an expiry date in their chips, or some DRM to prevent you watching certain content without a license. These restrictions can't be good for society in the long term, can they?

But the biggest problem should be for large companies and corporations. They are putting the faith of their own business into Intel, which like all businesses could one day fail, big time.

1. https://www.intel.co.uk/content/www/uk/en/architecture-and-t...

I find it hard to believe that such a scenario could play out in reality. Surely some government would step forward and compel or even fund a bankrupt Intel to fix such a disaster.

But perhaps I am wet behind the ears, have there been any similar cases on a similar scale in the past?

The government will compel Intel to fix a government backdoor? Sounds unlikely.

Adding insult to injury, Intel has something called "High Assurance Platform" (HAP) which allows to disable the ME. Available only to three-letter agencies, of course; what would the world come to if us plebs were allowed to do anything like that?

Fix this computer or got to prison.

How would that work ?

More like, release your signing keys to us so we can fix the problem (and future similar problems) or go to prison.

The fact that it's closed source is not actually the biggest problem --- it's the fact that the hardware completely refuses to run firmware that's not signed by Intel, and Intel is not giving you the keys or any other way out.

Intel could open-source the firmware, but without any way to use it on the hardware, it'd be useless for anything but finding exploits --- arguably an even worse position. See also https://en.wikipedia.org/wiki/Tivoization

All you need is the ability to run your own code on the hardware, legally or otherwise (regardless of what laws exist, no one can stop you from flipping the bits on storage media you possess...), and the community will do the rest. Having the ability to extract the existing code is also immensely helpful, but I'd consider source to be more of a bonus than an absolute requirement. BIOS modding, custom Android ROMs, iOS jailbreaks, console homebrew, whatever else --- you don't need source code, just the ability to run your own.

Crackers, reversers, and security researchers have long been fine operating under the saying: "Source code? We don't need no stinkin' source code!"

...and IMHO the software community could do well to promote this sort of introspection more, to encourage tinkering and exploration and analysis, in contrast to the "can't do anything without source code", "can't do anything without someone else telling you that you can" attitude prevalent today; but, and this may be a bit of a conspiracy theory, I suspect the establishment generally does not approve of such a "hacker" attitude precisely because it means they can't hide anything by "closing the source".

> it'd be useless for anything but finding exploits

For all unmodified parts of MINIX that ended up in ME 11, this is precisely the case.

Hence why GPLv3 and it's anti-Tivoization clause is so important.

You just described the actual situation with most Android devices, smart TVs, home routers and IoT of shame.

I wonder when people are going to realize RMS was right the whole time.

I'm constantly amazed at the pushback here and other forums against copyleft-foss.

Is there no way to flash the ME without expensive tools (i.e. software-side)? If Intel goes bankrupt they might just release the keys needed to disable/update the ME.

Unfortunately that doesn't seem to be how the computer industry works. Think of all the game, software, hardware companies that don't exist any more. How many of them have released their source code, hardware specifications or given any help for previous customers. Generally the companies got "more important" things to worry about if they're going bankrupt.

Sorry to answer your question, yes it's actually quite easy to flash the firmware. You don't actually need any hardware for it (unless you brick your device somehow). The only issue (as you stated) is it must be signed by Intel to work.

Flashing ME firmware is quite trivial for older laptops -- you just need a flash programmer, a raspberry pi and some patience. It's one of the key parts of how me_cleaner[1] works -- you "clean up" the firmware and flash a new version. However, newer Intel CPUs have BootGuard[2] which makes this impossible.

But I wouldn't hold my breath that they'll release the keys -- why would they? Releasing keys is the last thing you'll think of if a decades-old business is going up in flames.

[1]: https://github.com/corna/me_cleaner [2]: https://github.com/corna/me_cleaner/wiki/Intel-Boot-Guard

Moreover, Intel could selectively release patches for only the newer chips, providing an incentive to upgrade.

Intel deliberately creating such holes and then only fixing them on more expensive models would be possible as well, but the PR from that one might be distasteful enough to hurt Intel.

So like the way apple security updates gimp the performance of your device?

These kind of business practises are Apple's biggest contribution to the computing industry. Didn't invent them but made them absolutely "the norm" and everyone, even hardware manufacturers want to emulate Apple's stunning success. I used to hate Microsoft business practises, Apple are far, far worse the only reason they didn't seem it was because they had such a pathetic market share. Only one thing has changed. Think different. Think critically about what Apple are.

If Intel copy apple here, can you object to intel doing it but not Apple with a straight face?

Why do you think I would ever defend Apple in any way, shape, or form?

I don't. The comment above is much more general but definitely provoked by your observation. "You" is used in the sense of the somewhat archaic "one". Language imprecision is a thing.

"If Intel copy apple here, can one object to intel doing it but not Apple with a straight face?"

> When the next massive security bug is found (which is inevitable with all code, open source or closed) you are left essentially with 10k unusable laptops.

While this is less useful for devices going outside the network (e.g. the laptops you mention), I suspect that the big enterprise response is going to have to be smarter networks. I can easily picture high end fully managed switches becoming more like firewalls, possibly even to the stage of deep packet inspection for recognized patterns.

Not having worked with this, does the ME get its own IP or piggyback looking for particular patterns in packets? And how feasible is it to detect by testing for missing packets (or spurious ones if they're received and passed through?)

That security bug you're talking about can be patched the same way it's exploited. No source code doesn't mean "all is lost". Instead of writing a payload that steals your private keys you just write one that patches out the vulnerability.

"What Minnich would like to see happen is for Intel to dump its MINIX code and use an open-source Linux-based firmware. This would be much more secure. The current software is only secured by "security by obscurity".

Changing to Linux would also enable servers to boot much faster. According to Minnich, booting an Open Compute Project (OCP) Server takes eight minutes thanks to MINIX's primitive drivers. With Linux it would take less than 17 seconds to get to a shell prompt. That's a speedup of 32 times."

Anyone else think this is article is pretty FUD and crap? Not saying Minix has been security audited or is more/less secure than a Linux alternative, but there's something to be said for microkernels at the ME layer.

The OpenCompute annecdote (uncited?) doesn't designate whether Minix in ME is the bottleneck, or whether it's just slow to boot (it probably is when you're booting it with a platform worth of devices).

Good to know my involuntary shudder when opening a ZDNet article isn't entirely unfounded.

I know Ron, he used to work at Sandia National Laboratories in Livermore, running Plan 9 on IBM's Deep Blue among other things.

e.g. running 1 million Linux kernel at once

https://share-ng.sandia.gov/news/resources/news_releases/san...

He's also one of the people behind CoreBoot or whatever its called now

Holy cow, I just realized that I met him at a backyard barbecue... Very sharp guy.

Yes, it's complete FUD. It's also moot, because it really doesn't matter much whats in ME, ME just needs to not exist. The primary reason for choosing MINIX is memory footprint and reliability, additionally GNU is never popular for proprietary blobs like this... it would actually harm users with ME's current strategy if you think about it, GNU forces them to publish their likely buggy striped down version of linux, yet only intel can sign the firmware, so users are helpless and malicious people can find bugs in the code while intel sits on their hands.

I don't find it hard to believe that Minix drivers are slow and primitive... Minix is not widely used like Linux, that doesn't really mean anything more than that, it's an amazing kernel and there is no better choice for an embedded system that you can't afford to fail and require user intervention.

I guess the TL;DR is that Minix was the right system for the job, it's just that the job was unfortunately pure evil, so arguing about Minix is stupid.

> additionally GNU is never popular for proprietary blobs like this... it would actually harm users with ME's current strategy if you think about it, GNU forces them to publish their likely buggy striped down version of linux

I don't know whether Intel ME contains the usual userland tools that are typical for UNIX-like operating systems. But it is well-known that a lot of MINIX 3's userland was taken/ported from NetBSD, as the MINIX 3 developers openly admit: http://wiki.minix3.org/doku.php?id=developersguide:portingne...

Yes I am aware this is why Minix has the BSD license throughout. To be clear in-case their is confusion: in the text you quote I am describing the hypothetical scenario where Intel used Linux + GNU userland to build ME.

Perhaps's it's unclear from reading the zdnet article, but anyhow, the idea is not to replace Minix in the ME, but rather get rid of, or at least disable, the ME as much as possible, then replace the upper levels of the UEFI stack + the bootloader with a minimal Linux + u-root userspace.

When the final distro kernel is booted by the firmware one, it replaces it. The firmware Linux kernel is thus NOT left running anywhere in the background doing insidious things.

This article is not FUD and crap. The source of the numbers quoted is here:

https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit...

I know Ron Minnich. He is one of the founders of the coreboot project. He's been at this (replacing proprietary firmware with a free software alternative) for a very long time and he knows what he is talking about.

But... replacing Minix with Linux wouldn't be replacing proprietary code with a free alternative. It would be replacing free software with a less free alternative.

Your use of 'free' here is correct from the perspective of a developer working for intel, but as a user with a cpu running modified and previously opensource, but now closedsource, software it isn't applicable to me. GPL would have protected more of my freedom, provided they didn't just violate the GPL.

None of the four freedoms are available in this context, Minix as part of the Intel ME.

cf.

  https://www.gnu.org/philosophy/free-sw.en.html

While I am unsure if switchting to Linux for ME is a good solution, open sourcing whatever runs ME is a very important step towards user/customer security. And that is not because we all want to know intels secrets about 'how to make the fastest CPU' but because ME can change the product on a fundamental level while we use the product.

The reason I doubt that Linux is a good solution is that linux wasn't built to run somewhere deep inside a cpu with very little overhead. Surely, it can run nearly everywhere, I just doubt that it is the best choice for that job.

Just to be clear: I love Linux, not just for what it is, but also for what it does and use it every day since more than a decade.

Well, someone managed to get Linux running on a Motorola 68k of all things: https://www.bigmessowires.com/2014/11/17/68-katy-68000-linux...

Linux has actually run on a Motorola 68k for quite some time (late 90's I think?)- what makes this special is its a 68008, which is a 68000, with an 8 bit data bus.

MINIX is already open source, the ME services are not.

> While I am unsure if switchting to Linux for ME is a good solution

FWIW, this is NOT at all the goal of the NERF project that this zdnet article talks about. So what the idea is roughly:

- Remove or disable the ME as much as possible (impossible to do 100% since e.g. the ME is responsible for booting up the main CPU, but it appears you can remove a large part of it)

- Replace the upper levels of the UEFI firmware stack and the bootloader with Linux + a minimal userspace written in Go (u-root).

See https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit... for more details.

A shrunk version of Linux can run on 8088 CPUs too. https://github.com/jbruchon/elks But the problem here isn't to put this or that OS in place of Minix but rather to get rid of that completely for good. Different licensing also wouldn't help at all: behind those people are the ones who actually write the laws; it would require 10 minutes of their time to make an exception for terrorism or child porn motivated surveillance.

So if switching to AMD is NOT the solution, what is? ARM?

For your portable needs there is: https://puri.sm/posts/purism-librem-laptops-completely-disab...

using your dollar elsewhere will help.

for example where?

AMD?

AMD processors now include PSP/TrustZone.

AMD PSP is efficiently ARM tech called TrustZone so I would expect most of SOC to have own backdoors as well.

So far only option is POWER-based systems and they're costly.

Pre-PSP AMD CPUs are an option.

SPARC was the solution. It's open and royalty free and was sold by multiple vendors. Add to that Open Firmware and you're done. It's also not the hacked up turd that x86-64 is or the fragmented mess that ARM is.

Problem is it's dead.

Going out on a limb here, but we can solve this with another layer of abstraction in the long term. We need to develop a fully portable open source virtual machine model (think p-code machine) that is portable and make that the canonical hardware abstraction. That makes all vendors irrelevant if they can't comply with it and opens the market to new hardware vendors with different sales models to provide an optimised hardware implementation of that abstraction. The incumbents (ARM, Intel, AMD) can't sell a security model if the abstraction denies them that ability. Sure they can sell you out, but new competition which is privacy focused should end that.

> Problem is it's dead.

and if it's so good, why is sparc dead?

Because most people don't buy their CPUs for openness, they buy them for price, performance and software support.

As far as I know, Fujitsu still sells it with high-end servers (attempting to take on IBM POWER), and it's still floating around in embedded designs, but it's a niche choice, with the associated downsides.

Yes. Software support was good, but price and performance were not. That and Oracle.

Big endian, not enough suppliers, Oracle, too expensive, not enough market share and much more

They are not making more, but reasonably priced used sparc64 servers are still reasonably easy to find. OpenBSD runs well on most models.

wasn't Java supposed to be precisely that?

Yes I suppose it was.

For desktop your options are:

— FX 8350 (Piledriver) from AMD with no PSP: very cheap, no flashing necessary, but not the best performance. Single core performance much worse than even Pentium G4620[1].

— Some Intel processors and a Raspberry Pi: much better performance but you have to ME_Clean the firmware, hence the Pi.

— POWER9 processor for amazing performance and completely open & free firmware all around: the CPU is $400 but you get $400 worth of performance, PCIe 4.0 etc., however the only mainboard you can get right now costs $2000, and it’s not x86, so you’d need to run your Windows VMs (if you need) on a seperate box.

Personally I recommend used IvyBridge-EP or Haswell Xeon E5 system, make sure it takes ECC DDR3 Reg ram and you can pick up lots of very cheap DDR3 ECC memory to go along with it.

Performance is pretty good, on par with mid level Ryzen[1], and it’s recent enough to have all the hardware extensions anyone cares about.

[1] http://cpu.userbenchmark.com/Compare/AMD-FX-8350-vs-Intel-Pe...

[2] http://cpu.userbenchmark.com/Compare/Intel-Xeon-E5-1650-v2-v...

EDIT: Post before wrongly stated that you need pre-Skylake chip. Skylake/Kabylake µarch is also an option now, however some restrictions apply. I don’t think it’s very good value though, at least until Coffeelake is compatible.

> Personally I recommend IvyBridge-EP or Haswell Xeon E5

Err, the ME has been present on every Intel system since 2006 or so.

The only thing that changed with Skylake is that the ME runs on an x86 core, on previous processors the ME ran on some RISC microcontroller.

That’s not the only thing, but yeah I suppose you can get Skylake/Kabylake now with the HAP workaround.

Not just any RISC, but ARC, a descendant of the SNES's Super-FX chip

I think OP meant to say that you can disable ME in those CPUs, since they are pre-Skylale silicon.

> — Some Intel processors and a Raspberry Pi: much better performance but you have to ME_Clean the firmware, hence the Pi.

The Pi also has a binary blob requirement and a Trustzone implementation (which is however open to tinkering).

It’s just inexpensive flasher for the firmware.

The PocketBeagle is competitive on price (<$25), and the chip has a complete 5000+ page, no-NDA datasheet/programming manual freely available from TI.

BeagleBone Black might be another option for flashing the firmware.

Thanks for the options you mentioned!

Are there tutorials do do this?: Some Intel processors and a Raspberry Pi: much better performance but you have to ME_Clean the firmware, hence the Pi.

https://github.com/corna/me_cleaner/wiki/How-to-apply-me_cle...

Thanks!

It's good to note that you still have mysterious chunks of blobs with newer laptops (including the purism one), also thanks to Intel - that's Intel FSP, that does the initialization for the processor and the memory.

Second, all system since about....2007 (?) have a Intel ME ROM burned inside the chipset, so there's no telling what is still running there, and what exactly is capable of.

ARM is an option as long as you have control over the TrustZone code, and some manufacturers give that to you. You'd probably have to rule out the large SoC vendors, though.

https://en.wikipedia.org/wiki/RISC-V

Maybe this:

https://minifree.org/product/libreboot-t400/

However, I assume any chip released after they added the backdoors also has the backdoors. So, you'd be looking for pre-2007, Pentium-class chips in SMP configuration. Maybe Pentium 4 Prescot-2M or Cedar Mill. Wikipedia shows the latter was on same node as Core Duo with 3-3.6GHz plus 2MB cache.

Far as non-Intel, both PPC and SPARC used Open Firmware. Plenty of them on eBay. Gaisler also made GPL versions of Leon3 you could build yourself or buy as a development board for who knows what price.

https://en.wikipedia.org/wiki/Open_Firmware

In high-assurance security, I remember BootSafe tech letting someone write firmware in Java to benefit from all its testing and verification tech that was then translated into Open Firmware's Forth in a way that preserved the properties. That tech went proprietary but still exists. Something similar could be done in FOSS with a Rust or SPARK to Forth converter leveraging hard work already done by compiler/verification teams of source languages.

http://www.cs.cornell.edu/~kozen/papers/acsac.pdf

I can't remove from my head the thought that the NSA has been exploiting that for years.

No need to. For anybody who's read the Snowden leaks it's 100% plausible that the NSA owns society through hardware backdoors.

Conclusion: We need 100% open-source hardware ASAP if we're to become a sane society.

Edit: Anyone remember the "Intel inside" trademark [0] which was supposed to add (marketing) value to any PC which was allowed to carry that label? Well, today it's clear that this label actually stands for "Intelligence community inside".

[0] https://www.intel.com/content/www/us/en/trademarks/intel-ins...

Implying opensource cannot contain backdoors for years. https://arstechnica.com/information-technology/2010/12/fbi-a...

Yeah but at least you have a chance to find the backdoors.

It is possible find backdoors in closed source software. Check the Cisco story.

Yeah but at least you have a better chance to find the backdoors. ;-)

The open-source approach is our own chance to purge corruption in the technology layer. We may not yet have implemented the idea perfectly, but keep in mind the following:

With every new player (government, company, user) joining the open-source approach, we get additional eyes on the code/hardware.

Imagine all world governments using only open-source code/hardware: Given the current budgets at play, we would have 100% secure code/hardware in a matter of seconds - for everybody on the Planet.

Why is this not happening? Because governments (currently) still do not fully represent the citizens' interests. They mainly represent their interests first (which is the protection and expansion of their power monopoly). This is called the principal-agent problem.

Let's suppose that hardware is open-source. How do I know that my instance of the hardware is faithful to the spec? That my vendor didn't modify the hardware?

Let's suppose that I have a 3D printer sophisticated enough to print open-source circuitboards. How do I trust my 3d printer?

I think there's a hardware "trusting trust" problem; I can't imagine how your optimism could ever be realized. I hope I'm missing something!

There will always be trust related issues, but that doesnt mean we shouldnt improve overall situation. Currently its possible there are all kind of backdoors in: hardware itself, firmware, drivers, some of closed source software. If we would limit it only to hardware itself that would be huge win.

I think the parent doesn't mean that open source will cure all problems but that it will move the bar higher for malicious players. If the designs were published and it'd be possible for anyone to review and build such a thing then it's exponentially harder to hide something.

You're not missing anything, it's just that with each added "hop" it becomes harder to implement a backdoor and have it undetected.

Your futuristic 3D printer could be backdoored to recognize certain patterns and modify them sneakily but that would be pretty sophisticated and somebody validating thoroughly the output could detect the unexpected divergence. Designing a generic backdoor that would work on any CPU design without being obvious sounds very tricky indeed.

It would also be very difficult to hide the code generating the backdoor if the software of the printer is open source itself. Then you'd have to insert inconspicuous code in the printer's driver which would have the very complex task of messing with the model to insert a backdoor in an arbitrary user-controlled design.

I am not sure if you understand the complexity of validating crypto or finding backdoors in software. It is possible to find bugs in closed source software and as the link I provided proves it is possible to "hide" backdoors in open source software.

100% secure? You must be joking. Since there is no code without bugs and certain percentage of bugs have security implications there is no 100% secure.

If it's not open it's even less likely to be found in the first place. Do you have other options?

How many people were capable of spotting a backdoor in the standard[1]? Do you think that an average person can just look at a source code and spot any backdoor or security bug?

1. https://www.wired.com/images_blogs/threatlevel/2013/09/15-sh...

Doesn't have to be manual, despite kids being taught programming within the next generation.

Automated fuzzing is a solution amongst others.

It does not have to be the average person. If it's open and if there is enough interest in the community, organizations can contract security professionals to audit the code. This has been done for several crypto projects even in recent history.

Did they ever find backdoors, or are they still pure speculation?

"sane society"

My personal belief is that this is a little optimistic. There's a lot wrong with our society, and intel embedding Minix in the ME doesn't really rise to the top of current issues.

I would really like an option that did not have binary blobs in the bios or CPU. That's tough, though...CPU's always have microcode fixes, don't they?

So far, I think the best option for this kind of thing is the Raptor workstation with the Power7 CPU.

> "sane society"

> My personal belief is that this is a little optimistic. There's a lot wrong with our society, and intel embedding Minix in the ME doesn't really rise to the top of current issues.

It's not optimistic. Society will change massively - in the good direction. We have still a lot of work ahead of us, and there will of course be pain along the way, but the Planet will become peaceful and clean again. And we are assisted in this process. How do I know? I've seen it.

Look, friend, I'm not trying to be argumentative to be a troll or anything. I get that you think that this is a super serious issue. I do to, but you have to admit that getting Minix and the ME out of PC CPU's won't really stop cops from shooting unarmed black men, or stop proliferation of cheap small arms in conflict zones, or the lack of clean water...I won't keep beating the drum.

I'm also not an SJW or whatever. I'm just saying that things that can be very important to us...that we think will have a tremendous impact on the future...those things aren't universal issues. Maybe it's just my lack of understanding of where you are coming from to see how this would be a major component of getting to a peaceful and clean world. If so, I would like to hear more. Thanks.

Well as Bill Binney said, what the NSA can tap into has no real relation to what they can do. They're mostly sucking funding with bad if not useless monitoring tools. Unless they're going after low hanging fruits (accessing some business information, not like avoiding terrorism)

In that case why didn't they remotely disable Snowden's laptop when he went on the run? My best guess is that the system isn't yet fully operational.

What would NSA spooks have achieved besides confirming that hardware backdoor are real (to those remaining few who still doubt)? Snowden could have simply took out HDD, put in into the new machine and resume his operation.

The ME has full control of the hardware and could have wiped the hard drive before bricking the machine. The NSA presumably would have preferred a bit of bad PR to actual classified information being leaked. A better argument would be that all laptops approved for use by NSA staff routinely have the HAP bit enabled.

I somehow suspect that Snowden was smart enough not to keep all eggs in a single basket. His laptop might as well has been mugged or stolen.

My guess is that with insider knowledge and a good firewall, a no-updates policy you can prevent phoning into the backdoor for a while.

> In that case why didn't they remotely disable Snowden's laptop when he went on the run?

There are several possible answers to that question:

1) "Just because you're paranoid doesn't mean they're not after you."

2) Because the risk of getting this backdoor known would not be worth the cost.

3) Because Snowden's laptop was used with airgap.

4) Because at that point, the cat was already out of the bag (the journalists had the data on SDs).

Now that Intel ME is getting so much attention, are there similar efforts to analyze AMD's PSP? I wonder about that since I'm planning to buy a new PC next year and was planning to go for AMD this time. Should I wait until security researchers have found ways to disable these for a certain chip/motherboard/firmware combination?

I'm thinking about buying an Intel chip, trying to disable ME, and send the motherboard and chip back as faulty if it gets bricked during that process.

It would be interesting to know the HFT attitude on this. How many nanoseconds can you shave off of your trades with ME removed?

It seems like throws a spanner in the face of the unikernel / kernel bypass approach of getting closer to the metal, when your CPU can be directly running a web server(!) without your control.

None. ME isn't running on the CPU.

It's possible that ME initiates memory access that clogs the bus, though.

I thought modern HFT machines run on FPGA/ASIC's?

Like mentioned in another comment, the ME runs on a separate CPU.

What might be of concern to real-time workloads are SMM interrupts, which AFAIU run on the main CPU and trap into the firmware. The NERF project might help here too, in that they are looking to either disable SMM or direct them to the Linux kernel.

Makes me wonder what Tanenbaum thinks of the arguably most common MINIX deployment. Considering that their conference has been cancelled [0] it would seem that this OS is largely unexplored and by extension not thoroughly audited.

[0] - http://www.minix3.org/

He doesn't seem to mind [1]:

"The only thing that would have been nice is that after the project had been finished and the chip deployed, that someone from Intel would have told me, just as a courtesy, that MINIX 3 was now probably the most widely used operating system in the world on x86 computers."

[1] - https://news.ycombinator.com/item?id=15642116

It is another proof that Andrew Tanenbaum should be awarded the Turning Award - all those privacy & security issues aside (as he is not involved in the deployment, he was not even told for the deployment), his Minix positively influenced an entire generation of software engineers and now it is proven to be practical in such a world scale deployment.

I had a question about this passage:

>"There's no reason not to make this improvement. Minnich noted, "There are probably 30 million-plus Chromebooks out there and when your Chromebook gets a new BIOS, a new Linux image is flashed to firmware and I haven't heard of any problems."

Didn't or don't some generations of Chromebooks use Intel chips? Or is he not referring to the ring -2 and ring -3 Intel ME/UEFI stuff here?

What a terribly writen article! Sure intel me is a terrible thing but all this fake information about minix being slow and obscure makes this article a joke

see NERF https://news.ycombinator.com/item?id=15572978

see also discussion yesterday (different article about the same thing): https://news.ycombinator.com/item?id=15634014

Title is inaccurate. MINIX is not Intel's. Why is this ME fluff piece being rehashed? Why are they talking about stupid ideas like replacing it with Linux?

What impact does this have on cloud computing security?

Reply on news.ycombinator.com

MINIX: ​Intel's hidden in-chip operating system

MINIX: Intel's hidden in-chip operating system