A small remnant is left operational - without it, a PC shuts down after 30 minutes (this is well-known).
The Core 2 Duo/Quad architecture was the last iteration where the ME subsystem could be entirely removed.
I posted two BIOS images on this link for old HP machines. They can easily be flashed from within the booted bios without much hassle. Looking for the link...
Found it on Bing of all places!
Yeah, but unfortunately intel also didn't bother providing microcode patches for meltdown on those chipsets "because to old" by some arbitrary definition of "old".
However, these are not SMT/hyperthreaded, so many of the Specter vulnerabilities do not apply.
OpenBSD runs well enough on them, and these machines are likely what I trust most with this OS.
Most Linux runs on these machines (RedHat 9 doesn't - requires an i3), but will pause on the mei_me module and look for a response from the ME that you have lobotomized; blacklist the related modules if you want to boot faster.
It is vulnerable to variant 3a, 4, Fallout, Zombieload, and and both RIDLs.
Neither of the two methods to disable the ME discovered so far turned out to be an effective countermeasure against the SA-00086 vulnerability. This is because the vulnerability is in an early-loaded ME module that is essential to boot the main CPU.
https://en.wikipedia.org/wiki/Intel_Management_Engine#Disabl...
A 45nm platform that will do what you ask is far preferable to a 10nm platform that won't.
"Additional major security flaws in the ME affecting a very large number of computers incorporating ME, Trusted Execution Engine (TXE), and Server Platform Services (SPS) firmware, from Skylake in 2015 to Coffee Lake in 2017, were confirmed by Intel on 20 November 2017 (SA-00086).[39] Unlike SA-00075, this bug is even present if AMT is absent, not provisioned or if the ME was ‘disabled’ by any of the known unofficial methods.[40] In July 2018 another set of vulnerabilitites were disclosed (SA-00112).[41] In September 2018, yet another vulnerability was published (SA-00125).[42]"
https://njnewnjnew.medium.com/management-engine-interface-dr...
https://www.theregister.com/2017/12/06/intel_management_engi...
It does make me wonder what else has been missed.
We have such elaborate means to deceive one another. Perhaps, one day, we will be good enough that it is no longer necessary. But that is not today.
Sorry to be a stickler, but not really.
The citation indexed [40] (that is, the relevant portion) in your quote points to the Register article you also linked, just as the Wikipedia entry does in support of the statement:
"Unlike SA-00075, this bug is even present if AMT is absent, not provisioned or if the ME was "disabled" by any of the known unofficial methods."
That being the case I would expect the Register article to contain something that bolsters the quote above but if it does, it is so subtle as to escape my repeated rereading.
I believe some motherboards won't let you flash the modded bios if it's cryptographically unsigned or something like that, which is good for other reasons... but I haven't run into it myself.
I've disabled ME on a couple of supermicro boards too, using me-cleaner, since they were supported. (What I consider the "very easy" method.)
edit: Sibling poster is right that it can't be fully disabled. I do assume it's effectively disabled when it no longer appears in device manager and Intel's ME inspection tools show it as disabled.
If the guide said "dump the flash" and "write back the flash" instead of the detailed instructions, and only described firmware manipulation steps in details it would be much shorter.
Big "Look what you made me do" energy.
We hear this all the time don't we? Claims that something is;
"Because people want it".
"Markets demand it".
But we see absolutely no evidence of them whatsoever, this mythical mass of people clamouring for features that are strangely aligned with the things big-tech suppliers and manufacturers wish ti push and get to simply assert that "people want".
We like to think of ourselves as "evidence based, rational society" We'll happily hold governments, scientific and health research to a high standard of evidence. Even Wikipedia articles demand "citation needed".
Show us those people! Back up your claims Intel.
From my experience, I actually must disable 5G. The 4G network in my area actually works well enough in all circumstances. The 5G network is all-or-nothing. I either wind up with incredible speeds or completely unusable.
I'm with Telus up here in Canada. You pay the same old rates as per the usual for 5G speeds. If however you go with their subsidiary (Koodo) using the older infrastructure, you can pay a little less for similar packages.
Check it out yourself. Mind you, I use prepaid, cause I don't want to be on a contract, so I buy my own phone and use it. Koodo even charges more for bringing your own phone, since they aren't collecting on having leased one to you.
https://www.telus.com/en/mobility/prepaid/plans?linktype=sub... https://www.koodomobile.com/en/rate-plans?INTCMP=KMNew_NavMe...
Simply put, if I want to save money while still having enough data for what I actually need data for; I can either spend about 35-40$ with Koodo for 2-4GB of data at 3 & 4G speeds; or 40-50$ for 2.5-4.5GB at 4 & 5G speeds. I round things this way by the way, because of taxes. Also, auto-top up also tends to give some extra data too. 500MB more. So generous of them (/s).
And also, this is new packages. They just updated them with the new promo on Telus with that whole 1GB extra data and 10$ one time credit. I'm gonna have to call them and get that I guess. Unless they auto gave it to me? Who knows with them. Ultimately, I only need 500MB though, since I use Spotify in offline mode, and only download music via my wifi at home; and the only other thing I tend to use is Google Maps which can also be downloaded ahead of time to save on data.
Edit: I should also note that they do actually state 4G on the Telus website, but my phone says I am getting 5G speeds. Hence why I state 5G. I could care less what they claim on their website. End user experience is truth.
Some of it, like beam steering that tracks moving devices, which is going to be challenging to make it work in real world cases, and using spectrum that makes it hard to penetrate inside cars and buildings, is a reach nobody asked for.
Some seems greed driven, like "If we can convince AWS customers they need to put computing at the network edge we (telcos) will capture some of the value AWS accumulates now."
As for your 4G network, that's what we call 5Ge now.
Is 5Ge some sort of joke? Or is that a real designation.
It’s real. My iPhone 13 says it right now. https://arstechnica.com/tech-policy/2020/05/att-still-refuse...
Sprint sued for the blatant false advertising and AT&T unsurprisingly settled.
I want my phone to work in busy cell tower areas, so that is absolutely something I was demanding.
The government folk want it gone from theirs, but they want the rest of us to have it. Thus the claim "Our users want it" is true, in a tongue in cheek way.
(1) It is not something that you can (easily) disable
(2) It uses the same Network port that your LAN NIC uses instead of a separate "I won't plug that in if I don't want it" NIC.
(3) Security/Patches? This is outside the control of the BIOS manufacturer, so how do you make sure it's patched and upto date? and
(4) It wasn't an option.
I think the ME hating is kinda strident but it has a bunch of undocumented firmware and your PC still works after you remove it so... what was that firmware doing?
Both personally and as part of the management team of 150.000 computers at work, we don't use this stuff there either.
It is a great help for server lock-ups - it is able to force a full power-down of the main board and cold-boot.
The software behind iLO was also a presentation at BlackHat, so it's important to keep them patched (and I don't know anybody else that does).
https://www.blackhat.com/us-21/briefings/schedule/index.html...
It's definitely a security risk, but at a big company with a poorly managed IT department it wasn't the worst offender.
We also have Dells with iDRAC cards. But it's a nice thing with iLO that it's built-in, and it can be managed on a completely dedicated out-of-band network. Unlike the IME thing.
I understand there's a point to this in stuff like servers, but for workstations?
The devices are on an untrusted network and VPN into a LAN based on the device assignment. Things like printers are on a separate network, and there’s no cleartext on the network.
In the case of laptops, if they fall out of certain compliance baselines, they get remote wiped or bricked.
But IME is not needed for this. The certs are issued through windows / mac management systems e.g. SCCM/Intune. They are also dependent on the current security state of the machine (e.g. no EDR installed -> only access to remediation network). Is IME really used in your case?
The key difference is that you can provide a level of assurance and multi-tenant access without an OS. For example you can run a hypervisor on the PC and have a few OS instances running.
...hopefully RISC-V will save us from this nightmare.
RISC-V is just an ISA (Instruction Set) that anyone can use, but what people use it in, and how they use it, is not specified and does not have to be open source. Apple could take RISC-V, plop it in their iPhone, and release it tomorrow in a processor that only boots Apple-signed code and requires proprietary firmware without any issue whatsoever. Intel could literally release a Core i5 with a RISC-V instruction set and an Intel ME built-in, no problem.
Where the hope mainly comes from is small chip developers like SiFive, who make many of their drivers and such open-source. But that's only if you buy from vendors like them - if you implement your own RISC-V core, there's no requirement that the drivers or firmware be open-source for it, in any way. You might say that's a missed opportunity. I say RISC-V wouldn't have caught on otherwise.
So, you're saying it is possible (or will be down the track...) as long as things are bought from SiFive or a similar OSS-friendly place.
That's still a large improvement over the current situation, even if other vendors take different, locked down approach.
The hope is that (unlike x86/ARM) you will be able to purchase core designs from people who aren't sockpuppets. RISC-V will at least let people choose between which backdoor they want installed, which is an upgrade from a status quo of "All Your TCP Traffic Belongs To U.S.".
It's not exactly Superman, descending from the skies to deliver us from dystopia. But it's certainly a better path than letting ARM dominate any more of our chip landscape.
It also lowers the barrier to entry for new/rebranded sockpuppets, but having choices is a step in the right direction.
But there are still roadblocks as they likely bought the memory controller from a 3rd party as an IP block they drop into their chip. This means the bring up procedure for the memory controller is proprietary and delivered in blob form to be loaded into the black box ip. Likely the same for other 3rd party ip blocks as developing this stuff from scratch is very difficult and time consuming. Especially for critical hardware like memory controllers. This makes opening the platforms firmware just as tricky as any other chip from $bigvendor. This makes full top to bottom security audits difficult or impossible.
That said, the hardware we have is really good, it's just the software side that is a complete garbage heap.
Still though, AMD seems convinced that x86 can compete against modern RISC ISAs. They aren't far away from proving themselves right, honestly.
While I'd really love to agree with you, the IPC of a RISC-V chip can annihilate an x86 machine on equivalently advanced manufacturing node. It's performance-per-watt can reach up to 10x efficiency over x86 in the right situations, and pretty much all of the cool stuff we like in x86 can be added as an ISA extension.
If we're headed to a RISC/low-power computing future, RISC-V will be the future people's champion. x86 will be a legacy compatibility mode that we use for games and "retrocomputing", likely.