System76's coreboot open firmware manages to disable Intel ME for Raptor Lake(blog.system76.com)
blog.system76.com
System76's coreboot open firmware manages to disable Intel ME for Raptor Lake
https://blog.system76.com/post/major-updates-for-system76-open-firmware-june-2023
100 comments
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.
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
[1] https://en.wikipedia.org/wiki/Utah_Data_Center
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.
Yes, that's clearly why they order computers from manufacturers with ME disabled, because it's not a backdoor...
What evidence is there of it being a backdoor? Who was ultimately harmed/arrested as a result of it? I've never seen a link to a single case demonstrating that.
Personally, I don't care for the ME one way or the other, but I also don't think it's strictly spyware. That being said, Parallel construction is a thing and could be used in every case where the initially got their information from the backdoor in the ME, if such a thing exists.
The Silk Road bust comes to mind - https://www.schneier.com/blog/archives/2014/10/how_did_the_f...
>because it's not a backdoor
It lowers the attack surface by running less code. Most government computers don't even have the HAP bit set.
It lowers the attack surface by running less code. Most government computers don't even have the HAP bit set.
They partner with Intel to get what they need taken care of. Not something the average person can do.
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...
> 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...
"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.
Answer: order them to tape out N units without the spyware for only you. A new photomask isn't all that expensive.
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.
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)
It can be de-blobbed though [1]. At least this will "de-risk" it as part of the boot process ?
[1]: https://github.com/corna/me_cleaner
[1]: https://github.com/corna/me_cleaner
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.
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).
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).
Considering your car's (most average cars) TCS never really gets fully disabled... Yeah, your word needs quotes even more.
I can't tell what point you're trying to make and yet it seems wrong.
The point is that just because something is enabled at some point doesn't mean it can't be disabled at a later point. The original poster didn't seem to think ME is really disabled just because at some point it was enabled.
Did you miss the whole part about the boot process? It was the second sentence. You could only think they said that "just because" it you only read the first sentence of their comment.
I read the whole comment. The implication was that it wasn't really disabled because at some point it was enabled.
What makes you think that? The explicit, not-implied argument is that it enabled because it "is impossible to boot a modern Intel x86 system without it".
Of course if you ignore arguments entirely, other people's opinions become arbitrary. But that's all you.
Of course if you ignore arguments entirely, other people's opinions become arbitrary. But that's all you.
Of course it does. That is exactly another example of something that doesn't actually do what it says.
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).
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).
> 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?
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?
> 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.
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.
Alternatively, you can set the HAP bit in the BIOS flash https://hackaday.com/tag/hap-bit/
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.
* 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.
Do we have anything equivalent for AMD’s PSP?
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.
I haven't found anyone who has actually reversed the functionality to audit what it's doing, though.
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.
>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.
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.
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.
This is not unique to NSA. Security agencies within other governments play the same games with supply chains.
Intel making their products insecure is bad for their brand and bad for world wide computer security. Massive amounts of damage could happen by abusing such a backdoor. There is plenty of evidence of Intel claiming that there are no backdoors in their products, but there isn't for some NSA deal for adding a backdoor.
Pardon? Snowden showed huge amounts of NSA backdoors. It’s probably worth limiting the conversation to what they don’t have access to rather than trying to enumerate what they do have access to.
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.
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/.
You must have slept through Snowden.
That is not an argument. You can't justify that everything is secretly backdoored because of some old leak.
The safe assumption is that if there is a computer sitting on your LAN that you don't have access to that has access to your stuff that you have a massive security issue in waiting. That it hasn't materialized yet doesn't mean a thing and there are plenty of documented security holes associated with the ME, and likely many more that you simply will never know about. This stuff has been chewed to bits on HN and elsewhere.
If you feel different that's fine but with security the old adage 'better safe than sorry' applies very much and given the data collected so far the evidence of 'some old leak' times n is rather more solid than your belief in the opposite. FWIW Intels claims that they would not cooperate with the NSA are worth absolutely nothing because the USG has the power to tell Intel to stay quiet about such a deal.
If CISCO could be influenced by the NSA then so can Intel, either through supply chain interdiction or through more direct means. But to categorically claim that this is an impossibility is nonsense, the relevant questions are (1) has it been done? and (2) how would we ever find out given the locked up status of the ME? and (3) who past Snowden would be brave enough to leak the evidence if it exists?
If you feel different that's fine but with security the old adage 'better safe than sorry' applies very much and given the data collected so far the evidence of 'some old leak' times n is rather more solid than your belief in the opposite. FWIW Intels claims that they would not cooperate with the NSA are worth absolutely nothing because the USG has the power to tell Intel to stay quiet about such a deal.
If CISCO could be influenced by the NSA then so can Intel, either through supply chain interdiction or through more direct means. But to categorically claim that this is an impossibility is nonsense, the relevant questions are (1) has it been done? and (2) how would we ever find out given the locked up status of the ME? and (3) who past Snowden would be brave enough to leak the evidence if it exists?
This is probably going to change when AMD switches from AGESA openSIL, fully open firmware.
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?
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.
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.
> 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.
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.
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.
Will it have access to a wifi card? Only Intel?
Yes, AMT works over Intel WiFi.
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?
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.
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.
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.
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.
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.
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.
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.
- 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.
Interesting. My experience has been the opposite.
> 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
I don't understand what happened here. Did you buy clevo (clio?) parts and expect it to be compatible with what they shipped you?
> I abandoned them a few years ago
What do you recommend instead?
> 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
I don't understand what happened here. Did you buy clevo (clio?) parts and expect it to be compatible with what they shipped you?
> I abandoned them a few years ago
What do you recommend instead?
>"Did you buy clevo (clio?) parts and expect it to be compatible with what they shipped you?"
NO. the OEM for the first sets of S76 laptops were a spec buy from S76 to Clio?Clivo? - taiwanese laptop mfr who makes spec built kit....
The problem was that S76 wanted strong guts, but a lower price point to lure Linux Savvy buyer... and the machines they had built, while the guts were strong - the casing was weak and the build quality poor... (this is why Apple makes their machines out of Aluminum rather than plastic. Which is great one many levels, but there are also cons with using aluminum in anything...)
-
>"What do I recommend"
Currently on a flagship HP Omen Gaming machine - but still this exhibits hardware problems - this machine is ~$3,000 and I am on my third one with the previous two having mainboard failures of different causes...
But HPE Executive support is probably the best computer support I have received barring COMPAQ (whom HPE acquired in the late '90s... - COMPAQ support was legendary)
so - I am still paying for awesome guts - but even these Omen laptops still have a shitty case design...
They have a top aluminum panel for the KB - but the under panel is a flimsy plastic BS - and they still use undersized screws which are prone to fall out...
But the mainboard design is pretty bad ass.
Dual SSD slots - good venting (even though the machine has problems on any sof surface (like a blanket or a bed) because the venting is bottom fans venting air up, but when stiffled by a blanket/bed/pillow - it makes the machine overheat...
And W11 is not help in that area - power mgmt in W11 is atrocious from a subjective perspective - but if you want powerful gut and dont care about the above - then an HP Omen gaming machine with great graphics and proc and an AI capable GPU (although I havent used that much yet) is bad ass - couple that with USB powered external monitors and you have a three-screen awesome machine that is light and fits in any backpack.
but the legacy of apple is really the aluminum chassis...
But strong guts are more important to me for compute/$
NO. the OEM for the first sets of S76 laptops were a spec buy from S76 to Clio?Clivo? - taiwanese laptop mfr who makes spec built kit....
The problem was that S76 wanted strong guts, but a lower price point to lure Linux Savvy buyer... and the machines they had built, while the guts were strong - the casing was weak and the build quality poor... (this is why Apple makes their machines out of Aluminum rather than plastic. Which is great one many levels, but there are also cons with using aluminum in anything...)
-
>"What do I recommend"
Currently on a flagship HP Omen Gaming machine - but still this exhibits hardware problems - this machine is ~$3,000 and I am on my third one with the previous two having mainboard failures of different causes...
But HPE Executive support is probably the best computer support I have received barring COMPAQ (whom HPE acquired in the late '90s... - COMPAQ support was legendary)
so - I am still paying for awesome guts - but even these Omen laptops still have a shitty case design...
They have a top aluminum panel for the KB - but the under panel is a flimsy plastic BS - and they still use undersized screws which are prone to fall out...
But the mainboard design is pretty bad ass.
Dual SSD slots - good venting (even though the machine has problems on any sof surface (like a blanket or a bed) because the venting is bottom fans venting air up, but when stiffled by a blanket/bed/pillow - it makes the machine overheat...
And W11 is not help in that area - power mgmt in W11 is atrocious from a subjective perspective - but if you want powerful gut and dont care about the above - then an HP Omen gaming machine with great graphics and proc and an AI capable GPU (although I havent used that much yet) is bad ass - couple that with USB powered external monitors and you have a three-screen awesome machine that is light and fits in any backpack.
but the legacy of apple is really the aluminum chassis...
But strong guts are more important to me for compute/$
Does HP Omen ship with Linux, and does HP support it?
There are enough phone projects, and they are hard. I much rather have a laptop project and that's what they are working on.
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.
> 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?
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?
The thing is, if you build a phone out of shitty old components that the manufacturers no longer care about, who's gonna buy it?
I was all in on OpenMoko before I knew anything about these topics. First big disappointment in terms of hardware projects. Cool that you worked on that. I'm less optimistic on projects now but a lot respect for people who tried to do that work.
To bad the whole Nokia N900 thing didn't work.
To bad the whole Nokia N900 thing didn't work.
Whats the minimum volume of units do you think is necessary to get them interested?
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.
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.
No, I agree. I don't expect it would or even should happen, but if it did I would be very interested.
Did you consider a Librem 5 phone? Happy user here.
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
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
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.
I've left its title, even though people are disputing it, since the comments are mostly about that.
I'm hoping some RISC-V system developer will take the opportunity not to embed a mess like the Intel ME.
I lost my hope when they adopted UEFI.
Could you elaborate what the problem with UEFI is and what the alternatives are? Genuine question, as I've never heard this sentiment before.
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.
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.
I've heard many complaints about UEFI. Personally, I don't like the complexity, and I distrust some of the parties involved.
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™ 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."
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™ 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."
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.
Meanwhile, mothetboards having ARM, RISC and PowerPC continues to gain support.
Disabling the biggest malware of all time is amazing. System76 is getting quite attractive.
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.
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.
1. May be coming: https://twitter.com/jeremy_soller/status/1662551130768044032
Jeremy's post seems to going pretty strongly at that.
Jeremy's post seems to going pretty strongly at that.
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?
Intel ME, as its own CPU, promiscuously listen for a certain Ethertype or UDP/TCP port.
it is optional to run an additional OS code from the main Intel CPU to gain access to Intel ME.
Intel ME's basic function is to display your monitor over network, monitor some hardware temp sensors, and reset the motherboard while your main Intel CPU is running or suspended (or even powered down).
since we cannot verify that Intel ME is only doing just that specific listening of network packet, because we do not have access to their source code (much less rebuild our own copy of Intel ME binaries); we cannot assume any modicum of correctness of Intel ME CPU operation (which has full unfettered access to all of your CPU memory) nor determine the level of maliciousness ... of your Intel ME.
it is "caveat emptor" from a computer security POV.
it is optional to run an additional OS code from the main Intel CPU to gain access to Intel ME.
Intel ME's basic function is to display your monitor over network, monitor some hardware temp sensors, and reset the motherboard while your main Intel CPU is running or suspended (or even powered down).
since we cannot verify that Intel ME is only doing just that specific listening of network packet, because we do not have access to their source code (much less rebuild our own copy of Intel ME binaries); we cannot assume any modicum of correctness of Intel ME CPU operation (which has full unfettered access to all of your CPU memory) nor determine the level of maliciousness ... of your Intel ME.
it is "caveat emptor" from a computer security POV.
> Intel ME's basic function is to display your monitor over network, monitor some hardware temp sensors, and reset the motherboard while your main Intel CPU is running or suspended (or even powered down).
No, that's AMT, which is an optional feature not enabled on the majority of devices with an ME. On an average system it's much more likely that the ME is being used for PTT (Intel's implementation of a TPM running on the ME, avoiding the cost of an additional TPM chip), a protected video path for DRMed video (the encrypted video is passed to the ME, which decrypts it and draws it to the screen without the decrypted content ever being visible to the host CPU) and various other low-level platform integration things.
You don't need source code to verify the behaviour of a binary. The vulnerabilities that have been identified in ME code didn't depend on researchers having source code. Can we be certain that the ME isn't doing something malicious? No. But nor could we be certain even if we had the source code (maybe the microarchitecture was modified so that a specific sequences of instructions would cause the next cmp operation to invert , for example). Nobody's found any evidence of malice, and not really any more incompetence than you'd expect.
No, that's AMT, which is an optional feature not enabled on the majority of devices with an ME. On an average system it's much more likely that the ME is being used for PTT (Intel's implementation of a TPM running on the ME, avoiding the cost of an additional TPM chip), a protected video path for DRMed video (the encrypted video is passed to the ME, which decrypts it and draws it to the screen without the decrypted content ever being visible to the host CPU) and various other low-level platform integration things.
You don't need source code to verify the behaviour of a binary. The vulnerabilities that have been identified in ME code didn't depend on researchers having source code. Can we be certain that the ME isn't doing something malicious? No. But nor could we be certain even if we had the source code (maybe the microarchitecture was modified so that a specific sequences of instructions would cause the next cmp operation to invert , for example). Nobody's found any evidence of malice, and not really any more incompetence than you'd expect.
> You don't need source code to verify the behaviour of a binary.
Not even a died-hard cybersecurity reverse engineer would ever say, “you don’t need source code to verify the behaviour of a binary”, but it would make life easier to verify seldom-used or unused code for non-maliciousness.
Not even a died-hard cybersecurity reverse engineer would ever say, “you don’t need source code to verify the behaviour of a binary”, but it would make life easier to verify seldom-used or unused code for non-maliciousness.
Source code alone can never provide proof of non-maliciousness. Reflections on Trusting Trust demonstrated that almost 40 years ago.
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.
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?
Look at AMT documentation.
Intel is struggling to survive-- they'd be smart to open up all their firmware, microcode and drivers and let the open source community super charge their hardware and drivers.
I hope someone proofreads that article before it's published to the Interwebs!
A buffer overflow that allows the replacement of arbitrary portions of memory hmmm... Surely a simple, innocent coding error... Surely no one would have desired an obfuscated means of distributing a modified version of IME such that it can't be detected on the shipped CPU... Right?
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.
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.
> 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.
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.
The best the govs have been able to do is get a HAP bit.
>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.
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.
The vulnerability where no authentication was required and could be exploited wirelessly while the machine was off is directly relevant to the security model of anyone with a laptop with an Intel CPU.
I have been responsible for keeping small fleets of laptops patched and I actually read the relevant CVEs Intel puts out, which if you bothered to do you would find that yes over the years there has been an endless stream of fatal 0days
I have been responsible for keeping small fleets of laptops patched and I actually read the relevant CVEs Intel puts out, which if you bothered to do you would find that yes over the years there has been an endless stream of fatal 0days
>is directly relevant to the security model of anyone with a laptop with an Intel CPU.
I assume you are talking about INTEL-SA-00075. To quote "This vulnerability does not exist on Intel-based consumer PCs with consumer firmware." This vulnerability was responsibly disclosed to Intel and there was a security update made that patched it along with mitigation instructions in case your motherboard manufacturer did not create an update.
Security bugs and security updates are just a matter of reality. Anyone managing a fleet of computers needs to make sure that the whole fleet is getting security updates for any software that is running on it. This isn't a problem exclusive to the Intel ME. If this was instead was implemented as an OS driver it would still be a critical vulnerability that would need to be patched.
>over the years there has been an endless stream of fatal 0days
I believe INTEL-SA-00075 is the only ME related vulnerability that was rated as critical. I am not seeing all of these fatal 0 days that you are talking about.
I assume you are talking about INTEL-SA-00075. To quote "This vulnerability does not exist on Intel-based consumer PCs with consumer firmware." This vulnerability was responsibly disclosed to Intel and there was a security update made that patched it along with mitigation instructions in case your motherboard manufacturer did not create an update.
Security bugs and security updates are just a matter of reality. Anyone managing a fleet of computers needs to make sure that the whole fleet is getting security updates for any software that is running on it. This isn't a problem exclusive to the Intel ME. If this was instead was implemented as an OS driver it would still be a critical vulnerability that would need to be patched.
>over the years there has been an endless stream of fatal 0days
I believe INTEL-SA-00075 is the only ME related vulnerability that was rated as critical. I am not seeing all of these fatal 0 days that you are talking about.
>> "This vulnerability does not exist on Intel-based consumer PCs with consumer firmware."
Yet it did exist on computers used by senators, lawyers, executives, everyone I mentioned. Consumers are not the high value targets.
>> This vulnerability was responsibly disclosed to Intel
The vulnerability was uncovered and well known of by very many private espionage teams for a very long time. If this wasn't already obvious to you then your view of the world is too sheepish and naive to meaningfully participate in discussion about this kind of topic.
>> I am not seeing all of these fatal 0 days that you are talking about.
Those of us in the offensive security space see vulnerabilities that could be exploited "locally", anywhere where bad code could get running on the ME as critical too. Getting SYSTEM or root (the former being easier because of that OS' particular culture) is generally easier than it should be. Intel ME makes it a much bigger problem than it otherwise would have to be.
While you most likely are not, you come across as a shill.
Yet it did exist on computers used by senators, lawyers, executives, everyone I mentioned. Consumers are not the high value targets.
>> This vulnerability was responsibly disclosed to Intel
The vulnerability was uncovered and well known of by very many private espionage teams for a very long time. If this wasn't already obvious to you then your view of the world is too sheepish and naive to meaningfully participate in discussion about this kind of topic.
>> I am not seeing all of these fatal 0 days that you are talking about.
Those of us in the offensive security space see vulnerabilities that could be exploited "locally", anywhere where bad code could get running on the ME as critical too. Getting SYSTEM or root (the former being easier because of that OS' particular culture) is generally easier than it should be. Intel ME makes it a much bigger problem than it otherwise would have to be.
While you most likely are not, you come across as a shill.
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.