<div dir="ltr"><span style="font-size:12.8px">> I was not reminding you, I was talking to Zoran Stojsavljevic.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Hello Denis, Nico,<br></span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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). :-(</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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. ;-)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thank you,</span></div><div><span style="font-size:12.8px">Zoran</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 29, 2017 at 10:52 AM, Denis 'GNUtoo' Carikli <span dir="ltr"><<a href="mailto:GNUtoo@no-log.org" target="_blank">GNUtoo@no-log.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 28 Mar 2017 19:05:15 +0200<br>
Nico Huber <<a href="mailto:nico.h@gmx.de">nico.h@gmx.de</a>> wrote:<br>
<br>
[...]<br>
<span class="">> > (3) Having a boot firmware without the management engine firmware.<br>
> ><br>
> > It is strongly advised to do (3) and follow the corresponding<br>
> > coreboot documentation.<br>
><br>
> Strongly advised by who? In which scenario? Under which assumptions?<br>
<br>
</span><a href="https://www.coreboot.org/Board:lenovo/x200#Without_ME.2FAMT" rel="noreferrer" target="_blank">https://www.coreboot.org/<wbr>Board:lenovo/x200#Without_ME.<wbr>2FAMT</a> has:<br>
> The ME is a potential security and privacy risk, so removing it is<br>
> preferable. Removing it also means that the BIOS region can fill most<br>
> of the flash chip, giving plenty of flashing space (example use-case<br>
> scenario: BusyBox+Linux system in SPI flash, to be used as a live<br>
> rescue system).<br>
<span class=""><br>
> > To get a working Ethernet with (3) you need to set a<br>
> > valid mac address:<br>
> > In the installation documentation, you are expected to use ich9gen,<br>
> > however if you use it this way:<br>
> >> $ ./ich9gen<br>
> > It will not produce a valid MAC address. You must instead do<br>
> > something like that, and replace <A-VALID-MAC-ADDRESS> by a valid<br>
> > MAC address:<br>
> >> $ ./ich9gen --macaddress <A-VALID-MAC-ADDRESS><br>
> > To find such MAC address, you have several options:<br>
> > - Look if it can be found on a sticker on the bottom of your laptop.<br>
> > - Reflash the original flash content and get it with:<br>
> >> $ ifconfig -a<br>
> > or:<br>
> >> ip link<br>
><br>
> Pew, thanks for reminding me, that we have this in our wiki.<br>
</span>I was not reminding you, I was talking to Zoran Stojsavljevic.<br>
That said, it indeed would have been faster for me to point to the wiki<br>
resources.<br>
<span class=""><br>
> > == Side note ==<br>
> > According to the wikipedia article on MAC Address[1], the 3 bytes on<br>
> > the left correspond to a vendor/organisation.<br>
> > So I got a valid MAC address with the methods mentioned above, and<br>
> > only kept the 3 bytes on the left, and tested that MAC address:<br>
> >> 00:1f:16:00:00:00<br>
> > And it worked on my Lenovo Thinkpad X200.<br>
> > To use that MAC address, just use:<br>
> >> $ ./ich9gen --macaddress<br>
> ><br>
> > It might be possible that all addresses between 00:1f:16:00:00:00<br>
> > and 00:1f:16:FF:FF:FF work, but I didn't test that.<br>
><br>
> If you read that article, you might learn that any but the broadcast<br>
> ad- dress should work, as long as it's unique on the local network<br>
> segment.<br>
</span>What I said is indeed missleading, what I meant to say was that, if my<br>
memory is correct, using any MAC address in the flash descriptor will<br>
not work, and that the hardware has more restrictions than what you<br>
would expect. Note I didn't test the extent of the restrictions.<br>
<br>
If it is important/relevant, I can do some tests to help clarify that,<br>
or find that I was mistaken or that my memory is not as good as I<br>
though.<br>
<span class=""><br>
> Also, that your address claims to be globally unique. Which<br>
> might not be the best idea.<br>
</span>Indeed, it depends on the use case, using the MAC address assigned to<br>
the hardware by its manufacturer:<br>
(+) Has way more probability of being globally unique, and unique on the<br>
    local network. This is very relevant if the operating system or any<br>
    boot software(like iPXE) using the Ethernet "card" doesn't randomize<br>
    MAC address afterward. Certain GNU/Linux distros and operating<br>
    systems randomize the MAC address by default.<br>
(-) We have reproducible builds in coreboot. Setting the original MAC<br>
    address in the flash makes it harder to verify the images. You then<br>
    have to resort to binary diffing, with tools like vbindiff.<br>
<span class="HOEnZb"><font color="#888888"><br>
Denis.<br>
</font></span><br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br></blockquote></div><br></div>