[coreboot] Porting Kabylake laptop

chrisglowaki at tutanota.com chrisglowaki at tutanota.com
Wed Jun 27 18:15:13 CEST 2018


Hi Ron, Nico, 
27. Jun 2018 15:35 by nico.h at gmx.de <mailto:nico.h at gmx.de>:


> On 27.06.2018 13:37, > chrisglowaki at tutanota.com <mailto:chrisglowaki at tutanota.com>>  wrote:
>> 26. Jun 2018 20:02 by >> rminnich at gmail.com <mailto:rminnich at gmail.com>>>  <>> mailto:rminnich at gmail.com <mailto:mailto:rminnich at gmail.com>>> >:
>>> For a case like this, where your choice is between two binary blobs (FSP
>>> or UEFI) I would argue that linuxboot is a better way to go.
>
> Question is, what is this "case"? Chris, what is your motivation for the
> coreboot port?
>
>>>
>>> See > github.com/osresearch/heads <>>> http://github.com/osresearch/heads <http://github.com/osresearch/heads>>>> >>
>>> or > linuxboot.org <>>> http://linuxboot.org <http://linuxboot.org>>>> >>  for more info.
>>> ron
>>
>> Doesn't linuxbootalso require the FSP blob for memory and silicon
>> initialization on any Intel board after Ivy Bridge?
>
> LinuxBoot is an ambiguous term. What Ron and Philipp suggest here is
> taking an existing UEFI, strip it down to something as light as core-
> boot and plug the Linux kernel in. If you just want to get rid of the
> bloated, often bug haunted, user visible parts of UEFI, this is a
> good way to achieve it. If you want more control over the earlier,
> lower level parts of the boot process, coreboot is the way to go, IMO.
>
> The convenient trick of UEFI/LinuxBoot is that you don't have to care
> about any mainboard specific things, if somebody else already ported
> UEFI for your board. And other than the name suggests, you can boot
> any other OS*, the Linux in LinuxBoot is just a fancy boot loader.

In my case the purpose of porting the laptop is security. LinuxBoot sounds very promising and if the coreboot port fails or is unstable it could be the only option. Please correct me if I'm wrong, but I think LinuxBoot doesn't give the same security as coreboot+FSP because it leaves the firmware vendor and board manufacturer in the trust equation. With the FSP we only have to trust Intel.




Thanks

Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180627/a5b10b40/attachment.html>


More information about the coreboot mailing list