Let me try again to state what I stated before, with some new insides, because Tim brought the new equation: HAP into this discussion.
HAP - High Assurance Platform is long known (I know it from 2014), and its purpose, introduced by INTEL ME team was to disable ME as an application in INTEL embedded applications. I am not sure how this reflects The Truth, since no one truly knows in details the PCH (South Bride) design. >From this what I wrote here, DELL, per say, will have NO any Legal Issues, since they signed agreement with INTEL to use HAP, my best guess. DELL will use NOTHING what Black Hat hackers discovered, just legal means (RSNDA): HAP! Let me repeat the rest, from the very instructive and perfect link, outlining all what Black Hat hackers did to reveal internals of ME: http://blog.ptsecurity.com/2017/08/disabling-intel-me.html *"The disappointing fact is that on modern computers, it is impossible to completely disable ME. This is primarily due* *to the fact that this technology is responsible for initialization, power management, and launch of the main processor."* I will repeat again (in RED). Long before BIOS starts, there are (at least >5) very complex phases how the whole platform, by HW and FW is initialized. There are several components which are interacting with PCH, thus/read ME, BEFORE BIOS starts, These components are the following: PMIC (Power Management IC, integrated or discrete) EC (Embedded Controller) Some of IO init (HW wise default straps, then ME applied FW straps) ICC (Integrated Clock Controller) All of which need to be set correctly BEFORE MEI allows BIOS to start. And there are some relationships among these entities in the process of ME driving init of these components. It is a Rocket Science, after all (IMHO). Not going deeper into these details. This could NOT be removed, and, in my opinion, do not even try to do that. But one can always try. Good Luck! ;-) All the rest CAN and SHOULD be removed... Which does NOT guarantee that some hidden processes in ME inside PCH do not run (outside 32MB DDR memory, reserved solely for ME as application, could be blocked). All said here, IMHO! Zoran On Fri, Dec 8, 2017 at 3:04 AM, taii...@gmx.com <taii...@gmx.com> wrote: > Companies such as dell and purism that purport to offer a "safe" > "disabled" ME/PSP are being dishonest - there is no way to disable > something so integral by design to the boot process of modern x86-64 > platforms. > > If for once there is an organization that cares about security they can > buy a pre-PSP AMD system, select ARM systems and of course POWER - if they > have truly valuable IP the cost for an owner controlled POWER system such > as the TALOS 2 that lasts a decade and doesn't have "surprises" is a great > deal. > > There are already boards that have "fully open source firmware" you just > aren't hearing about them, excluding development boards - the TALOS 2, > Novena and KCMA-D8/KGPE-D16 systems fit in to this category (I play modern > games on my D16, so one isn't stuck with chintzy ARM PC's) > > Considering the level of IT waste in the average company there is always > more than enough money to buy real security it just isn't allocated > properly. > > Vendor guarantees (which here you lack) are bogus and will never hold up > in court - contrary to the goals of the bean counters who think they can > outsource risk to a vendor ("no we don't need to worry about IT security > its all in the cloud and someone elses problem") > > > If I was an IT manager I would be running me cleaner right now and looking > in to non-x86 computers, I wouldn't be that thinking $20 to dell per/pc > solves the issue. > > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
