coreboot April 2018

coreboot@coreboot.org

68 participants
128 discussions

Re : Re: Re : Re: BIOS/CoreBoot/UBOOT
by echelon＠free.fr 13 Apr '18

13 Apr '18

But I respect the opinions of Peter.. Florentin ----- Mail d'origine ----- De: echelon(a)free.fr À: David Hendricks <david.hendricks(a)gmail.com> Cc: Peter Stuge <peter(a)stuge.se>, Coreboot <coreboot(a)coreboot.org> Envoyé: Fri, 13 Apr 2018 00:18:00 +0200 (CEST) Objet: [coreboot] Re : Re: Re : Re: BIOS/CoreBoot/UBOOT It is the "IS FINE" that shocked (and saddened...) me ----- Mail d'origine ----- De: David Hendricks <david.hendricks(a)gmail.com> À: Florentin Demetrescu <echelon(a)free.fr> Cc: Peter Stuge <peter(a)stuge.se>, Coreboot <coreboot(a)coreboot.org> Envoyé: Fri, 13 Apr 2018 00:09:54 +0200 (CEST) Objet: Re: [coreboot] Re : Re: BIOS/CoreBoot/UBOOT On Thu, Apr 12, 2018 at 2:18 PM, <echelon(a)free.fr> wrote: > > ----- Mail d'origine ----- > De: Peter Stuge <peter(a)stuge.se> > À: coreboot(a)coreboot.org > Envoyé: Thu, 12 Apr 2018 17:43:48 +0200 (CEST) > Objet: Re: [coreboot] BIOS/CoreBoot/UBOOT > > ... > > Most people who buy computers are happy, because controlling the computer > > isn't as important as using the desktop, which I think IS FINE. > (emphasis mine) > ... > > It depends .. many people use their computer to access their online bank > accounts or to do operations with their bitcoin wallets. Would you be happy > knowing that someone from MS (could be a very decent person btw..) have > STEALTH access to your banking operations at every moment?... > What does this have to do secure boot, which is what Peter was talking about? I think we're all on the same page with regards to obscure privileged code and microcontrollers running in the system. But that's not what was being discussed. -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re : Re: Re : Re: BIOS/CoreBoot/UBOOT
by echelon＠free.fr 13 Apr '18

13 Apr '18

It is the "IS FINE" that shocked (and saddened...) me ----- Mail d'origine ----- De: David Hendricks <david.hendricks(a)gmail.com> À: Florentin Demetrescu <echelon(a)free.fr> Cc: Peter Stuge <peter(a)stuge.se>, Coreboot <coreboot(a)coreboot.org> Envoyé: Fri, 13 Apr 2018 00:09:54 +0200 (CEST) Objet: Re: [coreboot] Re : Re: BIOS/CoreBoot/UBOOT On Thu, Apr 12, 2018 at 2:18 PM, <echelon(a)free.fr> wrote: > > ----- Mail d'origine ----- > De: Peter Stuge <peter(a)stuge.se> > À: coreboot(a)coreboot.org > Envoyé: Thu, 12 Apr 2018 17:43:48 +0200 (CEST) > Objet: Re: [coreboot] BIOS/CoreBoot/UBOOT > > ... > > Most people who buy computers are happy, because controlling the computer > > isn't as important as using the desktop, which I think IS FINE. > (emphasis mine) > ... > > It depends .. many people use their computer to access their online bank > accounts or to do operations with their bitcoin wallets. Would you be happy > knowing that someone from MS (could be a very decent person btw..) have > STEALTH access to your banking operations at every moment?... > What does this have to do secure boot, which is what Peter was talking about? I think we're all on the same page with regards to obscure privileged code and microcontrollers running in the system. But that's not what was being discussed.

1 0

Re: [coreboot] BIOS/CoreBoot/UBOOT
by David Hendricks 13 Apr '18

13 Apr '18

On Thu, Apr 12, 2018 at 2:18 PM, <echelon(a)free.fr> wrote: > > ----- Mail d'origine ----- > De: Peter Stuge <peter(a)stuge.se> > À: coreboot(a)coreboot.org > Envoyé: Thu, 12 Apr 2018 17:43:48 +0200 (CEST) > Objet: Re: [coreboot] BIOS/CoreBoot/UBOOT > > ... > > Most people who buy computers are happy, because controlling the computer > > isn't as important as using the desktop, which I think IS FINE. > (emphasis mine) > ... > > It depends .. many people use their computer to access their online bank > accounts or to do operations with their bitcoin wallets. Would you be happy > knowing that someone from MS (could be a very decent person btw..) have > STEALTH access to your banking operations at every moment?... > What does this have to do secure boot, which is what Peter was talking about? I think we're all on the same page with regards to obscure privileged code and microcontrollers running in the system. But that's not what was being discussed.

1 0

Re: [coreboot] Re : Re: BIOS/CoreBoot/UBOOT
by Timothy Pearson 12 Apr '18

12 Apr '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Or Intel, or AMD, or Qualcomm, or Samsung, or Lenovo, or anyone else involved in the firmware stack really. It's a scary world out there these days! On 04/12/2018 04:18 PM, echelon(a)free.fr wrote: > > ----- Mail d'origine ----- > De: Peter Stuge <peter(a)stuge.se> > À: coreboot(a)coreboot.org > Envoyé: Thu, 12 Apr 2018 17:43:48 +0200 (CEST) > Objet: Re: [coreboot] BIOS/CoreBoot/UBOOT > > ... >> Most people who buy computers are happy, because controlling the computer >> isn't as important as using the desktop, which I think IS FINE. (emphasis mine) > ... > > It depends .. many people use their computer to access their online bank accounts or to do operations with their bitcoin wallets. Would you be happy knowing that someone from MS (could be a very decent person btw..) have STEALTH access to your banking operations at every moment?... > > Florentin > - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJaz9YLAAoJEK+E3vEXDOFbbvEIAIMnwbqx5CfsVJKf9zJOT7S0 twJMeCO/x6Lav3jMPno/+3So6778w5VNkGEJUJagN4S/0GynnVO5hl8q6NNrNs0B Dj/BJV3gBZhHGW2gzh7EgxIjW3a0GCOkU80rWfMI/FSB5mdveDhPy+TLei3Cebsr URqyJD7L21Ee9UVyxFn9JrR+oN7LzyVEvk12AgWY5fE0qSDC8tW8MwIqelZSWKke trq6UpyUWT1sMKWSn3dKJMV6TYcTdzVrVWddVfkNAymPc1dPi2B1Dl3iRjvQ4JPa 3BVBpF6uTN8Tz86J6IYQ3Pm244Kyq6DvUkuMcL1xM47G0atggv+MmOzQ1hrylcM= =Jkbd -----END PGP SIGNATURE-----

1 0

Re: [coreboot] BIOS/CoreBoot/UBOOT
by Zoran Stojsavljevic 12 Apr '18

12 Apr '18

> Is it possible to go from BIOS/UEFI to UBOOT (on-board)? How? Actually, since you are using, after all, YOCTO Project to build your BDX-DE BSP, you can freely use U-Boot, if Bin Meng (U-Boot BSP maintainer) already integrated BDX-DE/Camelback CRB's FSP into U-Boot. If? Bin, Did you integrate FSP to U-Boot for BDX-DE (Camelback CRB)? _______ The good thing about this approach is that: [1] You will follow YOCTO unwritten protocol. since you can find all the rootfs and other elements in <project name>/build/tmp/deploy/images/<platform_name> (where the platform name is in your case: intel-corei7-64, since you have added meta-intel into the YOCTO layering); [2] U-Boot is a standard ingredient of YOCTO layering, whereas for Coreboot I would not say so, (much) easier to handle U-Boot; [3] Do NOT listen about the linuxboot bootloader, since you need to create your own YOCTO mate-bsp layer with linuxboot specifics; [4] If you use Lava framework for the BSP testing, U-Boot is (definitely) your saviour! Best Regards, Zoran _______ On Thu, Apr 12, 2018 at 4:37 PM, ron minnich <rminnich(a)gmail.com> wrote: > At this point, on this platform, I think your fastest bet to mostly open > sourcing it all is linuxboot. We recently had an experience where we > installed a linux kernel in FLASH on two new boards in two days and most of > that was just figuring out how to rearrange the UEFI bits, (i.e. move the > furniture around :-) not building code. You can now replace a lot of UEFI > with a linux kernel and the only thing you have to build is ... a Linux > kernel. > > We recently found that for supported boards, a git clone of the linuxboot > repo and full build takes 2 minutes 45 seconds, and that's essentially hands > off. > > If you have a UEFI system, which that board almost certainly is, I think you > can skip coreboot and u-boot entirely and just take the linuxboot approach. > I'm no longer that big a fan of FSP, it has its own problems. > > I realize in this note there's a lot of "Alphabet soup" (many, many names > like UEFI and FSP and all ...) but the short form is this: with modern x86 > CPUs, the coreboot port is indeed a very large effort. The linuxboot effort > is, as mentioned, as little as a day in some cases. I can tell you from > experience it is far less work and, ironically, can also result in the use > of fewer binary blobs on these CPUs. > > Obviously, for open CPUs, I still prefer coreboot; but x86 CPUs are no > longer open in any meaningful sense of the word. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] BIOS/CoreBoot/UBOOT
by Simon Glass 12 Apr '18

12 Apr '18

Hi, On 11 April 2018 at 16:39, Raymond Yeung <rksyeung(a)hotmail.com> wrote: > > I currently have a board that uses Intel Xeon D (previously codenamed Broadwell DE). It boots up with BIOS/UEFI. I 'm exploring other oot-up options here. > > > I'm not familiar with this early stage of system initialization. It seems BIOS/UEFI to Linux needs to use PXE, with the need to configure DHCP (and possibly Proxy DHCP), TFTP server PXELINUX, Linux initial RAM disk (initrd) configuration file, and then Linux. Previously, I'd been using Coreboot/UBOOT environment (as a user, not developer). Prerequisite seemed much simpler. > > > A few questions - > > > Is there even a coreboot support for this CPU already available and stable that I could download and reflash? Or are we talking about some serious re-development? > Is it possible to go from BIOS/UEFI to UBOOT (on-board)? How? Yes, this is supported in mainline U-Boot. It builds U-Boot as a payload for UEFI to load. Overview here: https://www.denx.de/wiki/U-Boot/X86 Full details here: http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.u-boot_on_efi;h=298b94… It is also possible to boot EFI applications (e.g. grub) on U-Boot: http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.uefi;h=7403be36146d232… > Support for Secure Boot - would one approach be simpler than another? U-Boot has a secure boot implementation. > Am I even on the right track thinking this way? > > > Please let me know if this has already been discussed to the death here (or elsewhere), and would appreciate a link/reference. > > > Thanks, > > Raymond Regards, Simon

1 0

Re: [coreboot] BIOS/CoreBoot/UBOOT
by Zaolin 12 Apr '18

12 Apr '18

Hey Raymond, you can now start to ship coreboot with LinuxBoot easily https://review.coreboot.org/#/c/coreboot/+/23071/. Which gives you a whole Linux environment instead of TFTP. See www.linuxboot.org for more details. Regarding my work, I have implemented measured boot support into coreboot. You can already use Google's verified boot without pulling changes from coreboot gerrit review. If you want to have a deeper look into VBoot2, checkout: https://www.youtube.com/watch?v=4EvTcfcYfMY We covered this aspect since 2010 ;) Also if you have questions or problems you can talk to us via IRC, my IRC handle is zaolin. Happy Hacking, Philipp On 12.04.2018 03:54, Raymond Yeung wrote: > > Thanks David for the detailed response. > > > My main motivation to go down Coreboot/UBOOT route is to attempt to > simplify the remaining boot-up to Linux. Instead of using PXE-BOOT, > we could use tftp only. Am I correct to say that? > > > If we're to use whatever that is available today, instead of waiting > for Philipp's work to complete, does coreboot/UBOOT provide secure > boot support? I'd tend to think so, but want to confirm. UEFI seems > to already have this aspect covered. > > > Raymond > > > > ------------------------------------------------------------------------ > *From:* David Hendricks <david.hendricks(a)gmail.com> > *Sent:* Wednesday, April 11, 2018 6:03 PM > *To:* Raymond Yeung > *Cc:* coreboot(a)coreboot.org > *Subject:* Re: [coreboot] BIOS/CoreBoot/UBOOT > > > > On Wed, Apr 11, 2018 at 3:39 PM, Raymond Yeung <rksyeung(a)hotmail.com > <mailto:rksyeung@hotmail.com>> wrote: > > I currently have a board that uses Intel Xeon D (previously > codenamed Broadwell DE). It boots up with BIOS/UEFI. I 'm > exploring other oot-up options here. > > > I'm not familiar with this early stage of system initialization. > It seems BIOS/UEFI to Linux needs to use PXE, with the need to > configure DHCP (and possibly Proxy DHCP), TFTP server PXELINUX, > Linux initial RAM disk (initrd) configuration file, and then > Linux. Previously, I'd been using Coreboot/UBOOT environment (as > a user, not developer). Prerequisite seemed much simpler. > > > A few questions - > > > 1. Is there even a coreboot support for this CPU already > available and stable that I could download and reflash? Or > are we talking about some serious re-development? > > > Yes - See src/mainboard/intel/camelbackmountain_fsp/ for the reference > platform. > > You'll need the Intel FSP blob from > https://github.com/IntelFsp/FSP/tree/Broadwell-DE > <https://github.com/IntelFsp/FSP/tree/Broadwell-DE>. You'll also need > microcode which you can download from developer.intel.com > <http://developer.intel.com>. > > > 1. Is it possible to go from BIOS/UEFI to UBOOT (on-board)? How? > > > I haven't tried uboot as a payload, but yes, it is possible. There are > other options available to consider depending on your use case. > > > 1. Support for Secure Boot - would one approach be simpler than > another? > > > It depends on what you want/need. Philipp Deppenwiese is working on > "vboot" (Google's verified boot implementation) integration with > upstream: https://review.coreboot.org/#/c/coreboot/+/24993/ > > More about that approach > here: https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot > > > 1. Am I even on the right track thinking this way? > > > You seem to be off to a good start :-) > >

2 1

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?
by Rudolf Marek 12 Apr '18

12 Apr '18

Hi, What do you want to protect? If you want to protect the kernel, retpolines are OK on AMD. And you don't need any microcode update. Your CPU needs to have SMEP, otherwise you would need to clear RSB on CPL change (the paper on mentined page says that you need to do that always, but at least on Ryzen, the attack using RSB is not working (we tried that out, maybe it works only on some circumstances). If you want to protect userspace, the RSB will be clear by IBPB (which you would need if you don't have userspace compiled with retpolines). I don't know if intel clears RSB on IBPB... probably not To sum it up on AMD: kernel: retpolines, RSB clear on CPL change on CPU without SMEP (see above) userspace: retpolines, RSB clear on context switch necessary or IBPB (needs microcode update). Plus make sure you enable "LFENCE is dispatch serializing" - perhaps coreboot can do that :) it is simple MSR write on fam 10h 12h+ the fam 11h and 0fh dont have this MSR but LFENCE is dispatch serilizing. Besides that, you don't need any microcode update. Plus of course there is a spectre variant 1, which is more difficult to mitigate, basically you need to check all the software and look for any pattern like array_x[array_z[untrusted_index] * any transformation]. The first access would leak just address (ASLR defated), second will leak data. The variant 1 works on user/user attack and as well as user/kernel. As far I know there are no automated tools to check for this. Thanks Rudolf Dne 18.2.2018 v 12:48 Mike Banon napsal(a): > Maybe its' a good idea to write to AMD support regarding this question > - please share a reply if you would get an answer. I'm curious about > other fam15 CPUs as well, e.g. A10-5750M microcode update would be > nice, maybe a request could be more general, e.g. : what is the > estimated release date for the microcode updates for fam15 AMD CPUs > (so a request is not about "opterons only") > > On Sun, Feb 18, 2018 at 2:47 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: >> Maybe its' a good idea to write to AMD support regarding this question >> - please share a reply if you would get an answer. I'm curious about >> other fam15 CPUs as well, e.g. A10-5750M microcode update would be >> nice, maybe a request could be more general, e.g. : what is the >> estimated release date for the microcode updates for fam15 AMD CPUs >> (so a request is not about "opterons only") >> >> On Sun, Feb 18, 2018 at 4:30 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >>> They said they would be releasing opteron microcode updates in a few weeks >>> but it has been over a month and I am wondering when this is going to happen >>> or if it already has and I should re-compile coreboot? >>> >>> https://www.amd.com/en/corporate/speculative-execution >>> "We expect to make updates available for our previous generation products >>> over the coming weeks." >>> >>> Thanks! >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot >

3 4

Re: [coreboot] BIOS/CoreBoot/UBOOT
by Taiidan＠gmx.com 12 Apr '18

12 Apr '18

On 04/11/2018 09:54 PM, Raymond Yeung wrote: > Thanks David for the detailed response. > > > My main motivation to go down Coreboot/UBOOT route is to attempt to simplify the remaining boot-up to Linux. Instead of using PXE-BOOT, we could use tftp only. Am I correct to say that? If you want to boot over the network you should look in to petietboot I heard it is much better. > If we're to use whatever that is available today, instead of waiting for Philipp's work to complete, does coreboot/UBOOT provide secure boot support? I'd tend to think so, but want to confirm. UEFI seems to already have this aspect covered. Like I said I don't believe it is useful but if you want kernel code signing enforcement you can use the grub payload that supports signing for kernel/initramfs.

1 0

Re: [coreboot] BIOS/CoreBoot/UBOOT
by Raymond Yeung 12 Apr '18

12 Apr '18

Thanks David for the detailed response. My main motivation to go down Coreboot/UBOOT route is to attempt to simplify the remaining boot-up to Linux. Instead of using PXE-BOOT, we could use tftp only. Am I correct to say that? If we're to use whatever that is available today, instead of waiting for Philipp's work to complete, does coreboot/UBOOT provide secure boot support? I'd tend to think so, but want to confirm. UEFI seems to already have this aspect covered. Raymond ________________________________ From: David Hendricks <david.hendricks(a)gmail.com> Sent: Wednesday, April 11, 2018 6:03 PM To: Raymond Yeung Cc: coreboot(a)coreboot.org Subject: Re: [coreboot] BIOS/CoreBoot/UBOOT On Wed, Apr 11, 2018 at 3:39 PM, Raymond Yeung <rksyeung(a)hotmail.com<mailto:rksyeung@hotmail.com>> wrote: I currently have a board that uses Intel Xeon D (previously codenamed Broadwell DE). It boots up with BIOS/UEFI. I 'm exploring other oot-up options here. I'm not familiar with this early stage of system initialization. It seems BIOS/UEFI to Linux needs to use PXE, with the need to configure DHCP (and possibly Proxy DHCP), TFTP server PXELINUX, Linux initial RAM disk (initrd) configuration file, and then Linux. Previously, I'd been using Coreboot/UBOOT environment (as a user, not developer). Prerequisite seemed much simpler. A few questions - 1. Is there even a coreboot support for this CPU already available and stable that I could download and reflash? Or are we talking about some serious re-development? Yes - See src/mainboard/intel/camelbackmountain_fsp/ for the reference platform. You'll need the Intel FSP blob from https://github.com/IntelFsp/FSP/tree/Broadwell-DE. You'll also need microcode which you can download from developer.intel.com<http://developer.intel.com>. 1. Is it possible to go from BIOS/UEFI to UBOOT (on-board)? How? I haven't tried uboot as a payload, but yes, it is possible. There are other options available to consider depending on your use case. 1. Support for Secure Boot - would one approach be simpler than another? It depends on what you want/need. Philipp Deppenwiese is working on "vboot" (Google's verified boot implementation) integration with upstream: https://review.coreboot.org/#/c/coreboot/+/24993/ More about that approach here: https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot 1. Am I even on the right track thinking this way? You seem to be off to a good start :-)

1 0

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2018