A computer components & hardware forum. HardwareBanter

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.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » Homebuilt PC's
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

"Replacing x86 firmware with Linux and Go"



 
 
Thread Tools Display Modes
  #1  
Old November 27th 17, 02:08 AM posted to alt.comp.hardware.pc-homebuilt
Lynn McGuire[_3_]
external usenet poster
 
Posts: 198
Default "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  
Old November 27th 17, 03:41 AM posted to alt.comp.hardware.pc-homebuilt
VanguardLH[_2_]
external usenet poster
 
Posts: 1,453
Default "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  
Old November 27th 17, 04:09 AM posted to alt.comp.hardware.pc-homebuilt
Paul[_28_]
external usenet poster
 
Posts: 1,467
Default "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  
Old November 27th 17, 10:05 PM posted to alt.comp.hardware.pc-homebuilt
Lynn McGuire[_3_]
external usenet poster
 
Posts: 198
Default "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  
Old November 28th 17, 02:29 AM posted to alt.comp.hardware.pc-homebuilt
Paul[_28_]
external usenet poster
 
Posts: 1,467
Default "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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT +1. The time now is 12:12 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.