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
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
