Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

hardenedlinux.org

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#51

Post by ackalker »

tedunangst wrote: post #48
devereaux wrote: post #34

Earlier quoted context omitted.

There is a device visible on the PCI bus. How hard is it to imagine that userland programs could somehow pass requests to that device, and have the ME do bad things to the CPU or the RAM? How hard is it to imagine some special string in RAM could trigger the ME in a similar way? (so many CPU instructions - I would be surprised if there wasn't one to talk to the ME) Exploits and vulnerability are mitigated by proper a…

If userland processes are passing unauthorized commands to PCI devices, you have bigger problems.

They're called proprietary video drivers, and yes, they pass unknown commands, without user authorization (think DRM) to PCI(e) devices (video cards) all the time.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#52

Post by PeCaN »

Puts wrote: post #26

What happened to VIA and their x86 CPUs and mini-itx platform people used to build media PCs on? Wouldn't that be a viable option if you really want to avoid ME?

VIA is still around. They announced a new core with AVX2 support, Isaiah II, around late 2014 but it appears their x86_64 license will run out before it actually gets produced. The situation is really unclear. In 2010 they got a 6-year license extension thanks to the FTC, so it's possible VIA can't actually produce x86 CPUs anymore.

VIA is 100% a viable option—they support SSE 4.1, run Windows 10, and their integrated GPUs even run DirectX11 natively¹—except that they compete with Atom, not desktop or even regular laptop CPUs. However, the current (40nm Isaiah) “high-end” VIA microarchitecture is a out-of-order, 3-fetch 7-dispatch wide² superscalar, fully pipelined core. So it should outperform a modern Atom by a decent margin, with only slightly higher power consumption.

Apparently VIA is still fairly popular in China (and by virtue of being a Taiwanese company, possibly Japan as well).

1. See e.g. http://www.viatech.com/en/boards/mini-itx/epia-m920/

2. http://arstechnica.com/gadgets/2008/01/via-cpu-isaiah/2/

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#53

Post by dispose13432 »

BuuQu9hu wrote: post #50
dispose13432 wrote: post #41

Earlier quoted context omitted.

RISC-V is Open Source. Will the RISC-V based CPU in your computer be Open Source? A parallel example is while WebKit is Open Source Chrome isn't

Correction: RISC-V is an Open Standard. Of course there will be both proprietary and open implementations of RISC-V.

So what are the chances that you'll be able to get an open standard RISC?

Unlike software, you can't just download the code, you have to pay for a fab

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#54

Post by thesrcmustflow »

feld wrote: post #31
dsp1234 wrote: post #10

Earlier quoted context omitted.

Note that it looks like they may not make their goal. It ends on Dec 15th, and they only have about 10% raised ($344,310 raised of $3,700,000 goal)

It's only 32bit. This is not something I'm interested in funding. If it was 64bit or the 128bit version of RISC-V it would be more alluring.

Where did you read that? The TALOS machine uses POWER8 which is 64 bit. EDIT: Ah right there are two different links above

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#55

Post by persmule »

mmastrac wrote: post #23
sounds wrote: post #14

Earlier quoted context omitted.

The phrasing there is confusing. Does the NIC break because the ME is neutralized? Then rebooting again with the ME neutralized will break the NIC again. Why would the NIC only break once after the ME is neutralized? The system is started from a fully powered-off state after the ME firmware is updated. Maybe the NIC has some sort of non-volatile state that gets updated when the ME fails to initialize, and then the NI…

This was confusing to me as well. I'm parsing this as the NIC doesn't work after a cold boot, but does after a warm boot.

Your interpretation is correct. I am going to fix this ambiguity.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#56

Post by userbinator »

phantom_oracle wrote: post #19

Has Intel ever commented about this issue of removing ME? Surely, at least 1 Intel staffer reads HN and they must have discussed this internally. Unless they just brush this off as negligible (a couple thousand paranoid/"extremist" users) ?

I have a feeling Intel is more likely going to consider this a "vulnerability" and try to close it off in the next revision...

Anyone who works there, has access to the required information, and is unhappy at the situation surrounding ME and other freedom-hostile directions your company is taking, you know what to do!

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#57

Post by jdub »

feld wrote: post #31
dsp1234 wrote: post #10

Earlier quoted context omitted.

Note that it looks like they may not make their goal. It ends on Dec 15th, and they only have about 10% raised ($344,310 raised of $3,700,000 goal)

It's only 32bit. This is not something I'm interested in funding. If it was 64bit or the 128bit version of RISC-V it would be more alluring.

It's a microcontroller. Think ARM Cortex-M0.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#58

Post by jtl999 »

devereaux wrote: post #34
wmf wrote: post #27

Earlier quoted context omitted.

Their discussion may have consisted of "too bad these extremists don't realize that the ME is harmless if you don't have an Intel NIC".

There is a device visible on the PCI bus. How hard is it to imagine that userland programs could somehow pass requests to that device, and have the ME do bad things to the CPU or the RAM? How hard is it to imagine some special string in RAM could trigger the ME in a similar way? (so many CPU instructions - I would be surprised if there wasn't one to talk to the ME) Exploits and vulnerability are mitigated by proper a…

How does a userland process communicate with a PCI device?

Asking for a project.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#59

Post by twr »

I succeeded at doing this to an old Asus Z68 motherboard. Steps:

  flashrom -p internal -r bios.rom
  ifdtool -x bios.rom
  python3 me_cleaner.py flashregion_2_intel_me.bin
  python2 dump_me.py flashregion_2_intel_me.bin -x
  python2 me_sigcheck.py FTPR_part.bin
  ifdtool -i ME:flashregion_2_intel_me.bin bios.rom
  exit # Skip this line if you're okay with bricking your motherboard.
  flashrom -p internal -w bios.rom.new
`lspci | grep -i mei` and `lsmod | grep mei` are now empty.

intelmetool:

  ME: FW Partition Table      : OK
  ME: Bringup Loader Failure  : NO
  ME: Firmware Init Complete  : NO
  ME: Manufacturing Mode      : NO
  ME: Boot Options Present    : NO
  ME: Update In Progress      : NO
  ME: Current Working State   : Initializing
  ME: Current Operation State : Bring up
  ME: Current Operation Mode  : Normal
  ME: Error Code              : Debug Failure
  ME: Progress Phase          : BUP Phase
  ME: Power Management Event  : Pseudo-global reset
  ME: Progress Phase State    : 0x3b
  ...
  ME has a broken implementation on your board with this BIOS
  ME: failed to become ready
It took a hard reset to re-enable integrated ethernet.

Awesome!

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#60

Post by lallysingh »

ackalker wrote: post #51
tedunangst wrote: post #48

Earlier quoted context omitted.

If userland processes are passing unauthorized commands to PCI devices, you have bigger problems.

They're called proprietary video drivers, and yes, they pass unknown commands, without user authorization (think DRM) to PCI(e) devices (video cards) all the time.

If you're running highly privileged binary blob drivers, is ME really the attack vector you should be worried about?
Post reply on HN