Sometimes the end of a product’s production run is surrounded by publicity, a mix of a party atmosphere celebrating its impact either good or bad, and perhaps a tinge of regret at its passing. Think of the last rear-engined Volkswagens rolling off their South American production lines for an example.
Then again, there are the products that die with a whimper, their passing marked only by a barely visible press release in an obscure corner of the Internet. Such as this week’s discontinuances from Intel, in a series of PDFs lodged on a document management server announcing the end of their Galileo (PDF), Joule (PDF), and Edison (PDF) lines. The documents in turn set out a timetable for each of the boards, for now they are still available but the last will have shipped by the end of 2017.
It’s important to remember that this does not mark the end of the semiconductor giant’s forray into the world of IoT development boards, there is no announcement of the demise of their Curie chip, as found in the Arduino 101. But it does mark an ignominious end to their efforts over the past few years in bringing the full power of their x86 platforms to this particular market, the Curie is an extremely limited device in comparison to those being discontinued.
Will the departure of these products affect our community, other than those who have already invested in them? It’s true to say that they haven’t made the impression Intel might have hoped, over the years only a sprinkling of projects featuring them have come our way compared to the flood featuring an Arduino or a Raspberry Pi. They do seem to have found a niche though where there is a necessity for raw computing power rather than a simple microcontroller, so perhaps some of the legion of similarly powerful ARM boards will plug that gap.
So where did Intel get it wrong, how did what were on the face of it such promising products fizzle out in such a disappointing manner? Was the software support not up to scratch, were they too difficult to code for, or were they simply not competitively priced in a world of dirt-cheap boards from China? As always, the comments are open.
At the Bay Area Maker Faire last weekend, Intel was showing off a couple of sexy newcomers in the Single Board Computer (SBC) market. It’s easy to get trapped into thinking that SBCs are all about simple boards with a double-digit price tag like the Raspberry Pi. How can you compete with a $35 computer that has a huge market share and a gigantic community? You compete by appealing to a crowd not satisfied with these entry-level SBCs, and for that Intel appears to be targeting a much higher-end audience that needs computer vision along with the speed and horsepower to do something meaningful with it.
I caught up with Intel’s “Maker Czar”, Jay Melican, at Maker Faire Bay Area last weekend. A year ago, it was a Nintendo Power Glove controlled quadcopter that caught my eye. This year I only had eyes for the two new computing modules on offer, the Joule and the Euclid. They both focus on connecting powerful processors to high-resolution cameras and using a full-blown Linux operating system for the image processing. But it feels like the Joule is meant more for your average hardware hacker, and the Euclid for software engineers who are pointing their skills at robots but don’t want to get bogged down in first-principles of hardware. Before you rage about this in the comments, let me explain.
Betteridge’s Law of Headlines states, “Any headline that ends in a question mark can be answered by the word no.” This law remains unassailable. However, recent claims have called into question a black box hidden deep inside every Intel chipset produced in the last decade.
Yesterday, on the Semiaccurate blog, [Charlie Demerjian] announced a remote exploit for the Intel Management Engine (ME). This exploit covers every Intel platform with Active Management Technology (AMT) shipped since 2008. This is a small percentage of all systems running Intel chipsets, and even then the remote exploit will only work if AMT is enabled. [Demerjian] also announced the existence of a local exploit.
Intel’s ME and AMT Explained
Beginning in 2005, Intel began including Active Management Technology in Ethernet controllers. This system is effectively a firewall and a tool used for provisioning laptops and desktops in a corporate environment. In 2008, a new coprocessor — the Management Engine — was added. This management engine is a processor connected to every peripheral in a system. The ME has complete access to all of a computer’s memory, network connections, and every peripheral connected to a computer. The ME runs when the computer is hibernating and can intercept TCP/IP traffic. Management Engine can be used to boot a computer over a network, install a new OS, and can disable a PC if it fails to check into a server at some predetermined interval. From a security standpoint, if you own the Management Engine, you own the computer and all data contained within.
The Management Engine and Active Management Technolgy has become a focus of security researchers. The researcher who finds an exploit allowing an attacker access to the ME will become the greatest researcher of the decade. When this exploit is discovered, a billion dollars in Intel stock will evaporate. Fortunately, or unfortunately, depending on how you look at it, the Managment Engine is a closely guarded secret, it’s based on a strange architecture, and the on-chip ROM for the ME is a black box. Nothing short of corporate espionage or looking at the pattern of bits in the silicon will tell you anything. Intel’s Management Engine and Active Management Technolgy is secure through obscurity, yes, but so far it’s been secure for a decade while being a target for the best researchers on the planet.
In yesterday’s blog post, [Demerjian] reported the existence of two exploits. The first is a remotely exploitable security hole in the ME firmware. This exploit affects every Intel chipset made in the last ten years with Active Management Technology on board and enabled. It is important to note this remote exploit only affects a small percentage of total systems.
The second exploit reported by the Semiaccurate blog is a local exploit that does not require AMT to be active but does require Intel’s Local Manageability Service (LMS) to be running. This is simply another way that physical access equals root access. From the few details [Demerjian] shared, the local exploit affects a decade’s worth of Intel chipsets, but not remotely. This is simply another evil maid scenario.
Should You Worry?
The biggest network security threat today is a remote code execution exploit for Intel’s Management Engine. Every computer with an Intel chipset produced in the last decade would be vulnerable to this exploit, and RCE would give an attacker full control over every aspect of a system. If you want a metaphor, we are dinosaurs and an Intel ME exploit is an asteroid hurtling towards the Yucatán peninsula.
However, [Demerjian] gives no details of the exploit (rightly so), and Intel has released an advisory stating, “This vulnerability does not exist on Intel-based consumer PCs.” According to Intel, this exploit will only affect Intel systems that ship with AMT, and have AMT enabled. The local exploit only works if a system is running Intel’s LMS.
This exploit — no matter what it may be, as there is no proof of concept yet — only works if you’re using Intel’s Management Engine and Active Management Technology as intended. That is, if an IT guru can reinstall Windows on your laptop remotely, this exploit applies to you. If you’ve never heard of this capability, you’re probably fine.
Still, with an exploit of such magnitude, it’s wise to check for patches for your system. If your system does not have Active Management Technology, you’re fine. If your system does have AMT, but you’ve never turned it on, you’re fine. If you’re not running LMT, you’re fine. Intel’s ME can be neutralized if you’re using a sufficiently old chipset. This isn’t the end of the world, but it does give security experts panning Intel’s technology for the last few years the opportunity to say, ‘told ‘ya so’.
The Intel 8085 microprocessor was introduced 40 years back, and along with its contemporaries — the Z80 and the 6502 — is pretty much a dinosaur in terms of microprocessor history. But that doesn’t stop it from still being included in the syllabus for computer engineering students in many parts of the world. The reason why a 40 year old microprocessor is still covered in computer architecture text books instead of computer history is a bit convoluted. But there’s a whole industry that thrives on the requirements of college laboratories and students requiring “8085 Microprocessor Training Kits”. [TisteAndii] just finished college in Nigeria, where these kits are not locally built and need to be imported, usually costing well over a 100 dollars.
Which is why his final year project was a low cost Intel 8085 Microprocessor Trainer. It’s a minimalist design with some basic read/write memory, program execution and register inspection, with no provision for single stepping or interrupts yet. The monitor program isn’t loaded in an EEPROM. Instead, a PIC18 is used and connected to the 8085 address, data and control pins. This makes it easier to write a monitor program in C instead of assembly. And allows use of a 1.8″ LCD with SPI interface instead of the more usual 7-segment displays used for these kind of kits. [TisteAndii] built a 6×4 keyboard for input, but couldn’t solve debounce issues and finally settled on a 5×4 membrane keypad.
Being a rookie, he ended up with a major flaw in his board layout — he missed connecting the SRAM and the PPI devices to the data bus. A bunch of jumper links seemed to solve the issue, but it wasn’t perfect. This, and a few other problems gave him a lot of grief, but towards the end, it all worked, almost. Most importantly, his BoM cost of about $35 makes it significantly cheaper compared to the commercial units available in Nigeria.
While some hackers may consider this a trivial project, it solves a local problem and we hope the next iteration of the design improves the kit and makes it more accessible.
As an Apple user, I’ve become somewhat disillusioned over the past few years. Maybe it’s the spirit of Steve Jobs slowly vanishing from the company, or that Apple seems to care more about keeping up with expensive trends lately rather than setting them, or the nagging notion Apple doesn’t have my best interests as a user in mind.
Whatever it is, I was passively on the hunt for a new laptop with the pipe dream that one day I could junk my Apple for something even better. One that could run a *nix operating system of some sort, be made with quality hardware, and not concern me over privacy issues. I didn’t think that those qualities existed in a laptop at all, and that my 2012 MacBook Pro was the “lesser of evils” that I might as well keep using. But then, we published a ThinkPad think piece that had two words in it that led me on a weeks-long journey to the brand-new, eight-year-old laptop I’m currently working from. Those two words: “install libreboot”.
The usefulness of Raspberry Pis seems almost limitless, with new applications being introduced daily and with no end in sight. But, as versatile as they are, it’s no secret that Raspberry Pis are still lacking in pure processing power. So, some serious optimization is needed to squeeze as much power out of the Raspberry Pi as possible when you’re working on processor-intensive projects.
This simplest way to accomplish this optimization, of course, is to simply reduce what’s running down to the essentials. For example, there’s no sense in running a GUI if your project doesn’t even use a display. Another strategy, however, is to ensure that you’re actually using all of the available processing power that the Raspberry Pi offers. In [sagiz’s] case, that meant using Intel’s open source Threading Building Blocks to achieve better parallelism in his OpenCV project.
Five or so years ago, Intel rolled out something horrible. Intel’s Management Engine (ME) is a completely separate computing environment running on Intel chipsets that has access to everything. The ME has network access, access to the host operating system, memory, and cryptography engine. The ME can be used remotely even if the PC is powered off. If that sounds scary, it gets even worse: no one knows what the ME is doing, and we can’t even look at the code. When — not ‘if’ — the ME is finally cracked open, every computer running on a recent Intel chip will have a huge security and privacy issue. Intel’s Management Engine is the single most dangerous piece of computer hardware ever created.
Previously, the first iteration of the ME found in GM45 chipsets could be removed. This technique was due to the fact the ME was located on a chip separate from the northbridge. For Core i3/i5/i7 processors, the ME is integrated to the northbridge. Until now, efforts to disable an ME this closely coupled to the CPU have failed. Completely removing the ME from these systems is impossible, however disabling parts of the ME are not. There is one caveat: if the ME’s boot ROM (stored in an SPI Flash) does not find a valid Intel signature, the PC will shut down after 30 minutes.
A few months ago, [Trammell Hudson] discovered erasing the first page of the ME region did not shut down his Thinkpad after 30 minutes. This led [Nicola Corna] and [Frederico Amedeo Izzo] to write a script that uses this exploit. Effectively, ME still thinks it’s running, but it doesn’t actually do anything.
With a BeagleBone, an SOIC-8 chip clip, and a few breakout wires, this script will run and effectively disable the ME. This exploit has only been confirmed to work on Sandy Bridge and Ivy Bridge processors. It should work on Skylake processors, and Haswell and Broadwell are untested.
Separating or disabling the ME from the CPU has been a major focus of the libreboot and coreboot communities. The inability to do so has, until now, made the future prospects of truly free computing platforms grim. The ME is in everything, and CPUs without an ME are getting old. Even though we don’t have the ability to remove the ME, disabling it is the next best thing.