[HN Gopher] System76's coreboot open firmware manages to disable...
___________________________________________________________________
System76's coreboot open firmware manages to disable Intel ME for
Raptor Lake
Author : airhangerf15
Score : 232 points
Date : 2023-06-02 15:41 UTC (7 hours ago)
(HTM) web link (blog.system76.com)
(TXT) w3m dump (blog.system76.com)
| BiteCode_dev wrote:
| Disabling the biggest malware of all time is amazing. System76 is
| getting quite attractive.
| jmclnx wrote:
| Same here, all I would need is 2 more things
|
| 1. A trackpoint similar to what Thinkpads have and the ability
| to disable the touchpad.
|
| 2. No Nvidia GPU, but full opensource GPU. I think that is
| already an option for some models. This is so I could use
| OpenBSD with it.
|
| But if I every get a new laptop, I will look directly at System
| 76.
| mPReDiToR wrote:
| I hope someone proofreads that article before it's published to
| the Interwebs!
| Kim_Bruning wrote:
| Rather than going by hearsay I thought I'd just look up the Intel
| ME documentation. Unfortunately I can't seem to find much on the
| Intel site. Where would full documentation of this system be
| found, am I looking in the right place?
| wmf wrote:
| Look at AMT documentation.
| neilv wrote:
| I'm hoping some RISC-V system developer will take the opportunity
| _not_ to embed a mess like the Intel ME.
| rwaksmunski wrote:
| I lost my hope when they adopted UEFI.
| jonas-w wrote:
| Could you elaborate what the problem with UEFI is and what
| the alternatives are? Genuine question, as I've never heard
| this sentiment before.
| egberts1 wrote:
| It is simple: the mere fact of adding network support at
| BIOS level remains problematic.
|
| And we are not talking about TFTP, but DHCP and NTP (not to
| mention even more problematic HTTP[S]) which clearly does
| not belong at BIOS and should not be at UEFI level.
| neilv wrote:
| I've heard many complaints about UEFI. Personally, I don't
| like the complexity, and I distrust some of the parties
| involved.
| thatguyman wrote:
| SiFive (the biggest RISC-V developer) has already partnered
| with Intel: https://www.sifive.com/blog/sifive-made-a-splash-
| at-the-risc...
|
| Quote: "As part of our efforts to build out the RISC-V
| ecosystem, SiFive has partnered with Intel to develop the
| HiFive Pro P550 Development System (previously code-named Horse
| Creek). During his keynote, Patrick was joined on stage by
| Intel Foundry Services' Bob Brennan to share a first look at
| this high performance platform that features a quad-core SiFive
| Performance(tm) P550 processor and is implemented in the Intel
| 4 technology platform. The board will enable a new generation
| of RISC-V software, continuing the tradition of SiFive HiFive
| boards that have helped drive the growth of the RISC-V
| ecosystem. The board will be commercially available in the
| summer of 2023."
| jsiepkes wrote:
| I recently found out (and was quite surprised) that certain HP
| models also have an option in the UEFI to disable Intel ME.
|
| I posted some pictures of it and pictures of the Intel tool
| confirming it can't connect with ME when disabled:
|
| https://mastodon.social/@JasperSiepkes/110221669827027710
| bri3d wrote:
| Note that this wasn't so much about figuring out how to disable
| Intel ME, which is accomplished by sending an HECI (Host Embedded
| Controller Interface) command in the same way it has been for
| ages.
|
| Rather, this was about fixing a buffer management bug in Coreboot
| which prevented S3 sleep from working with secure boot enabled
| (basically, coreboot would clobber itself with the TPM log on
| wake). This bug required System76 to switch to S0ix suspend and
| in turn, the ME to be re-enabled (as the ME manages some
| peripherals in S0ix sleep).
| nailer wrote:
| > how to disable Intel ME, which is accomplished by sending an
| HECI (Host Embedded Controller Interface) command in the same
| way it has been for ages.
|
| I didn't know this - so it's possible to turn off Intel ME? The
| idea of a full copy of Minix with TCPIP running on my machine
| is scary. Can someone else turn it back on?
| als0 wrote:
| Alternatively, you can set the HAP bit in the BIOS flash
| https://hackaday.com/tag/hap-bit/
| gnu8 wrote:
| I would like to know how the ME shares the NIC with the user
| OS on these systems. Do they have a completely separate
| interface that somehow uses the same physical port? Do the
| drivers from the two operating systems cooperate? Do they
| have one MAC address or two? What happens if the user
| installs a PCI NIC and doesn't plug in the onboard interface?
| mjg59 wrote:
| The hardware has the ability to tag packets with certain
| contents - this is used for more interesting Wake-on-LAN
| policies (eg, rather than requiring a magic packet, you
| could have a web server that aggressively suspends and then
| gets automatically woken when there's an incoming packet to
| port 80 or 443). In the AMT case, it identifies incoming
| packets that are aimed at the AMT ports and passes those
| off to the ME rather than the OS. If you want to speak to
| AMT from the host OS, you install an app that listens to
| those ports on localhost and then tunnels the traffic
| through the HECI interface instead. There's only one IP
| address and one MAC address, and it's limited to built-in
| Intel NICs.
| wmf wrote:
| It definitely only works with certain Intel NICs. It
| doesn't require OS cooperation because the main purpose of
| AMT is to recover a broken OS. I think the NIC effectively
| has two host interfaces so that one can be used by the OS
| and the other can be used by the ME. Due to network
| authentication and such I think the same IP and MAC address
| is shared by the OS and AMT which is of course a rampant
| layering violation.
| yomlica8 wrote:
| > It definitely only works with certain Intel NICs.
|
| Not really doubting you as that kind of stands to reason
| to me, but is there any proof of this? The whole thing
| seems opaque.
| MobiusHorizons wrote:
| I think the general idea is that the purpose of having
| networking in the ME is to enable certain features, which
| are documented to only work with certain Intel NICs. Of
| course if you are paranoid, you would not trust this to
| stop a determined attacker.
| mixmastamyk wrote:
| Will it have access to a wifi card? Only Intel?
| wmf wrote:
| Yes, AMT works over Intel WiFi.
| gnu8 wrote:
| Raising yet more questions about how AMT participates in
| enterprise WiFi authentication schemes. My laptop at work
| has a computer certificate which works for the OS, but
| how does AMT have credentials or even know which SSID to
| associate with?
| bri3d wrote:
| This is all available in the Intel AMT documentation.
| While the implementation is closed-source and opaque,
| this isn't some magic functionality, it's a product that
| businesses want and use.
|
| If the OS is running, wireless AMT forwards packets
| through the OS driver; it's cooperative (unlike the wired
| AMT, which always exists at a higher level than the OS,
| because it has features like resetting a crashed OS).
|
| If the OS isn't running, you provision the AMT with WiFi
| credentials for the AMT host, using a tool. If you want,
| you can use the Local Manageability Service (LMS) tool to
| automatically forward credentials from the OS to the AMT,
| otherwise, you can install specific profiles.
| blacklion wrote:
| I have bitter memories about AMT and all this "remote
| management by Intel" from the old days.
|
| When I'd built my first home server/NAS I wanted remote
| control but I didn't want to pay for hardware with real
| IPMI/iLO/..., so I choose desktop motherboard from Intel
| with Q35 chipset (it was time when Z45/Q45 was cutting
| edge and 35th series was previous generation). NIC was
| Intel's one too, I think it was legendary PRO/100, not 1G
| yet.
|
| I was VERY disappointed to discover, that I didn't get
| remote console and/or remote serial port with ME/AMT at
| all, that it i not true AMT in desktop motherboards, even
| with Q chipset.
| tenebrisalietum wrote:
| > The idea of a full copy of Minix with TCPIP running on my
| machine is scary.
|
| Well...
|
| - I don't think the ME knows how to talk to non Intel NICs
| (install a Realtek or Broadcom based NIC).
|
| Some searching I just did regarding "AMT" (remote management
| feature that uses the ME) says it needs an Intel NIC.
|
| And, some searching I just did regarding vPro (not 100% sure
| what this is exactly) says vPro uses the onboard network
| adapter.
|
| - So I don't think the ME will look for a NIC on the PCIe bus
| at all, but not 100% sure.
|
| - I'm fairly sure AMT/vPro/the ME doesn't know how to talk to
| anything other than stuff on the PCIe bus (use a USB NIC)
|
| - The NIC the ME would use has a MAC like any other NIC.
| Should be information available from the firmware. Just block
| it at the router.
| bri3d wrote:
| Yes. There are several ways, depending heavily on the
| version, and ranging from most trustworthy to least
| trustworthy:
|
| * By patching the ME firmware itself - see the me_cleaner
| project, and methods documented here:
| https://puri.sm/posts/deep-dive-into-intel-me-disablement/ .
| This is Pretty Reliable; the runtime code has been deleted
| from flash.
|
| * By setting a bit in the flash configuration, assumed to be
| added for the US High Assurance program:
| https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-
| bi... , https://www.ptsecurity.com/ww-en/analytics/disabling-
| intel-m... . This is Mostly Reliable; the mechanism has been
| fairly aggressively reverse engineered and was added for a
| program with strict requirements.
|
| * By sending an HECI command that says "hey ME, turn off your
| runtime" https://review.coreboot.org/c/coreboot/+/52800 .
| This is Somewhat Reliable; the method is well understood and
| seems to work but I'm not sure someone has done a deep dive
| audit into whether it could be re-enabled somehow.
| jimbob45 wrote:
| Do we have anything equivalent for AMD's PSP?
| bri3d wrote:
| The equivalent of Option 3, send a supported command that
| tells the runtime capabilities to shut down, has been
| provided as a user-selectable option by AMD in AGESA (the
| unified AMD BIOS/EFI package) for several years now.
|
| I haven't found anyone who has actually reversed the
| functionality to audit what it's doing, though.
| jacooper wrote:
| This is probably going to change when AMD switches from
| AGESA openSIL, fully open firmware.
| jacquesm wrote:
| In a way this is all insane: we are spending a fortune on
| security globally but at the same time manufacturers get
| to insert massive backdoors into the hardware and hardly
| anybody bats an eye.
| charcircuit wrote:
| >manufacturers get to insert massive backdoors into the
| hardware
|
| There is no proof that they are
|
| >hardly anybody bats an eye.
|
| Because only a certain niche of paranoid people are
| willing to believe that companies are trying to make
| their systems intentionally insecure so that you can be
| personally hacked.
| anonymousiam wrote:
| It's a fact that NSA solicits companies to add security
| weaknesses to their products. They'll "make an offer you
| can't refuse" by offering cash (in the form of a
| contract), and they'll use their influence with other
| "contractors" and government agencies to punish companies
| that don't participate.
|
| This is not unique to NSA. Security agencies within other
| governments play the same games with supply chains.
| feanaro wrote:
| It most certainly doesn't have to be intentionally
| insecure but it almost definitely is accidentally so.
| There should be no OS nor network stack running in the
| firmware, period.
| fsflover wrote:
| User-respecting OS running in the firmware can be really
| useful. It must be FLOSS though. Example:
| https://puri.sm/posts/pureboots-powerful-recovery-
| console/.
| wmf wrote:
| What if... ME/PSP are actually very low security risk
| relative to everything else in the system.
| dboat wrote:
| It's troubling to have even a potentially very low
| security risk in hardware I paid for being beyond my
| reach to resolve.
| hlandau wrote:
| This does not "disable" Intel ME. The ME is instrumental to the
| boot process and it is impossible to boot a modern Intel x86
| system without it. It's quite tiring seeing x86 vendors
| continuing to misrepresent this.
|
| See comment by bri3d below for details. It appears they're just
| sending a command to the ME politely asking it to stop doing
| things, maybe. Of course, this happens long after the ME has
| already done a great deal of work bringing up the system.
|
| Of the three options for ME scope reduction, none are good and
| none actually "disable" the ME, but it seems like they've chosen
| the least effective/audited option of the three. I should add
| that if you don't trust the ME not to be owned, there's not
| really any reason to trust that it will honour a polite request
| to stop doing anything sent to it, and you can't trust it not to
| have compromised the boot process anyway, making this rather
| pointless.
| VWWHFSfQ wrote:
| I'm wondering how someone like the USA government manages this?
| They have massive deployments of Intel x86 like at the Utah
| Data Center [1].
|
| [1] https://en.wikipedia.org/wiki/Utah_Data_Center
| elif wrote:
| There was a dell link floating around for a while to an
| internal store listing for laptops with IME-free CPU's. It
| was then taken down with the (implied? Explicit? I don't
| recall) explanation that it was meant for government
| employees only.
| mjg59 wrote:
| The ME isn't in the CPU, it's in the PCH. I'd be astonished
| if Intel made special parts that didn't use the ME at all,
| it's much more likely that they just have the HAP bit set
| in the FIT and the ME largely shuts down part-way through
| boot (you still need ME firmware to be present, so the ME
| clearly still runs some amount of code before disabling
| itself)
| deelowe wrote:
| They partner with Intel to get what they need taken care of.
| Not something the average person can do.
| caeril wrote:
| "I'm wondering how the people who ordered Intel to integrate
| spyware into their processors manages this?
|
| Answer: order them to tape out N units without the spyware
| for only you. A new photomask isn't all that expensive.
| mhitza wrote:
| They might just ask Intel to put a special flag in, like the
| one discovered back in 2017.
|
| > One of the fields, called "reserve_hap", drew our attention
| because there was a comment next to it: "High Assurance
| Platform (HAP) enable".
|
| > Googling did not take long. The second search result said
| that the name belongs to a trusted platform program linked to
| the U.S. National Security Agency (NSA)
|
| https://web.archive.org/web/20170829010653/https://blog.ptse.
| ..
| charcircuit wrote:
| They don't need to disable ME, no more than they need to
| disable some microprocessor in a network card. The government
| doesn't have to believe baseless conspiracy theories when
| they design datacenters.
| DaSHacka wrote:
| Yes, that's clearly why they order computers from
| manufacturers with ME disabled, because it's _not_ a
| backdoor...
| tssva wrote:
| I'm writing this from my car as I wait to have my state safety
| inspection done. My car has a traction control system which is
| enabled. Just pushed the TCS button. It was enabled and now it
| is disabled. Just pushed the button again. It was disabled and
| now it is enabled. I can switch freely between each state and
| in neither case does the description of the state require
| quotes around it.
| FireBeyond wrote:
| In most cars, TCS enable/disable is not really as concrete as
| it sounds, but more "allow more wheel slippage/spin from
| stopped" for snow/mud scenarios. Even with it 'nominally
| off', it's still there and working hard.
|
| On certain performance cars, it's actually a three stage
| system. On my Audi RS 5, there's the same thing as you
| describe. And then if I push, and hold, TCS for five seconds,
| it goes fully off (for race days and such).
| lannisterstark wrote:
| Considering your car's (most average cars) TCS never really
| gets fully disabled... Yeah, your word needs quotes even
| more.
| t09i209ba893 wrote:
| IDK, even this method was not possible for years due to the
| issue with s3 sleep not working. While it's not an absolutely
| unmitigated win, I think it is still valuable to at least
| regain this option. I wish that hardware freedom was at a place
| where it was worth being frustrated with vendors for not making
| a finer distinction here, but in this case I'm just glad to see
| any progress on this front.
| EuropeOverlords wrote:
| [dead]
| EuropeOverlords wrote:
| [dead]
| egberts1 wrote:
| This is why we never use much less connect the onboard Intel
| Ethernet port for any motherboards having Intel support. (Same
| for AMD); we always add a (better) Ethernet NIC adapter card.
|
| Meanwhile, mothetboards having ARM, RISC and PowerPC continues to
| gain support.
| nazgulsenpai wrote:
| Even as someone who doesn't use anything System76, I truly
| appreciate all of their contributions.
|
| Kinda tangential but I wonder, as successful as they've been in
| their niche (I presume, based on how prolific the branding is) I
| wonder if they would be better positioned to make a Linux phone
| where the others have fallen flat? I loved my PinePhone but as a
| novelty mini-AIO PC more than a phone. I doubt they'd want to
| step onto that minefield, but I wouldn't be able to help but get
| excited if such a project ever materialized.
| samstave wrote:
| As a customer of System76 since at least ~2014, (many machines)
| I dont like them as a company ;
|
| - They wanted $90 for a replacement laptop power supply cable
|
| - They wanted money to replace screws that that fell off and
| were clicking around in the body of the machine
|
| - They took the exact same model/design (from CLIO) of machine
| in the same release year and changed the interface for the LCD
| screen mid-stream, so a newly ordered screen for machine would
| not connect because they changed the ribbon cable type and told
| me to kick rocks
|
| The machines had extremely flimsy cases and the fan fins often
| broke...
|
| I loved running linux on them for the value for the guts you
| got on their machines, but their support fucking sucked. I
| abandoned them a few years ago.
|
| I still have one of their machines here - and its firmware
| failed and its unsuable.
| panick21_ wrote:
| There are enough phone projects, and they are hard. I much
| rather have a laptop project and that's what they are working
| on.
| PopePompus wrote:
| Yes, building a cell phone is simply something a small group
| of people cannot do successfully. I used to develop software
| for Openmoko phones, the N900, and other early Linux phones.
| Those projects had several decedent projects, all of which
| failed. There are several show-stoppers: 1) chip vendors
| won't talk to you if you are proposing to build a few
| thousand phones. 2) These projects never produce several
| iterations of prototypes that are tested by a significant
| number of users, so if they ever do ship a phone, there are
| terrible hardware faults. Fun fact: end users are not good at
| adding additional surface-mount components to cure these
| problems. 3) Unless you are making an Android phone, or at
| least an Android-compatible phone, none of the major apps
| will be available, and your customer base will be limited to
| the small fraction of the population that cares about
| privacy. So you'll never see economies of scale. 4) It will
| take longer than expected to bring the phone to the market,
| so even if you manage to build something, the hardware will
| be several generations behind what consumers expect. 5) Power
| management is _hard_.
| jancsika wrote:
| > chip vendors won't talk to you if you are proposing to
| build a few thousand phones.
|
| So is all the bootleg crazy hardware produced and sold in
| Shenzhen basically running the same firmware/driver blobs
| used in the West?
|
| Is there really _nobody_ who has access to specs for even
| out-of-date shitty cameras, wifi modules, and old gpus?
| donkeybeer wrote:
| Whats the minimum volume of units do you think is necessary
| to get them interested?
| nazgulsenpai wrote:
| No, I agree. I don't expect it would or even should happen,
| but if it did I would be very interested.
| Brian_K_White wrote:
| Still waiting years for my FxTec. By the time it arrives I
| asssume I will be unimpressed with a snapdragon 662. Qualcom
| EOLed the snapdragon 835 it was originally based on, so mid-
| way, they had to redesign around a newer but lower spec chip.
| The original chip was a high end but from 2017. Imagine
| getting that, new, in 2023 or 2024.
|
| In some ways I guess I don't care since I'm on a pixel 4a 5g
| just for the headphone jack. But I also only paid about 150
| or 200 for it.
| user6723 wrote:
| The purpose of Intel ME is to give foreign intelligence agencies
| wireless access to America's senators, executive teams, and
| critical infrastructure.
|
| Occasionally the open source security industry uncovers yet
| another 0day in the endless stream of zero days then Intel and
| all the OEMs release a patch to fix the bug and add three more
| 0days to Intel ME.
|
| Very very few IT teams want AMT. It is a total scam. If we had a
| functioning government, Intel ME in its current from would never
| be allowed to be sold in USA.
| Aerbil313 wrote:
| > The purpose of Intel ME is to give foreign intelligence
| agencies wireless access to America's senators, executive
| teams, and critical infrastructure.
|
| I agree, only that I think it's reverse. It would seem that
| American companies like Intel and AMD can be far more easily
| controlled with both force and cash by American government, not
| by foreign governments.
| charcircuit wrote:
| >The purpose of Intel ME is to give foreign intelligence
| agencies wireless access to America's senators, executive
| teams, and critical infrastructure.
|
| Do you even have a shred of evidence for this claim?
|
| >yet another 0day in the endless stream of zero days
|
| There is not an endless stream of zero days in the ME. None of
| these are relevant to most people's security model. Even for
| those with an excessive security model attacks you probably
| already consider your machine compromised if tan attacker has
| physical access to it.
| everdrive wrote:
| I understand what the ME at a very vague level, but I'm confused
| about how it works. How would someone interact with the ME? Is it
| just listening on my network interfaces? Would someone need to
| run code from my OS? Does it matter what OS I'm using?
| mjg59 wrote:
| In general the ME will only be listening for network traffic if
| you've enabled AMT functionality (which is restricted to
| certain enterprise SKUs and has requirements around which
| networking hardware is used and so on). Otherwise, the ME will
| expose a PCI device implementing the Host Embedded Controller
| Interface (HECI) and OS drivers can bind to that to offer an
| interface to applications.
| dang wrote:
| We changed the URL from
| https://www.phoronix.com/news/System76-Disable-ME-RPL, which
| points to this and seems to add nothing significant.
|
| I've left its title, even though people are disputing it, since
| the comments are mostly about that.
___________________________________________________________________
(page generated 2023-06-02 23:00 UTC)