On 28.03.19 20:04, Philipp Stanner wrote:
Hi,
His argument was: Imagine it would take you 15 minutes to install a patch on a computer (all windows machines of course...). If your company has 1000 computers and you send one admin to install the patches, it will take him >31 work days, working 8h a day. That's why, he said, companies are interested in software allowing them to install stuff on the OS / hard drive remotely through the firmware
PXE, in-production since the 90th.
Before that we hat it's individual components (tftp, bootp, dchp) in separate boot roms, since the 80th.
Ergo: no excuse for IME at all.
What else could one have missed ?
* digital signed payloads ? --> simple to add to the existing stack. (BIOS) * remote console before OS comes up ? --> pretty simple to add to the BIOS * remote provisioning of BIOS settings ? --> also pretty simple to add via PXE --> just standarize (or at least document!) the pmem access and layout. --> could even be done w/o touching the BIOS * remote powering / reboot ? --> that's something you *really* *do not* wanna have available from the same network segment. seriously, not. --> add a BMC (which then easily can do the rest of the stuff)
I, not dealing with large networks, had never thought about it this way. But it does make a lot of sense to me, it's about real money (as usual).
Just money or power ? The word "intel" has some interesting meanings ...
So I guess that's indeed a huge reason why Intel and AMD created Frankenstein, running below UEFI and Kernel.
Certainly not the actual reason, just a really infamous excuse.
Indeed there actually is a reason for having a separate MCU on-dice, eg. internal power control, clocking, etc is horribly complicated, so you wanna do it in software (field-upgradable). But such an MCU certainly does not need full contol over the whole CPU and periphery.
Still NO EXCUSE for putting in such a backdoor. And the existance of the HAP bit should give some more insight on what that thing is *really* for.
So I'm wondering: What would you do about this reality?
Avoid x86. And you also avoid that totally insane UEFI (even ACPI), which already was completely obsolete long before its incarnation.
Just have a look at ARM/PPC embedded world. The SoCs either directly boot up from flash or have a tiny builtin microloader which can even load from sdcards or USB sticks. Here we directly put in our bootloader (uboot, barebox, ...), which we can build/customize for our own needs.
As a mainboard vendor of generic mainboards, I'd just put an cheap micro sd slot on the board (the sdhc usually is already there, anyways) and let the SoC directly boot from it (pretty usual approach in arm/embedded world). Now you can easily replace the bootloader, w/o jtag+friends. Boom: firmware made trivial and safe.
Could there be a different solution other than software in Ring -1 having its sausage fingers on everything?
We'd first have to define the exact problem to solve.
Sure, the programmers in a company could install their stuff on their own, but the office folks, the HR and PR guys and the lawyers? Hmm.
See above: the problem of automatic remote deployment has already been solved since the 80th. It worked well w/ the ancient CPUs back then, so why shouldn't it work anymore (it actually is done every day).
OTOH, I haven't seen a single actual installation with IME-based deployment in the field, yet.
And whether we like it or not, even awesome companies almost exclusively supply their employees with windows machines and they just demand solutions allowing their IT-departements to fix everything as cheap and as easy as possible
Besides that operating Windows is pretty much the opposite of cheap, all these things already exist and are used on daily basis long long before IME (also long long before UEFI)
I fail to imagine any sane technical or business reasons (except some highly criminal ones) for doing things like IME.
--mtx