On 29.03.2017 10:52, Denis 'GNUtoo' Carikli wrote:
To get a working Ethernet with (3) you need to set a valid mac address: In the installation documentation, you are expected to use ich9gen, however if you use it this way:
$ ./ich9gen
It will not produce a valid MAC address. You must instead do something like that, and replace <A-VALID-MAC-ADDRESS> by a valid MAC address:
$ ./ich9gen --macaddress <A-VALID-MAC-ADDRESS>
To find such MAC address, you have several options:
- Look if it can be found on a sticker on the bottom of your laptop.
- Reflash the original flash content and get it with:
$ ifconfig -a
or:
ip link
Pew, thanks for reminding me, that we have this in our wiki.
I was not reminding you, I was talking to Zoran Stojsavljevic. That said, it indeed would have been faster for me to point to the wiki resources.
Sorry, this was badly articulated. The "thanks" was meant sincere.
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.
Nico
PS. Actually I think coreboot shouldn't handle these platform blobs at all. But that's even harder to convince people of ;)
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.
On 29.03.2017 22:37, Denis 'GNUtoo' Carikli wrote:
Nico Huber nico.huber@secunet.com wrote:
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
Just drop ifdfake and related functions in our Kconfig/Makefiles. It's purpose relies on a patch to flashrom that was never merged and even its author (me) doesn't use it any more. The idea was to have the region table in the image to verify it against the descriptor in flash. IMO, flashrom should use the in flash descriptor by default and only support a different layout when explicitly asked to overwrite the descriptor. So you wouldn't usually need any descriptor in the coreboot image.
- Add the bits necessary to produce a working GM45 image, by using ich9gen as documentation.
flashrom/ich_descriptors.[ch] might also be a good reference.
However, I believe as long as a user can't verify the code of such a tool against some official documentation, he has not only to trust the chip vendors + OEM but also the author of such a tool to run his machine. You'll just exchange a blob for a blob.
Nico
-
Denis 'GNUtoo' Carikli -
Nico Huber -
Nico Huber