Experiments with disabling the ME on Sandybridge x230(coreboot.org)
coreboot.org
Experiments with disabling the ME on Sandybridge x230
https://www.coreboot.org/pipermail/coreboot/2016-September/082016.html
115 comments
For this NTP check to happen, you must be using a computer with Intel MEBX and an Intel AMT-enabled network adapter, and the network adapter must be configured with network information to use. You have to do this manually initially, although of course later you can configure AMT using AMT.
This isn't something your consumer computer is doing automatically, in fact, your computer is almost certainly not capable because it lacks an AMT-capable NIC. I suspect the software capability is baked into ME itself rather than the AMT component so it's probably present in your ME, but it's not doing anything without an AMT NIC to communicate with.
This is the kind of feature that you pay an extra $1k for when you configure your $20k server.
This isn't something your consumer computer is doing automatically, in fact, your computer is almost certainly not capable because it lacks an AMT-capable NIC. I suspect the software capability is baked into ME itself rather than the AMT component so it's probably present in your ME, but it's not doing anything without an AMT NIC to communicate with.
This is the kind of feature that you pay an extra $1k for when you configure your $20k server.
> This is the kind of feature that you pay an extra $1k for when you configure your $20k server.
We have ~$400 Sandy Bridge workstations at work that have separate AMT enabled NICs. You don't have to spend $1k for the feature; here's a vPro enabled board for $100:
http://www.newegg.com/Product/Product.aspx?Item=N82E16813157...
We have ~$400 Sandy Bridge workstations at work that have separate AMT enabled NICs. You don't have to spend $1k for the feature; here's a vPro enabled board for $100:
http://www.newegg.com/Product/Product.aspx?Item=N82E16813157...
Not specifically ME but yeah Baseboard Management Controllers and IPMI modules have been a thing for a long time. Most real server motherboards have them or have the facilities in place to accept them as an add-on module. It's not even just stuff in the $20k range; this $450 mini itx 8-core Atom-based storage server board has it: http://www.asrockrack.com/general/productdetail.asp?Model=C2... and it comes with a web-based IPMI console. You can turn the power on and watch it POST with a java web screen viewer, sending it keys as if you were sitting there.
Dell's add-in card to do out-of-band management is called the DRAC and it's been optional in their servers for about 17 years: https://en.m.wikipedia.org/wiki/Dell_DRAC
Dell's add-in card to do out-of-band management is called the DRAC and it's been optional in their servers for about 17 years: https://en.m.wikipedia.org/wiki/Dell_DRAC
And I think you typically do not expose IPMI to the WAN. Separate dedicated private network.
It's been hacked before, too, see:
https://defcon.org/images/defcon-22/dc-22-presentations/Kall...
and
http://legbacore.com/Research_files/HowManyMillionBIOSWouldY...
The example in the first link is especially depressing, because they found an integer overflow vulnerability in a code file that started with this warning comment:
https://defcon.org/images/defcon-22/dc-22-presentations/Kall...
and
http://legbacore.com/Research_files/HowManyMillionBIOSWouldY...
The example in the first link is especially depressing, because they found an integer overflow vulnerability in a code file that started with this warning comment:
/*
Caution: This module requires additional review when
modified.
This driver will have external input − capsule image.
This external input must be validated carefully
to avoid security issue like buffer overflow, integer
overflow. */
> Does that work over wifi (where does it get the WPA password from)?
http://superuser.com/questions/360754/what-is-intel-active-m...
http://superuser.com/questions/360754/what-is-intel-active-m...
ISBN 9781430265719: "To get the current date/time information, the EPID manager requests a real-time OCSP (Online Certificate Status Protocol) response from a trusted OCSP server, which was endorsed by Intel. The response contains the current date/time. The EPID manager saves the date/time (baseline) in a file in the kernel’s secure storage and calls the kernel’s Start timer function that starts the timer. Later, when the EPID manager is verifying the validity period of a certificate, it calls the Get current timer value function and calculates the current date/time by adding the kernel’s returned value to the baseline. The EPID manager requests a new real-time OCSP response every 30 days to calibrate its timer."
Tangental, but interesting in a The-Dystopian-Future-Is-Now! sense: "The endorsement key initially placed in security fuses may be revoked by the TPM2_ChangeEPS command introduced in TPM 2.0. In this case, the TPM must generate a new endorsement key pair, store it in nonvolatile memory, and remember not to use the one in the security fuses in the future. The TPM task uses a field programmable fuse for the purpose of saving the revocation status of the endorsement key in fuses."
The fuses are blown when the chip is manufactured to encode a _pre-calculated_ 2048-bit rsa key-pair, selected from a giant collection which intel generated en-mass to have some properties that allow the two 1024-bit primes to be encoded using only 272 bits each (if I'm reading it right):
"The TPM on the security and management engine features a preinstalled endorsement key (2048-bit RSA). The endorsement key is required to be unique per hardware part. Because of its uniqueness, the endorsement key cannot simply be hard-coded in the firmware, which is the same on all parts. Instead, hundreds of millions of endorsement keys are pregenerated. During Intel’s manufacturing process, different key materials are burned to the platform’s security fuses for all parts, respectively. Note that key materials are not the key value. [...] This algorithm is implemented by the key generation facility and not the TPM firmware."
(Same source as parent)
The fuses are blown when the chip is manufactured to encode a _pre-calculated_ 2048-bit rsa key-pair, selected from a giant collection which intel generated en-mass to have some properties that allow the two 1024-bit primes to be encoded using only 272 bits each (if I'm reading it right):
"The TPM on the security and management engine features a preinstalled endorsement key (2048-bit RSA). The endorsement key is required to be unique per hardware part. Because of its uniqueness, the endorsement key cannot simply be hard-coded in the firmware, which is the same on all parts. Instead, hundreds of millions of endorsement keys are pregenerated. During Intel’s manufacturing process, different key materials are burned to the platform’s security fuses for all parts, respectively. Note that key materials are not the key value. [...] This algorithm is implemented by the key generation facility and not the TPM firmware."
(Same source as parent)
You would have to enable it first I think though.
I thought you couldn't disable it?
https://www.coreboot.org/pipermail/coreboot/2016-September/0... - "AFAIK the ME will allow the platform to stay on for 30 minutes, and will then shut it down hard." (when the firmware/ME has gone bad)
https://www.coreboot.org/pipermail/coreboot/2016-September/0... - "AFAIK the ME will allow the platform to stay on for 30 minutes, and will then shut it down hard." (when the firmware/ME has gone bad)
This 30-minutes-then-shutdown annoyance looks to be optional and disabled at the very least on the x230 machine that trmm is hacking on:
https://www.coreboot.org/pipermail/coreboot/attachments/2016...
If this will turn out to be something that could be reliably disabled on other laptops, this is going to be huge.
https://www.coreboot.org/pipermail/coreboot/attachments/2016...
If this will turn out to be something that could be reliably disabled on other laptops, this is going to be huge.
I am talking about the remote management feature, aka Intel AMT.
As much as people are freaked out by the capabilities of ME, I really like the concept of AMT.
I built a headless compile-slave box recently, and was looking forward to using AMT features to manage it and keep it headless, but found out too late that the board I ordered didn't have AMT support. Now, whenever its fragile boot-stack of GRUB+iSCSI+Xen+LVM decides to wedge into single-user mode on a reboot, I have to power the box off and carry it over to a monitor to see what's wrong. I'd much rather just fix it from my laptop.
I built a headless compile-slave box recently, and was looking forward to using AMT features to manage it and keep it headless, but found out too late that the board I ordered didn't have AMT support. Now, whenever its fragile boot-stack of GRUB+iSCSI+Xen+LVM decides to wedge into single-user mode on a reboot, I have to power the box off and carry it over to a monitor to see what's wrong. I'd much rather just fix it from my laptop.
These kinds of features are standard for servers and nobody bats an eye ("out of band management"). You need them unless you want to attach a remote KVM to every single server. AMT is just that - out of band management. Intel's implementation is a lot more secure than, say, SuperMicro IPMI which had its fair share of issues.
You can disable SuperMicros IPMI though by pulling out the PCI card, though :-)
You can disable SuperMicros IPMI though by pulling out the PCI card, though :-)
Why can't you attach a serial console? This will help with any problems that still let you get to grub (BIOS Setup likely doesn't support UI over serial, unless it's a server-like machine).
Once you have a serial console, you can either just plug the cable into your laptop (likely through USB-attached serial port) or set up a small second box (that just runs an ssh daemon and has something like picocom installed) and connect it to that. Then you'll have access over the network.
Once you have a serial console, you can either just plug the cable into your laptop (likely through USB-attached serial port) or set up a small second box (that just runs an ssh daemon and has something like picocom installed) and connect it to that. Then you'll have access over the network.
The capabilities of an out-of-band management system are much, much greater than the serial console offers. BIOS and UEFI configuration are an obvious case, but you also use out-of-band management to bail yourself out of situations where the OS is unresponsive or unbootable, and to take many other management actions that would normally require physical access.
Serial consoles don't help if the box is properly wedged, or has eaten its own bootloader. With a good out of band management system, you can install an OS remotely, with disks on the session driving it appearing as local disks to the machine. Or, you can power off a box as needed, power it on, reconfigure raid cards, etc. A remote serial console is very limited in comparison.
I really like the concept of AMT.
As long as the actual owner has the keys, I agree.
As long as the actual owner has the keys, I agree.
It's a shame that ME can't be removed or disabled on modern Intel CPU's. Same goes for AMD and maybe companies that implement something like ME in ARM. OpenSPARC is quite dead, sadly enough.
Highly recommended read about x86 security: http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
The author of this paper is also the developer of Qubes OS. They recently added another requirement to laptops who are 'Qubes certified': they must run Coreboot. It's not Libreboot yet, but that is a huge leap forward for x86 security. Hopefully this will trigger vendors to make their hardware Coreboot compatibile. It won't do anything about Intel ME, but it is a step in the right direction.
I ordered a Thinkpad x200 to flash it with Libreboot last week, just to have at least one device without any malware (in RMS sense)
Highly recommended read about x86 security: http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
The author of this paper is also the developer of Qubes OS. They recently added another requirement to laptops who are 'Qubes certified': they must run Coreboot. It's not Libreboot yet, but that is a huge leap forward for x86 security. Hopefully this will trigger vendors to make their hardware Coreboot compatibile. It won't do anything about Intel ME, but it is a step in the right direction.
I ordered a Thinkpad x200 to flash it with Libreboot last week, just to have at least one device without any malware (in RMS sense)
Y'all all ordered Talos, right? https://www.raptorengineering.com/TALOS/prerelease.php
Or Novena? https://www.crowdsupply.com/sutajio-kosagi/novena
No?
Or Novena? https://www.crowdsupply.com/sutajio-kosagi/novena
No?
> ... for around $5,300 USD.
Well, let me take a step back and first say that the project is impressive and I really like it.
But the cost is staggering.
Well, let me take a step back and first say that the project is impressive and I really like it.
But the cost is staggering.
For something rather more low-end, but good enough for some common tasks, don't forget EOMA68: https://www.crowdsupply.com/eoma68/micro-desktop
I own a Novena. It's a fun piece of hardware.
As just a day-to-day computer for software development, how does it work out? Can it run Firefox/Chromium just fine? What sort of issues have you had?
I've got a couple of Novenas. It's good for development except for web-browsing; for whatever reason firefox and chromium are both pretty sluggish on it. Everything else seems fine; I suspect that it's mostly down to video drivers, which are still somewhat in a state of flux (but getting better).
I'm skeptical about whether the video drivers are the culprit for poor web browsing performance. Yes, there's WebGL, but do Firefox and Chromium depend that critically on OpenGL for rendering ordinary web pages?
Yeah, Novena will be much more usable once the etnaviv drivers are ready.
I believe both the Librem laptops and the ORWL PC will soon use Coreboot, and they are much cheaper.
There's zero chance that the future Librem laptops will be "truly" open source. They will still have ME or AMD equivalent. Their entire marketing campaign is frustratingly dishonest.
They're quite competent con men. If you call them out about it (as the Coreboot developers did) especially on Reddit, they give very dismissive, yet non-committal comments
"We're in talks with Intel" "They really want to do this" "We're going to make a petition to show interest to Intel"
The reality is that even Google with their Chromebooks, despite hiring most of the Coreboot team and shipping volume into the likely millions of units, was unable to persuade Intel. Even for the absolutely tiny set of CPU models they use
"We're in talks with Intel" "They really want to do this" "We're going to make a petition to show interest to Intel"
The reality is that even Google with their Chromebooks, despite hiring most of the Coreboot team and shipping volume into the likely millions of units, was unable to persuade Intel. Even for the absolutely tiny set of CPU models they use
Those still have the eeeeevil ME, although maybe in a semi-dormant form.
I have an x200 sitting around (although the case is cracked after a drop) but I've held off on trying libreboot because it requires a ~$50 piece of hardware to flash it (a BeagleBone Black)
Don't need a beagle bone black. I have flashed my laptop (T500) with a raspberry pi just fine.
Could you direct me to a tutorial on that? I contacted the Libreboot devs before and they told me they wouldn't give any info out about using a different device
Sorry didn't see this yesterday. Don't know if you will come back. Here is some a page that helped me with the wiring: https://web.archive.org/web/20150908054150/http://blogs.fsfe... and https://github.com/bibanon/Coreboot-ThinkPads/wiki/Hardware-...
ty ty
That's true. They don't officially support the Raspberry Pi because it needs proprietary drivers and thus breaks the "chain of trust" needed for flashing Libreboot.
It's a bit over-the-top paronoid to expect firmware modifying software in GPU drivers, but I understand their point.
It's a bit over-the-top paronoid to expect firmware modifying software in GPU drivers, but I understand their point.
To call the binary blobs on the Pi "GPU drivers" is an understatement. The VC4 is running the full ThreadX operating system. The Pi is closer to a VC4 board with a secondary ARM coprocessor tacked on than it is to an ARM board.
[deleted]
Oh wow, I didn't knew this. Will look into this, thanks.
All the same, is your adversary really going to use this to attack your machine? They'd have to predict a number of things quite in advance, as well as sneak an attack into the blob.
Hm, well I have always run it headless. Should be possible to make sure the GPU driver isn't ever loaded.
> The Raspberry Pi boots from its GPU and only non-free software is currently available for the GPU, even starting the machine requires a large (2MB) blob of non-free, unsupportable software
https://wiki.debian.org/RaspberryPi
https://wiki.debian.org/RaspberryPi
Also from that page:
Broadcom publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the VPU firmware blob started in 2016: https://github.com/christinaa/rpi-open-firmware. See more at https://news.ycombinator.com/item?id=11703842
Broadcom publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the VPU firmware blob started in 2016: https://github.com/christinaa/rpi-open-firmware. See more at https://news.ycombinator.com/item?id=11703842
The VC4 GPU actually is the primary chip; it boots the ThreadX operating system on the VC4 first, then ThreadX loads the user-configured system onto the ARM core. Whether you run headless or not, ThreadX is running on the VC4.
I have hope in Risc-V.
I don't have any hope for other hardware. The only hope that I have is that Intel will change their mind and remove it, or make it fully open source.
The sad thing is that ME isn't even developed by Intel, but a third party. They sublicense it to Intel. So even if Intel would be willing to distribute the source, they couln't.
The sad thing is that ME isn't even developed by Intel, but a third party. They sublicense it to Intel. So even if Intel would be willing to distribute the source, they couln't.
AFAIK not even Google could get Intel to share the source code on their chips in order to make some of their Chromebooks. If Google can't do it, I doubt a handful of "GNU extremists" are going to change their minds.
If Intel said, "needs to be open source or we'll find another supplier" then it would become open source.
I think someone has to leak everything, Snowden-style, although with all the increasing "security" that could be a bit difficult... nevertheless, if someone does decide to be a hero and do it, I fully support their efforts.
Unless this leak revealed that the NSA forced Intel and AMD to include ME in their chips to advance their mass spying efforts such a leak would be a crime. Snowden's case is different since he was revealing info that Americans (or their reps) have a right to know. The intelligence agencies are building a mass surveillance infrastructure that is prima facie not compatible with a free country and almost certainly a violation of the constitution. The constitution and amendments do not directly apply to Intel and they are free to do whatever they want and we are free to buy or not to buy as we see fit.
TBH, I think there is a lot of focus on this ME technology and I see no reason that at some point someone is going to crack the model or the encryption and reveal exactly what it is doing and how to disable it.
TBH, I think there is a lot of focus on this ME technology and I see no reason that at some point someone is going to crack the model or the encryption and reveal exactly what it is doing and how to disable it.
It's a shame that we seem locked into using Intel or AMD for x64 processors, both of which have secondary, black-box processors.
Isn't x64 a standard? Couldn't another company create their own implementation of it and design their own processors for the paranoid to use?
Isn't x64 a standard? Couldn't another company create their own implementation of it and design their own processors for the paranoid to use?
There have been rumors (for a while) that VIA is looking to seriously get back in the x64 game. So as far as I'm aware they have yet to attempt anything like Intel ME/AMD PSP.
AMD64 is, as far as I know, not a standard.
Even if it was, being a standard does not mean that it is free, easy and legal for others to implement. Some standard bodies require a patent sharing agreement or licenses being provided for a "reasonable" cost, but what is reasonable is often a topic of discussion.
x86_64 also incorporates a 32-bit compatibility, which is copyright protected by Intel and only a handful of licensees exist, with no new licenses having been signed in the past decade or so. I don't think you can implement AMD64 without also acquiring an x86 license from Intel.
Even if it was, being a standard does not mean that it is free, easy and legal for others to implement. Some standard bodies require a patent sharing agreement or licenses being provided for a "reasonable" cost, but what is reasonable is often a topic of discussion.
x86_64 also incorporates a 32-bit compatibility, which is copyright protected by Intel and only a handful of licensees exist, with no new licenses having been signed in the past decade or so. I don't think you can implement AMD64 without also acquiring an x86 license from Intel.
x86 is an Intel standard; they own the patents. Some of the patents have expired at this point but there's new ones which you would need in order to make a competing x86 processor.
x86_64 is an AMD standard, I believe still under patent.
Intel and AMD cross-license these patents to each other. As a result, any other company wanting to make x86 processors would have to purchase rights from both companies (assuming they're willing to, which is a big if), which would instantly make their products cost-uncompetitive.
x86_64 is an AMD standard, I believe still under patent.
Intel and AMD cross-license these patents to each other. As a result, any other company wanting to make x86 processors would have to purchase rights from both companies (assuming they're willing to, which is a big if), which would instantly make their products cost-uncompetitive.
It's my understanding the only reason they cross-license today is both have big enough patent warchests as to place them in MAD. So it's probably quite unlikely Joe Startup could ever get a license.
x64 is copy righted only AMD, Intel, and VIA have the rights. There are also some patent protections.
x86 is also copyrighted, but it's expired. Most the parents have expired and it's starting to become more common to 486 and 386's in very cheap embedded controllers.
x86 is also copyrighted, but it's expired. Most the parents have expired and it's starting to become more common to 486 and 386's in very cheap embedded controllers.
x86 hasn't been around long enough for a copyright to expire; the only feasible type of protections to expire would be patents. In the US, copyrights last for 120 years after creation of the work or 95 years after the initial publication, whichever is shorter. (Referenced from https://en.wikipedia.org/wiki/Copyright_law_of_the_United_St...)
There is copyright for the masks used to fabricate chips, and those only last 10 years: http://www.copyright.gov/title17/92chap9.html
IMHO, at this level binary compatibility isn't important. Linux could be easily ported to run on any ISA.
The problems are economies of scale and the perfect being the enemy of the good. What is the interest in an expensive custom chip when you still can't trust that it wasn't compromised by the fab?
The problems are economies of scale and the perfect being the enemy of the good. What is the interest in an expensive custom chip when you still can't trust that it wasn't compromised by the fab?
I don't think it will ever be possible to prove that given piece of hardware contains no malware. Still, there is demand for transparency and product that comes with manufacturer's warranty that says "malware not included". People believe this could lead to some good results, such as better hardware and lower probability of bugged computer.
It's theoretically possible, provided you have a small trusted circuit. It's an active research area. The basic idea is to use multiple separate, untrusted chips and have them do multiparty computation, coordinated by the small trusted circuit.
With testing amplification, you can then set an upper bound on the probability that the chip will run a backdoor.
With testing amplification, you can then set an upper bound on the probability that the chip will run a backdoor.
POWER8, OpenSparc, and OpenRISC are all still around. Linux kernel compiles for them all.
You're only locked in if your personal requirements mandate the smallest lithography process and the highest clock speed.
You're only locked in if your personal requirements mandate the smallest lithography process and the highest clock speed.
My personal requirements mandate "a cheap sturdy laptop". Do such things exist for non-X64 architectures? I'm not sure where I would even start to look.
There were a few chromebooks that ran on ARM chips. Not sure about sturdy, but they were definitely cheap. (And, you can enable developer mode and then use whatever flavor of Linux you like.)
Also, the Microsoft Surface RT tablets were ARM and fairly impressive from a hardware standpoint (sturdy, nice screens, etc.) You should be able to get a used one on Swappa fairly cheep. I know there was some credential leak recently, but I'm not sure if that's gone far enough to make it a useful development machine. (Also, it's a tablet with a kickstand and a detachable keyboard...)
Also, the Microsoft Surface RT tablets were ARM and fairly impressive from a hardware standpoint (sturdy, nice screens, etc.) You should be able to get a used one on Swappa fairly cheep. I know there was some credential leak recently, but I'm not sure if that's gone far enough to make it a useful development machine. (Also, it's a tablet with a kickstand and a detachable keyboard...)
There's still a tranche of early 2015 Rockchip Chromebooks, already with Coreboot on them - and you can even put Libreboot on at least some of them:
https://libreboot.org/docs/install/c201.html
https://libreboot.org/docs/install/c201.html
MIPS and ARM laptops exist, or an old Thinkpad X60 with coreboot.
I actually have an X60! But it's 32-bit x86, so these days it mostly collects dust while I use a Thinkpad X301.
Where does one find a MIPS or ARM laptop? Who manufactures them?
Where does one find a MIPS or ARM laptop? Who manufactures them?
ARM laptops exist in the form of various chromebooks. No clue if completely free firmware exists for any of them though.
You would start to look at Novena, but that might not be quite the answer you're looking for.
Novena is great, but it certainly isn't cheap, isn't sturdy, and to be honest, unless you were lucky enough to snag a Senoko battery board, isn't a laptop. (I'm fortunate enough to own a few Novena boards).
> You're only locked in if your personal requirements mandate the smallest lithography process and the highest clock speed.
I'm pretty sure POWER still fulfills requirements for "highest clock speed", not x86/x64. That might be based on outdated information, though; I just recall POWER being the first to hit 5GHz CPU clock speeds even in spite of IBM's lithographic processes lagging behind Intel's.
I'm pretty sure POWER still fulfills requirements for "highest clock speed", not x86/x64. That might be based on outdated information, though; I just recall POWER being the first to hit 5GHz CPU clock speeds even in spite of IBM's lithographic processes lagging behind Intel's.
Interesting that the ME region can be even partially overwritten and will still let the system boot, albeit with an error (guessing a checksum mismatch)...
Ah ... reading further down the thread its explained and is even more interesting: https://www.coreboot.org/pipermail/coreboot/2016-September/0...
> along with the fact that the ME will sync it's internal clock with NTP servers across the internet once every 30 days
Wow. This is part of the processor?
Wow. This is part of the processor?
The Management Engine, think of it as running at Ring -1. It can access hardware below the level of the processor. Injecting malware into it would be the holy grail for attackers, it would be impossible for anything running on the CPU to detect it and the malware would have access to all of the low level hardware. It can even intercept or create packets on the network interfaces.
Luckily the implementation is obscure so it has perfect security, right? There's no way such a complex piece of software that has had very little oversight could have exploitable bugs that would completely destroy any security foundations you have on your machine.
Luckily the implementation is obscure so it has perfect security, right? There's no way such a complex piece of software that has had very little oversight could have exploitable bugs that would completely destroy any security foundations you have on your machine.
> It can even intercept or create packets on the network interfaces.
And appears to be built to do so out of the box by default with no "specialized code". I'm guessing with both wired and wireless interfaces... crazy!
And appears to be built to do so out of the box by default with no "specialized code". I'm guessing with both wired and wireless interfaces... crazy!
[deleted]
My next question is (and it's probably mentioned further in the thread or manual somewhere): how does the ME chipset route traffic to the Internet in the first place? Piggyback off the OS? Does this mean it's directly coupled with the networking devices on the system somehow? Presumably it will work with any OS....
AMT requires Intel NICs for that reason.
So could you neutralize its communication functions (to a degree) by using a non-Intel NIC? Would a non-chipset Intel NIC accomplish the same thing?
but it still needs and IP address right? Does ME does its own DHCP/BOOTP configuration or does it rely on some other protocol specific to Intel NICs/Intel infrastructure?
The AMT component must be specifically configured with network information. It is usually kept on a different interface from that used by the OS for security reasons.
"chipset" I think.
Can someone describe what a "ME Region" is?
This has an editorial point of view, for sure, but it's also an approachable introduction:
http://boingboing.net/2016/06/15/intel-x86-processors-ship-w...
http://boingboing.net/2016/06/15/intel-x86-processors-ship-w...
The region of the "bios" flash chip which stores the code for the Intel Management Engine.
[deleted]
where ME is stored I think.
Does someone have a link to where I can download a few copies of different ME regions for some CPUs.
I'd love to get a look at what it's doing.
I'd love to get a look at what it's doing.
"The ME code to start the platform is in (on-chip) ROM and a failed
signature check of the (compressed with AFAIK still unknown codebook)
ME code in flash just means that the ME considers the system broken
and allows it to run for a little while so that a human can repair it."
So 1) will the system stay up with the ME software erased, 2) what's the ROM component doing besides managing the boot, and 3) what access does it take to alter the ME's firmware?
So 1) will the system stay up with the ME software erased, 2) what's the ROM component doing besides managing the boot, and 3) what access does it take to alter the ME's firmware?
The ME firmware is signed by Intel I think.
So compromise their signing keys and we have a wide-open door to neutralizing (and/or replacing) ME, right?
I am fascinated by this - is there no where that is leading the charge to develop personal computing devices that are truly open? What cost level are we really talking here?
There are some places that are trying to do fully open source hardware, but because the majority of the public doesn't care (they just want their computer to work), nothing big has come out yet.
First you have to build a Fab that you trust. Then build an assembly line that you trust. Then make sure these don't have any humans in them, since humans are not trustworthy.
Not to be pedantic, but the x230 has an ivybridge chip.
That's pretty crazy to think there's a sub-ring-0 rootkit running on your CPU contacting NTP servers without your knowledge.
Does that work over wifi (where does it get the WPA password from)?
Where does it get an IP address? Does it leech off the host's DHCP IP by intercepting ethernet packets?
Is there any way to fingerprint the traffic? TTLs, sequence numbers, etc?
It'd be interesting to run a system behind a router for a while while logging all ME traffic...