If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
"Replacing x86 firmware with Linux and Go"
"Replacing x86 firmware with Linux and Go"
http://www.osnews.com/comments/30097 "The Intel Management Engine (ME), which is a separate processor and operating system running outside of user control on most x86 systems, has long been of concern to users who are security and privacy conscious. Google and others have been working on ways to eliminate as much of that functionality as possible (while still being able to boot and run the system). Ronald Minnich from Google came to Prague to talk about those efforts at the 2017 Embedded Linux Conference Europe." https://lwn.net/SubscriberLink/738649/81007748bf15c1e5/ I am not understanding the repercussions of this yet. But, it looks serious, very serious. Lynn |
#2
|
|||
|
|||
"Replacing x86 firmware with Linux and Go"
Lynn McGuire wrote:
"Replacing x86 firmware with Linux and Go" http://www.osnews.com/comments/30097 "The Intel Management Engine (ME), which is a separate processor and operating system running outside of user control on most x86 systems, has long been of concern to users who are security and privacy conscious. Google and others have been working on ways to eliminate as much of that functionality as possible (while still being able to boot and run the system). Ronald Minnich from Google came to Prague to talk about those efforts at the 2017 Embedded Linux Conference Europe." https://lwn.net/SubscriberLink/738649/81007748bf15c1e5/ I am not understanding the repercussions of this yet. But, it looks serious, very serious. https://en.wikipedia.org/wiki/Intel_Management_Engine Twould be useful if they actually listed the affected chipsets (well, the Intel CVE article gives details by OEM brand). Sounds like something Intel would've incorporated with UEFI, not in the old BIOS config. "Since 2008" isn't clear which chipsets have IME. https://www.eff.org/deeplinks/2017/0...way-disable-it The BIOS in my ancient desktop home PC is so limited in settings (it's a salvaged Acer) that there would be no settings regarding AMT. Acer is so terse in their documentation on the mobo that they don't even have a section for BIOS settings. The EFF article mentions the following tool: https://github.com/corna/me_cleaner but with the warning that it could brick the computer. This program acts like a firmware update: it will burn different code into the EEPROMS, so you are trusting an unknown source to change the firmware in your BIOS/UEFI. According to: https://en.wikipedia.org/wiki/Nehale...roarchitecture) "the first processor released with the Nehalem architecture was the desktop Core i7, which was released in November 2008." Well, I'm still back on an old Intel Core 2 quad-core processor. It's G45 chipset (Intel 4-series chipset family) was introduced in 2008. Haven't found a block diagram of the G45 chip showing the IME but it seems that was a somewhat hidden function. Seems AMT targeted business- class deployments. https://communities.intel.com/thread/108479 A respondent there claims G45 does not have AMT but I haven't independently verified their claim. The respondent said it is the "Q" chipset class you have to watch out for. When looking at getting a new mobo, it's the "Z" chipset class that I look for. You'll have to research the chipset on your mobo to see if it has AMT. The chipset might support AMT but that doesn't mean it was enabled on the mobo you have. Have support for a function doesn't mean it got implemented. https://en.wikipedia.org/wiki/Intel_vPro Good luck contacting the maker of your mobo for details regarding AMT in the model you bought. Too bad the author of me_cleaner didn't instead write a reduced program that merely checked if AMT was available. Intel is not ignoring the problem of AMT vulnerabilities; see: https://security-center.intel.com/ad...nguageid=en-fr which notes "This vulnerability does not exist on Intel-based consumer PCs with consumer firmware, ..." So the nightmare seems limited to corporate customers using vPro hardware (and possible with the "Q" chipsets). The Intel article gives a list of PC makers and the articles there regarding AMT vulnerability. In the Acer article, it looks like the BIOS version in my mobo is much older than what Acer lists as susceptible, but that's me guessing "P01-A2" precedes versions 6.x and up. The Acer article lists the susceptible models. Mine isn't listed. Acer provides a firmware update for the models listed. Looks like you use their firmware update along with Intel's AMT Unprovisioning tool: https://downloadcenter.intel.com/download/26781 All these fixes are altering firmware. Since I'm not in the lists, I'm not farking over my desktop just to feel safer. EFF's "letter" was published on May 8, 2017. Intel's CVE notice and working with PC makers for firmware changes was May 1, 2017. The datestamps are too close to tell if EFF didn't notice Intel's announcement or if EFF didn't publish until a few days late. |
#3
|
|||
|
|||
"Replacing x86 firmware with Linux and Go"
Lynn McGuire wrote:
"Replacing x86 firmware with Linux and Go" http://www.osnews.com/comments/30097 "The Intel Management Engine (ME), which is a separate processor and operating system running outside of user control on most x86 systems, has long been of concern to users who are security and privacy conscious. Google and others have been working on ways to eliminate as much of that functionality as possible (while still being able to boot and run the system). Ronald Minnich from Google came to Prague to talk about those efforts at the 2017 Embedded Linux Conference Europe." https://lwn.net/SubscriberLink/738649/81007748bf15c1e5/ I am not understanding the repercussions of this yet. But, it looks serious, very serious. Lynn Well, this has been going on for some time, and you should have some idea by now what's going on. It's been around for ten years. While the idea of NERF for firmware is good, the most important aspect is "If you completely remove the ME, your node probably will not boot, but NERF has taken away the ME's web server and IP stacks." It means, since somewhere around 2007, that your BIOS chip has at least (the possibility of...) +----------------------+ | ME firmware | --- Added, Intel platform, since 2007. | | Runs in Southbridge/PCH microcontroller. } } Loads in "stolen RAM". +----------------------+ | Main BIOS code | ---+ Prior to 2007, only these | | | two worked together to handle +----------------------+ | POST and the BIOS setup screen. | 8KB BIOS boot loader | ----+ | (checksums "Main") | +----------------------+ And the thing is, the ME firmware cannot be fully nullified. Because there is a microcontroller in your chipset, it has to be put in a safe state. And completely removing the ME firmware, the ME firmware is likely protected by its own watchdog timer which would cause the (non-existent) ME code to reload. To make the firmware load at least a bit "sane", there's always going to be a binary blob sitting in the ME slot. We don't want that subsystem "flapping in the breeze". The ME firmware will have to write to its own watchdog timer "every once in a while", to stop the ME from reloading. There will be a loop of code that minimally has to continue running in the ME. The safest state we can leave it in, will include a code loop, but with the comm stacks removed. I know how engineers think, so I can easily guess as to how the land mines were planted. The engineers who designed this were self-absorbed individuals, which is why there's a watchdog timer and armaments for the ME. They didn't intend us to stop it by inserting or removing a jumper, and consequently, we would expect stiff opposition inside the chip, to removing its effects entirely. The ME needs to implement a "high availability platform", and it would not be good P.R. if an IT guy tried to reset an ME platform box remotely from home, and could not reach it because the ME had crashed as well. That's why there is a watchdog in there. This means a minimal set of instructions must be in the ME. The firmware that Asus ships, won't have the "smallest possible" ME code in it, in non-VPro products. And I proved this just two days ago, when the damn Intel utility printed out a release number for my "ME firmware", proving communications were taking place! On a platform that "doesn't support ME" via branding (no VPro printed on the box top). I wouldn't have bought the motherboard, if VPro was printed on the box. NERF is like Coreboot though - it's not like it's going to be easy to retrofit all the hardware, or offer people a "nullified' firmware they can install at home. If you want to do this, you'll have to be a Level 37 Rocket Scientist. Intel will not be paying the motherboard companies any compensation for the mess this "security by obscurity" approach is causing. Motherboard companies will not ship "fixed" firmwares, just because Intel "burps". So while Intel can release these security bulletins, the actual uptake of fixes to the security flaws, is going to be close to zero. Intel must have known this, when they came up with this *stupid* idea back in 2007. There are so many firmwares to fix, some companies will need to hire more employees to keep up. Someone has to pay. And the motherboard companies didn't invent this scheme. Intel did, and they put it in way more platforms than they should have. And I don't understand why the AMD P.R. department isn't having a field day with this. Yet, no slideware promoting AMD. Very strange. Paul |
#4
|
|||
|
|||
"Replacing x86 firmware with Linux and Go"
On 11/26/2017 9:09 PM, Paul wrote:
Lynn McGuire wrote: "Replacing x86 firmware with Linux and Go" Â*Â*Â* http://www.osnews.com/comments/30097 "The Intel Management Engine (ME), which is a separate processor and operating system running outside of user control on most x86 systems, has long been of concern to users who are security and privacy conscious. Google and others have been working on ways to eliminate as much of that functionality as possible (while still being able to boot and run the system). Ronald Minnich from Google came to Prague to talk about those efforts at the 2017 Embedded Linux Conference Europe." Â*Â* https://lwn.net/SubscriberLink/738649/81007748bf15c1e5/ I am not understanding the repercussions of this yet.Â* But, it looks serious, very serious. Lynn Well, this has been going on for some time, and you should have some idea by now what's going on. It's been around for ten years. While the idea of NERF for firmware is good, the most important aspect is Â*Â* "If you completely remove the ME, your node probably Â*Â*Â* will not boot, but NERF has taken away the Â*Â*Â* ME's web server and IP stacks." It means, since somewhere around 2007, that your BIOS chip has at least (the possibility of...) Â*Â*Â* +----------------------+ Â*Â*Â* | ME firmwareÂ*Â*Â*Â*Â*Â*Â*Â*Â* | --- Added, Intel platform, since 2007. Â*Â*Â* |Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* |Â*Â*Â*Â*Â* Runs in Southbridge/PCH microcontroller. Â*Â*Â* }Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* }Â*Â*Â*Â*Â* Loads in "stolen RAM". Â*Â*Â* +----------------------+ Â*Â*Â* | Main BIOS codeÂ*Â*Â*Â*Â*Â* | ---+ Prior to 2007, only these Â*Â*Â* |Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* |Â*Â*Â*Â* | two worked together to handle Â*Â*Â* +----------------------+Â*Â*Â*Â* | POST and the BIOS setup screen. Â*Â*Â* | 8KB BIOS boot loader | ----+ Â*Â*Â* | (checksums "Main")Â*Â* | Â*Â*Â* +----------------------+ And the thing is, the ME firmware cannot be fully nullified. Because there is a microcontroller in your chipset, it has to be put in a safe state. And completely removing the ME firmware, the ME firmware is likely protected by its own watchdog timer which would cause the (non-existent) ME code to reload. To make the firmware load at least a bit "sane", there's always going to be a binary blob sitting in the ME slot. We don't want that subsystem "flapping in the breeze". The ME firmware will have to write to its own watchdog timer "every once in a while", to stop the ME from reloading. There will be a loop of code that minimally has to continue running in the ME. The safest state we can leave it in, will include a code loop, but with the comm stacks removed. I know how engineers think, so I can easily guess as to how the land mines were planted. The engineers who designed this were self-absorbed individuals, which is why there's a watchdog timer and armaments for the ME. They didn't intend us to stop it by inserting or removing a jumper, and consequently, we would expect stiff opposition inside the chip, to removing its effects entirely. The ME needs to implement a "high availability platform", and it would not be good P.R. if an IT guy tried to reset an ME platform box remotely from home, and could not reach it because the ME had crashed as well. That's why there is a watchdog in there. This means a minimal set of instructions must be in the ME. The firmware that Asus ships, won't have the "smallest possible" ME code in it, in non-VPro products. And I proved this just two days ago, when the damn Intel utility printed out a release number for my "ME firmware", proving communications were taking place! On a platform that "doesn't support ME" via branding (no VPro printed on the box top). I wouldn't have bought the motherboard, if VPro was printed on the box. NERF is like Coreboot though - it's not like it's going to be easy to retrofit all the hardware, or offer people a "nullified' firmware they can install at home. If you want to do this, you'll have to be a Level 37 Rocket Scientist. Intel will not be paying the motherboard companies any compensation for the mess this "security by obscurity" approach is causing. Motherboard companies will not ship "fixed" firmwares, just because Intel "burps". So while Intel can release these security bulletins, the actual uptake of fixes to the security flaws, is going to be close to zero. Intel must have known this, when they came up with this *stupid* idea back in 2007. There are so many firmwares to fix, some companies will need to hire more employees to keep up. Someone has to pay. And the motherboard companies didn't invent this scheme. Intel did, and they put it in way more platforms than they should have. And I don't understand why the AMD P.R. department isn't having a field day with this. Yet, no slideware promoting AMD. Very strange. Â*Â* Paul My conspiracy theorist son thinks that the CIA paid Intel to put the ME in to give them a backdoor. He has a total disgust for the CIA since his involvement with them in Iraq (he is former USMC). I suspect that AMD has their own version of the ME that has not been found yet. Lynn |
#5
|
|||
|
|||
"Replacing x86 firmware with Linux and Go"
Lynn McGuire wrote:
My conspiracy theorist son thinks that the CIA paid Intel to put the ME in to give them a backdoor. He has a total disgust for the CIA since his involvement with them in Iraq (he is former USMC). I suspect that AMD has their own version of the ME that has not been found yet. Lynn If AMD has a capability, they're being pretty quiet about it. They have a security processor inside their newer processors, which is an ARM in an x86 main processor. But that by itself isn't enough to build a really great back door. That might be enough to do some TPM functions, verify the BIOS hasn't been tampered with. But when it comes time to remote in, what plumbing is there to help the remote-in ? I haven't seen any evidence of "plumbing" on the AMD platform, a dedicated hardware path like Intel has set up. Sure, you can simply share all the regular system resources, but that makes it harder to do (could mean custom firmware, meaning poor central control of the uniformity of the feature set). How would two processors handle the interrupt handler for the NIC, if the NIC has a single head and no filter table, identifying packets destined for each processor ? And you can't make a tiny security processor "gate" all the incoming and outgoing traffic, as people might notice :-) The AMD security processor might have a higher MIPS rating than the Intel one, but I'm not convinced you wouldn't notice. It would mean messing with the interrupt table, preventing the main processor from seeing the real NIC. A mess. And AMD boards probably have RealTek NICs on them. Paul |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
"Parts need replacing message" on an Epson D68 | Brian Watson | Printers | 10 | June 13th 08 02:07 PM |
Replacing eIDE Boot drive with SATA - OS setup says "NTLDR is Missing" BIOS issues? | tenor20 | Dell Computers | 8 | August 4th 07 06:41 AM |
Firmware version is still shown "same" after successful update? | kimiraikkonen | Storage (alternative) | 2 | July 31st 07 05:08 AM |
Replacing "Nvidia Geforce4 MX 440" videocard Fan | Planky | Nvidia Videocards | 5 | July 30th 07 09:18 PM |
Western Digital "My Book" - Replacing the hard drive | [email protected] | Storage (alternative) | 0 | July 8th 06 06:31 PM |