How to become the sole owner of your PC [pdf]
github.com
github.com
[1] https://archive.org/details/bitsavers_ibmpcat150ferenceMar84...
Occam's razor says they really just sell a ton of CPUs to huge datacenters and wanted to solve the problem of having to have some tech go out and physically reset a machine when it misbehaves. If you've ever accidentally powered down a machine that's sitting in some lights-out facility in Northern Alabraska, this kind of technology is a godsend. Now I'm not saying I'd bet my hat that it's 100% secure, or that Intel couldn't be thumb-screwed by the feds to use it as a backdoor in some scenario, but it wasn't built from the ground up to be one.
http://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf
SPARC and Java(!) are present in this system. It gives a whole new meaning to the "3 billion devices run Java" advert...
They even changed the CPU at some point. It used to be ARC, now it's SPARC. The LOM aspect of it didn't change. It worked just fine with ARC before. So why did it change?
There is no technical reason why implementing the LOM function is easier or better with one CPU compared with another. In fact, there's no technical reason why implementing anything is easier with one CPU or some other CPU. The new CPU seems even less power-efficient than their old one. The only reason why you'd want a particular CPU architecture is if you want to run some particular code for that particular CPU. And apparently running this secret code is so important, that it was worth the huge expense of porting all the other already-existing, already-working firmware they had before.
[1] http://en.wikipedia.org/wiki/ARC_%28processor%29
[2] http://www.eetimes.com/document.asp?doc_id=1248611
[3] http://blog.invisiblethings.org/2015/10/27/x86_harmful.html
Yes, they use Linux, but, as you say, they run a bunch of other crap that's old and buggy, and the implementation of the protocol itself is not stellar.
How many bugs were found in IPMI implementations vs. ssh over the last 5 years?
We don't need IPMI, we really only need ssh, and a console that allows setting things up (like Open Firmware on RISC machines).
We don't need a new protocol for remotely accessing our machines, when we can remotely export the plain old machine console securely.
Some vendors do work the way I described, at least for their RISC offerings, although, for example, the Oracle ILOM runs some Java web server crap by default. But at least you can turn it off and use pure ssh! No IPMI.
Intel is a large company, with lots of engineers, both hardware and software, managers, marketers and project managers. Some really stupid decisions will come out of simple scope creep and someones pet project suddenly becoming the next product.
Outside of evidence of actual malevolent intention, what you have here is easily a project gone really really weird.
How do I use this technology to, say, boot my turned off but plugged in and network-connected laptop?
I mean in a legitimate way. I'd really love to see how this works (and then be horrified).
I don't get your point. If it's just about OOB management, then there are already plenty of BMC technologies out there (IPMI, ILO, ...). There is no need for AMT/ME here. Or maybe I just misunderstood how this whole thing works.
https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor...
It is pretty expensive for the amount of performance you get, but you are getting a fully documented, auditable and free product. It comes with instructions on how to update/build/flash/modify your firmware. You're also supporting the Libreboot project.
Have you had the chance of using it?
The model I got has 8gb ram, 240gb SSD, 1tb HDD, Core2Duo processor, and is upgradeable to a Core2Quad.
However, I'm strongly considering just keeping it as a backup. To me it represents the best possible backup computer, durable and auditable.
It's backup for when my current computer breaks down, but also for when new sinister surveillance and encryption laws are passed. Or for when the web turns into even more of a wild-west with hackers and nation-states doing whatever they feel like.
I kinda feel like it was a bad idea to even discuss my ordering of this on a non-throwaway, from an IP vaguely linked to me.
.
That went kinda dark. Guess I haven't been taking enough Soma.
Problem is the project is mostly dead. Nothing in from the last four years is supported, and its stuck on Android 4.2.
Every brand of smartphone has this secondary firmware, entirely separate from the primary OS. Without it, you can't connect to the cellular network.
Well, they don't even need a separate coprocessor. They could just swap out the registers of the main CPU, and use the full power of that CPU. Basically, it would work like context-switching works in a multithreading environment.
https://en.wikipedia.org/wiki/Open-source_computing_hardware...
Benchmarks: http://www.phoronix.com/scan.php?page=article&item=talos-wor...
For most applications, the end user gets vastly more computing power per dollar spent when they buy an off the shelf design that's in large scale mass production.
You could port BSD or Linux to your new architecture for a reasonable amount of money (though that's already an uphill battle selling that to a consumer). How are you going to even come close to the unit economies of scale that Intel and other large established players enjoy?
[0] http://spectrum.ieee.org/semiconductors/design/the-death-of-...
for personal computing, I'd take the later
I do own a desktop gaming PC though. It's running Windows 10 on a respectable Intel CPU with a highish end nVidia graphics card. On it are my games. On it are only my games. If I need to do any development work, I boot that machine into Arch Linux. That's partly because I don't trust Windows, but it's mostly because the development environment is better on a Linux system anyway, for what I do regularly.
So, yes, it would work fine depending on your needs, but be aware that a core 2 is not exactly a bad CPU. It is a 4-wide aggressively out of order machine with a pretty good memory subsystem. Is any of the open CPU replacements as good?
# Why is the latest AMD hardware unsupported in libreboot?
It is extremely unlikely that any post-2013 AMD hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible. The main issues are as follows:
# AMD Platform Security Processor (PSP)
This is basically AMD's own version of the Intel Management Engine. It has all of the same basic security and freedom issues, although the implementation is wildly different.
That sounds even worse than ME:
Intel Management Engine (ME) is a separate computing environment physically located in the (G)MCH chip.
Theoretically, if a third-party can figure out how to make a compatible MCH they can use Intel CPUs without ME, but that is impossible with AMD's design.
Then again, developing a compatible MCH would be nontrivial too --- the last truly "open" x86 bus interface was probably Socket 370 (still in use by VIA and others), and the later bus interfaces are such high speed that they require some very expensive signal analysers to even see the communications properly.
I have recently purchased a pi-top which is basically a 3d-printed laptop case + laptop battery + keyboard + display + raspberry pi 3. The keyboard could be better and I'll swap out the pi for a beagle bone black (pi comes with a binary blob) but it's a surprisingly useful package. I only bought it to experiment a bit with ARM assembly on the go but it's actually powerful enough for a lot of day to day stuff (mail, surfing, libre office, programming). Not great but good enough.
Of course you have to be willing to trade speed and availability of some programs for that control but in theory a beagle bone + input and output devices is a nice little open machine for a lot of day to day stuff.
The various warts in the implementation (e.g. no BIOS, so there's quite some effort going just into making something boot on a new ARM board) and the non-standard, or just closed source-dependent, augmentations that are required in order to make an ARM CPU do anything breathtaking (PowerVR and Mali, TI's EVEs) also mean that, at least if you're using Linux, you're often living outside the mainline kernel. I have very few kind words to say about some of the code that I've seen in manufacturers' kernel trees, especially on let's-pump-two-more-cores-before-next-years-mobile-world-so-that-we-can-play-a-demo-that-looks-exactly-like-last-year-except-salespeople-are-gasping-for-some-reason, the ancient Indian name by which ARM is also known in some places. I would rather not have useful/important data reside on devices which run that stuff.
I'll yield to more informed people but searching a reasonably useful and completely open (I guess I can live without HDL for everything but it would be nice) machine has been a quest I go on every now and then. ARM seems to be the best (and most affordable) bet. I'll gladly take other suggestions as the whole ARM licensing model doesn't really sit well with me.
I haven't ran OpenBSD on the BeagleBone Black, but I imagine it has no graphical output of any kind. I see the X packages but the only on-board devices that are listed as supported are:
BeagleBone, BeagleBone Black
Supported on-board devices:
standard serial port (com)
watchdog controller (omdog)
ethernet controller (cpsw)
GPIO controller (omgpio)
I run into various ARM platforms at $work. The platform, as a whole, is probably a step backwards from e.g. PowerPC; it's very relevant today because its power consumption is very hard to beat, and between mobile phones, tablets, IoT and in-car infotainment, this is an important topic. But unless you need something that's super low power, the only thing ARM CPUs have to show for themselves is that they aren't x86. This is more than made up for by the headaches involved into getting stuff that runs on a company's Cortex A7 to run on another company's Cortex A7.
This isn't to say that it's a bad thing. Pre-64-bit ARMs were designed (with the exception of some really old stuff in the 80s) as a platform for appliances, not for computers. They're excellent for designing phones and tablets and smart TVs and whatnot. It's trying to bolt a general-purpose environment on top of them that gives people headaches.
NetBSD has a framebuffer driver for TI OMAP CPUs so it could be possible to port it to OpenBSD.
https://en.wikipedia.org/wiki/Intel_Active_Management_Techno...
A nice overview of what AMT and ME is capable of (and has been for the past decade) can be found in libreboot FAQ:
seriously, AMT is stuff of nightmares. runs even when machine is powered off.
Biggest irony: they advertise it as a feature for IT management. ;)
The other thing that's even stranger is Absolute Software, a little company nobody has ever heard of who somehow got every OEM to bundle their code in system BIOS for theft recovery since the 90s.
It seriously reads like a botnet description. I'd have believed them if they said "From the innovators behind Storm comes new endpoint protection..."
You can do some wacky shit with it. There is one mode where you can configure it to delete certain directories or files to screw around with a thief. That can be tweaked to delete files that the system needs. Those modes are persistent, and even after reformatting or replacing the boot media, the agent will reinstall and retrieve its policy file.
If you use it with Intel AMT, it can also brick the device permanently. (http://www.intel.com/content/dam/doc/product-brief/mobile-co...)
Everyone who tested the product had two questions: "Who is buying this?" and "How do I get this dormant code off my devices?"
Laptops aren't cheap, but they aren't expensive enough as an asset to care that much about recovery. And there are arguably better ways to safeguard data assets.
https://calhoun.nps.edu/bitstream/handle/10945/6073/02Mar_An...
https://news.ycombinator.com/item?id=10906999
Basically, modern SOC's are mixed-signal systems that have digital, analog, and often RF capabilities. I've imagined, with limited HW knowledge, quite a few attacks on digital subsystems using analog or RF components. HW gurus I know encounter sneaky stuff like that in 3rd party I.P. regularly and have to mitigate it. Most people have no clue it exists. They're mitigating at the networking channel which is a mere abstraction for more complex stuff going on in chip and interface point. You could even embed a radio in the sucker that turned on when it detected a certain signal in a packet header that NIDS certainly wasn't analyzing.
Note that NSA TAO catalog includes active attacks with radars that rely on physical materials in counterfeit parts and SOC's with embedded radios hidden in USB connectors. Quite a few attacks at SOC level software people will never see coming.
Nope, I'm talking about scale. You'd need to signal (paint with radar, send a packet, dip the power in morse code, put the magic cookie in the root DNS server response, whatever) every target at least once prior to exploitation. But yes, stealth would certainly be a concern that would reduce the value of AMT relative to a factory backdoored RNG.
> A Ring -3 rootkit was demonstrated by Invisible Things Lab for the Q35 chipset; it does not work for the later Q45 chipset as Intel implemented additional protections.[39] The exploit worked by remapping the normally protected memory region (top 16 MB of RAM) reserved for the ME. The ME rootkit could be installed regardless of whether the AMT is present or enabled on the system, as the chipset always contains the ARC ME coprocessor. (The "-3" designation was chosen because the ME coprocessor works even when the system is in the S3 state, thus it was considered a layer below the System Management Mode rootkits.[32]) For the vulnerable Q35 chipset, a keystroke logger ME-based rootkit was demonstrated by Patrick Stewin.[40][41]
Any ideas what a Chinese ARM chip might have for backdoors?
Did I miss it in the slides?
I see explanations and low-level temporary/soft-disablement references, but nothing immediately actionable.
The Intel Management Engine is another computer in your computer, running its own OS, and able to see everything your computer is doing, and modify it, including things like network transfers.
Woah, that's not just sitting there but actually actively doing stuff while bypassing your kernel. This sounds a lot more scary even though I know nothing about this Lenovo dhcp thing, observing it just makes it a lot more real to me.
Do you have any more information on this?
Also see https://media.ccc.de/v/30C3_-_5380_-_en_-_saal_2_-_201312291...
EDIT: I forgot to mention Computrace, the BIOS anti-theft service. IIRC that interacts with ME.
[0] https://en.wikipedia.org/wiki/Intel_Active_Management_Techno...
[1] https://www.kernel.org/doc/Documentation/misc-devices/mei/me...
If you want to firewall ports or IP addresses on the machine itself, obviously that doesn't do anything, so what you'd need to do is do it on your router (that you hope doesn't have a similar backdoor that cooperates with ME), first you'd need to know what to block, which is difficult enough, and then you'd have to trust that that information doesn't change.
But event then all it takes is for AWS or CloudFlare or $Foo to collude with Intel to get at your juicy data again, so you really would need to work on a blocked-by-default basis, which is possible, but not really practical, depending on what you're doing.
It really depends on what your threat model is. If your're a high value target to someone with a lot of resources, you're essentially screwed.
It can broadcast information via your speakers, and maybe even your microphone. It can encode data in the timing of your packets as they leave your system. It can encode data in it's power consumption, it can encode data in what it sends to the screen, it can send data out via bluetooth or wifi. There are probably more ways, that I didn't think of off the top of my head.
We have Free Software all the way down to the firmware level. Not widely available, but the potential is there. That is good.
But for computers that we can really trust, we need to go deeper.
looks up Czochralski process
I’m back to using a realtek NIC from 2006 now.
Edit: It worked when I requested the desktop version of github though.
<tinfoil_hat>maybe ME is detecting it and wants to prevent us from knowing about it?!?</tinfoil_hat>
Talk is ~3.5minutes transcribed live to English. Sadly you're not missing much by just looking at the PDF.