Nico Huber nico.huber@secunet.com wrote:
Pew, thanks for reminding me, that we have this in our wiki.
[...]
Sorry, this was badly articulated. The "thanks" was meant sincere.
There was indeed some missunderstanding from both sides, I'm happy that it's fixed and we can now understand each other.
I had this on my TODO list for some time. I think we should (if not already done) extend ifdtool to toggle whatever bit is needed to run without ME firmware. And let people use that instead of building a new blob which only extends the list of entities you have to trust.
I had that on my TODO list too, I planed to do it this way: - First merge ifdtool and ifdfake - Adjust the build system to use the unified tool - Add the bits necessary to produce a working GM45 image, by using ich9gen as documentation.
Until now, I only started evaluating how to merge ifdtool and ifdfake and didn't made much progress due to the lack of time spent on it.
PS. Actually I think coreboot shouldn't handle these platform blobs at all. But that's even harder to convince people of ;)
== Usage == I also don't like blobs. I've some questions with reguard to the ME blob: - What are the advantages of having the ME blob, for the end users, on devices with the GM45 chipset? - I would guess that it provides a "software" TPM. I don't see any TPM without the ME on my X200. - In thinkpads, it provides AMT, however I fail to see how relevant this is. I guess that no coreboot (or derivative) users want it. It would also require to use SeaBIOS and to extract the ME BIOS extensions option rom. - Does it gives better platform stability? RAM compatibility? Thermal management?
Given that: - The ME blob(s) are all proprietary software. As far as I know, no free software can run on the ME of the GM45 chipset. - The ME is not meant to have the end user directly interact with it in any ways. - The firmware partitions are signed. - The hardware (ME Processor or SOC or whatever it is called) has access to: - The network interfaces - Probably many other things, but I can't say for sure as I make some confusions between ME versions. I'm not sure that on GM45 it has access to the x86 CPU RAM, or the GPU framebuffer. I'm sure some versions of the ME do. - Having to use a blob complicates the compilation and installation for the end user[1], thus increasing the probability of making mistakes. - The ME blob occupy flash space.
It might be interesting to only offer the option to generate a valid flash descriptor that doesn't use any ME blobs for end users[1].
References: ---------- [1]Note that by end-user I mean anyone that have at least one GM45 laptop running coreboot (or derivative) that is not only used for coreboot development and testing. This probably includes many coreboot developers having such machines.
== Development == As far as I know, there isn't any way to execute code on the GM45 Management Engine, unless it's signed by Intel, right?
If we keep the code that handles the Management Engine (HECI), but remove the option to produce a flash image that uses a Management Engine firmware, would it be useful?
Would it help developers to find a way to execute code on the Management Engine and have free software code running in there?
I didn't look into the Management Engine yet, but I fear that there is a lack of available documentation on its internals.
So having free software (especially GNU/Linux) running there would: - Allow to understand better the hardware, and thus, improving the trustworthyness (or untrustworthyness) of the hardware. - Allow to implement things like software TPM, gpg smartcard, or whatever similar things. - Allow to offload an IRC client/mail fetcher/downloader on the Management Engine, and suspend-to-ram the x86 processor. - Allow to have a software BMC-like. I personally don't see any good use of it on laptops beside runtime testing (of coreboot), or remote assistance, but other people might have better ideas. It might be very useful for servers/desktops though. - Whatever idea people comes up with.
Denis.