Re: [coreboot] BIOS/CoreBoot/UBOOT

[Peter Stuge]

taii...@gmx.com wrote:
> >>> 3.  Support for Secure Boot - would one approach be simpler than another?
> >> SB was invented by MS for DRM, it serves no real security purpose IMO
> >
> > I'd like to ask you to reconsider that opinion.
> 
> It is a fact not an opinion.

You wrote "IMO", otherwise I probably wouldn't have tried to change
your opinion.


> SB was invented for DRM - to prevent people from using linux or god
> forbid doing something that hollywood doesn't like.
> "embrace, extend, extinguish"

I think you give non-Windows desktops far too much credit.

As for the content industry, I do have the impression that they are
super scared of losing their business model to a technologically
advanced society.

But I honestly don't see that as a big threat either. People will
continue to communicate and organize. The "community society" is
only just starting out. Youtube, reddit and Twitter are some of the
early tools. Influencers are already celebrities.


> Good things don't have to be forced on people, but the SB 2.0 specs have
> quietly left out the owner control mandate after the attention has died
> down.

I think you give the "attention" too much credit as well. I heard
(I've forgotten where, sorry) that MSFT tried to exclude the
possibility to disable Secure Boot right from the start.

They got their way for Windows RT Logo certification, but there was
too much pushback from OEMs for PC Windows Logo certification to do
it the first time around.

Remember that OEMs and most of all IBVs were super scared of UEFI
when it was being introduced, because they felt Intel's UEFI model
to be far too open, and that it would jeopardize their businesses.


> > But Secure Boot is also related to the security of individual computers
> > and computer users, because it enables Microsoft and OEMs to establish
> > a controllable, reliable and thus trustable chain of software from reset
> > to desktop.
> 
> So microsoft should control the whole computing ecosystem?

Of course not. But Microsoft has always controlled the whole ecosystem
around Windows, and they will continue to. It just wasn't quite as obvious
before.

The good news is that Microsoft Windows in many cases is, as you write,
an obsolete relic. :)


> should not be permitted to strangle the competition in the crib.

Mh - there's no competition to Windows. And the thing is, Microsoft
can continue to control the PC architecture, there will continue to
be others, and I think an important point is that for an organization
which considers replacing Windows having to replace some hardware
will only be a small bump in the road, not a blocker.


> > Most people who buy computers are happy, because controlling the computer
> > isn't as important as using the desktop
> 
> Why can't they simply provide people a choice? (ie: flip this switch to
> disable code signing enforcement)

They could, but why should they? It is not in their interest, nor in
the interest of Windows machine OEMs.


> Freedom is too dangerous? Hackers could turn their computer in to a bomb
> without secure boot?

MSFT is a corporation, by law it must care only about profit.


> > which I think is fine.
> 
> I am surprised someone here would think that, moreso you of all people.

Allow me to clarify.

It's fine that most people care more about using the desktop than
about controlling their computer.

By that I mean: Everyone can not be an expert at everything, and it's
important to have a diverse computing landscape with experts in many
fields of computing, from ISA over chip engineering to firmware and
the rest of the software stack, but it's *not* important that desktop
users are firmware experts.

It would be great for desktop users to question their firmware more,
and maybe that will happen, but computers are still very much magic.


It's fine that people begin to expect their computers to be reliable.
(This may be the best shift our society has seen wrt. IT in some time!)

It's fine that people buy technology which they feel allows them to do
more.

It's fine that customers trust their suppliers. It's fine that
suppliers offer products controlled by them and not by customers,
based on the argument that this makes products more trustworthy.


It would be great if all customers reject that argument, but all will
not, only some will, and that's fine too.


It's *not* fine to pretend that a Windows machine is anything else,
in particular a Windows machine is *not* a general purpose computer.

That used to hold true, but that was way before the time of that Treo.


It's *not* fine to advertise a Windows machine as a general purpose computer.


Having an interest in controlling technology is quite rare. This
seems very unfortunate to me in a society built increasingly around
technology, but I don't think it is actually anything new.

Educating people about the pillars of society is very important, but
even then, technology is just one of several.


> There will not be another future steve jobs 

Re: [coreboot] BIOS/CoreBoot/UBOOT

[Duncan]

Hello Taiidan,

taii...@gmx.com:
> On 04/12/2018 11:43 AM, Peter Stuge wrote:
>> taii...@gmx.com wrote:
 3.  Support for Secure Boot - would one approach be simpler than another?
>>> SB was invented by MS for DRM, it serves no real security purpose IMO
>> I'd like to ask you to reconsider that opinion.
>>
> It is a fact not an opinion.

This is certainly an opinion. There are multiple reasons why Secure Boot
came about, some of which were bad; others were not bad - Microsoft has
improved the security of their operating system quite a lot since the
days of Windows XP. And in any case, it is better than before from the
perspective of an end user.

> 
> SB was invented for DRM - to prevent people from using linux or god
> forbid doing something that hollywood doesn't like.
> "embrace, extend, extinguish"
> 
> Good things don't have to be forced on people, but the SB 2.0 specs have
> quietly left out the owner control mandate after the attention has died
> down.
>> Secure Boot is mandated by Microsoft to provide Microsoft and
>> Microsoft's customers (OEMs) security, and I think it's pretty
>> effective.
>>
>> But Secure Boot is also related to the security of individual computers
>> and computer users, because it enables Microsoft and OEMs to establish
>> a controllable, reliable and thus trustable chain of software from reset
>> to desktop.
> So microsoft should control the whole computing ecosystem? They are an
> obsolete relic that should not be permitted to strangle the competition
> in the crib.
>> Most people who buy computers are happy, because controlling the computer
>> isn't as important as using the desktop
> Why can't they simply provide people a choice? (ie: flip this switch to
> disable code signing enforcement)
> 
> Freedom is too dangerous? Hackers could turn their computer in to a bomb
> without secure boot?
>> which I think is fine.
>>
> I am surprised someone here would think that, moreso you of all people.
> 
> There will not be another future steve jobs or bill gates game changer
> decades from now just more mark zuckerberg's only allowed to make
> useless web apps.

Are developers not allowed to produce web applications? This makes no
sense.

> 
> Even wealthy families won't think to purchase their children a developer
> computer by default and when a kid sees a "you are not allowed to
> install this" message he/she will simply give up and go on to something
> else like be a lawyer instead of a computer engineer; although even that
> developer model won't allow someone true access they will only be
> allowed to create surface level programs not low level programs,
> kernels, or firmware.
> 
> I believe one day even you the expert will not be allowed to run the
> code you please at least not without buying a very expensive "developer
> edition" laptop.
> 
> People think that phones were always a walled garden but I am old enough
> to remember when programs were installed on a palm treo similarly to the
> win32 model where you download a file from a website and double click
> without requiring permission to install something on *your phone*.
> 

It is still possible to side-load applications on mobile phones -
Android still gives users this option. So do smaller mobile operating
systems, even Windows 10 Mobile (not Apple, though, sadly). Palm OS was
wholly proprietary; Android at least has its base system as open source,
and Google make large contributions to open source projects. The
situation is somewhat better now, and there is a stronger open source
software library behind Android than there ever was behind Palm OS.

Yet it's also a distraction, as it wasn't your actual point. The meat of
your actual email seems to be as follows:

> Let us hope the leaders of the future do not share your complacency or
> we are truly done for.
> 

This is perhaps somewhat eloquent. However, saying people on the list
are "complacent" strikes me as somewhat childish. I don't understand why
you said this - are we not allowed to disagree without attacking other
people's character? Yet I don't think this email is unique. I have seen
other examples on this list.

A good motto is, if you wouldn't say it to yourself without taking
offense, consider not saying it to others - when most people start to
follow this motto, we can have more civil discussion together.

All the best,
- Duncan

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[taii...@gmx.com]

On 04/12/2018 11:43 AM, Peter Stuge wrote:
> taii...@gmx.com wrote:
>>> 3.  Support for Secure Boot - would one approach be simpler than another?
>> SB was invented by MS for DRM, it serves no real security purpose IMO
> I'd like to ask you to reconsider that opinion.
>
It is a fact not an opinion.

SB was invented for DRM - to prevent people from using linux or god
forbid doing something that hollywood doesn't like.
"embrace, extend, extinguish"

Good things don't have to be forced on people, but the SB 2.0 specs have
quietly left out the owner control mandate after the attention has died
down.
> Secure Boot is mandated by Microsoft to provide Microsoft and
> Microsoft's customers (OEMs) security, and I think it's pretty
> effective.
>
> But Secure Boot is also related to the security of individual computers
> and computer users, because it enables Microsoft and OEMs to establish
> a controllable, reliable and thus trustable chain of software from reset
> to desktop.
So microsoft should control the whole computing ecosystem? They are an
obsolete relic that should not be permitted to strangle the competition
in the crib.
> Most people who buy computers are happy, because controlling the computer
> isn't as important as using the desktop
Why can't they simply provide people a choice? (ie: flip this switch to
disable code signing enforcement)

Freedom is too dangerous? Hackers could turn their computer in to a bomb
without secure boot?
> which I think is fine.
>
I am surprised someone here would think that, moreso you of all people.

There will not be another future steve jobs or bill gates game changer
decades from now just more mark zuckerberg's only allowed to make
useless web apps.

Even wealthy families won't think to purchase their children a developer
computer by default and when a kid sees a "you are not allowed to
install this" message he/she will simply give up and go on to something
else like be a lawyer instead of a computer engineer; although even that
developer model won't allow someone true access they will only be
allowed to create surface level programs not low level programs,
kernels, or firmware.

I believe one day even you the expert will not be allowed to run the
code you please at least not without buying a very expensive "developer
edition" laptop.

People think that phones were always a walled garden but I am old enough
to remember when programs were installed on a palm treo similarly to the
win32 model where you download a file from a website and double click
without requiring permission to install something on *your phone*.

Let us hope the leaders of the future do not share your complacency or
we are truly done for.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[David Hendricks]

On Thu, Apr 12, 2018 at 2:18 PM, <eche...@free.fr> wrote:

>
> - Mail d'origine -
> De: Peter Stuge <pe...@stuge.se>
> À: coreboot@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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[Zoran Stojsavljevic]

> 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 /build/tmp/deploy/images/ (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  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@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[Simon Glass]

Hi,

On 11 April 2018 at 16:39, Raymond Yeung  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=298b94e342e4cc389df587c45e8b4d067b0feaf3;hb=HEAD

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=7403be36146d2321b29d82bef306c9d322ab1910;hb=HEAD

> 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

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[Peter Stuge]

taii...@gmx.com wrote:
> > 3.  Support for Secure Boot - would one approach be simpler than another?
> 
> SB was invented by MS for DRM, it serves no real security purpose IMO

I'd like to ask you to reconsider that opinion.

Secure Boot is mandated by Microsoft to provide Microsoft and
Microsoft's customers (OEMs) security, and I think it's pretty
effective.

But Secure Boot is also related to the security of individual computers
and computer users, because it enables Microsoft and OEMs to establish
a controllable, reliable and thus trustable chain of software from reset
to desktop.

Most people who buy computers are happy, because controlling the computer
isn't as important as using the desktop, which I think is fine.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[ron minnich]

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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[Zaolin]

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.hendri...@gmail.com>
> *Sent:* Wednesday, April 11, 2018 6:03 PM
> *To:* Raymond Yeung
> *Cc:* coreboot@coreboot.org
> *Subject:* Re: [coreboot] BIOS/CoreBoot/UBOOT
>  
>
>
> On Wed, Apr 11, 2018 at 3:39 PM, Raymond Yeung <rksye...@hotmail.com
> <mailto:rksye...@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 :-)
>
>

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[taii...@gmx.com]

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.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[Raymond Yeung]

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.hendri...@gmail.com>
Sent: Wednesday, April 11, 2018 6:03 PM
To: Raymond Yeung
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] BIOS/CoreBoot/UBOOT



On Wed, Apr 11, 2018 at 3:39 PM, Raymond Yeung 
<rksye...@hotmail.com<mailto:rksye...@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 :-)
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[taii...@gmx.com]

On 04/11/2018 06:39 PM, Raymond Yeung 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.
Let us know what you are attempting to accomplish.
> I'm not familiar with this early stage of system initialization.  It seems 
> BIOS/UEFI to Linux needs to use PXE
Hm? do you want to boot over the network? why would you need PXE just to
boot linux on your local machine?
I believe there is a neat petietboot coreboot payload with some network
booting features that is better than PXEthere is also iSCSI as an
option of course either a coreboot payload or part of a networking card.
>  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.
I am sorry I do not understand what you wish to do?
> 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?
The issue isn't support for the CPU it is support for your board, there
are a few broadwell boards in coreboot but they are only development
boards with no board status so I have no idea if the platform port even
works.

FYI the hardware initiation for the newer intel stuff is done entirely
by intels FSP binary blob in case you are wondering so there isn't
really much to change or poke around with.
>   2.  Is it possible to go from BIOS/UEFI to UBOOT (on-board)?  How?
Without coreboot no it isn't.
>   3.  Support for Secure Boot - would one approach be simpler than another?
SB was invented by MS for DRM, it serves no real security purpose IMO
and such a thing is better served by for example a grub payload with
kernel code signing enabled where you sign your own kernels.
"pointless? why?" Any hypothetical rootkit could simply infect some
other key system component that is always loaded and used every time the
computer is running.
"DRM?" SB 2.0 has removed the owner control mandate from MS leaving
OEM's free to not offer it, eventually only "developer" computers that
cost much more will let you install linux leaving the next generation of
computer programmer kids out in the cold and only able to create
programs for windows in a walled gardeneven wealthy families
probably wouldn't know to get their kid a special computer and most
would just give up when faced with a "you cant do that" error.
>   4.  Am I even on the right track thinking this way?
Ports for coreboot cost a lot of money (think 50K+) or if you have the
necessary firmware development skills 6months+ of time and effort
honestly I would just buy a board that already has what you want if you
want to play around with firmware programming - the entirely open source
being the very fast TALOS 2 (factory libre firmware but not coreboot)
and the not as fast KGPE-D16 (libre coreboot and OpenBMC ports are
available) unfortunately "coreboot" in general no longer means open
source firmware for most boards so be aware if you want to buy something
else.

Anyways welcome to the community :]


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[David Hendricks]

On Wed, Apr 11, 2018 at 3:39 PM, Raymond Yeung  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.


>
>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 :-)
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] BIOS/CoreBoot/UBOOT

[Raymond Yeung]

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?
  2.  Is it possible to go from BIOS/UEFI to UBOOT (on-board)?  How?
  3.  Support for Secure Boot - would one approach be simpler than another?
  4.  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
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot