I was not reminding you, I was talking to Zoran Stojsavljevic.
Hello Denis, Nico,
I read these emails, but, unfortunately, nothing to add, from my side of the story. Since I am also learning, so, please, do not quarrel (as I very often do). I do find excuse for myself (too old and too stubborn, sometimes too much beer for the evening). :-(
I will be glad (upon ask) for anyone on this list to analyze kernel dmegs and Xorg.0.log with Coreboot as boot-loader. Adds to my knowledge, since I do understand that I have (Coreboot wise, at least, but not the last) some gaps, I need to fill in. ;-)
Thank you, Zoran
On Wed, Mar 29, 2017 at 10:52 AM, Denis 'GNUtoo' Carikli GNUtoo@no-log.org wrote:
On Tue, 28 Mar 2017 19:05:15 +0200 Nico Huber nico.h@gmx.de wrote:
[...]
(3) Having a boot firmware without the management engine firmware.
It is strongly advised to do (3) and follow the corresponding coreboot documentation.
Strongly advised by who? In which scenario? Under which assumptions?
https://www.coreboot.org/Board:lenovo/x200#Without_ME.2FAMT has:
The ME is a potential security and privacy risk, so removing it is preferable. Removing it also means that the BIOS region can fill most of the flash chip, giving plenty of flashing space (example use-case scenario: BusyBox+Linux system in SPI flash, to be used as a live rescue system).
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.
== Side note == According to the wikipedia article on MAC Address[1], the 3 bytes on the left correspond to a vendor/organisation. So I got a valid MAC address with the methods mentioned above, and only kept the 3 bytes on the left, and tested that MAC address:
00:1f:16:00:00:00
And it worked on my Lenovo Thinkpad X200. To use that MAC address, just use:
$ ./ich9gen --macaddress
It might be possible that all addresses between 00:1f:16:00:00:00 and 00:1f:16:FF:FF:FF work, but I didn't test that.
If you read that article, you might learn that any but the broadcast ad- dress should work, as long as it's unique on the local network segment.
What I said is indeed missleading, what I meant to say was that, if my memory is correct, using any MAC address in the flash descriptor will not work, and that the hardware has more restrictions than what you would expect. Note I didn't test the extent of the restrictions.
If it is important/relevant, I can do some tests to help clarify that, or find that I was mistaken or that my memory is not as good as I though.
Also, that your address claims to be globally unique. Which might not be the best idea.
Indeed, it depends on the use case, using the MAC address assigned to the hardware by its manufacturer: (+) Has way more probability of being globally unique, and unique on the local network. This is very relevant if the operating system or any boot software(like iPXE) using the Ethernet "card" doesn't randomize MAC address afterward. Certain GNU/Linux distros and operating systems randomize the MAC address by default. (-) We have reproducible builds in coreboot. Setting the original MAC address in the flash makes it harder to verify the images. You then have to resort to binary diffing, with tools like vbindiff.
Denis.
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot