Re: [coreboot] Looking for a volunteer to add Fam15h spectre MSR to coreboot

[Arthur Heymans]

Mike Banon  writes:

> Line 869 - "const int amd_erratum_319[] =" --- is this code really
> against the Spectre, or its more like against the erratas in general?
> Also, What if someone would like to use either a Linux distro which
> hasnt been upgraded to the latest kernels, or maybe some alternative
> OS like FreeDOS or Kolibri? I think Taiidan has a good point: the
> availability of protection from this vulnerability should not depend
> on your OS and the version of your Linux kernel.
>

I disagree, the OS and the systems proper operation should depend as
little as possible on the firmware and coreboot generally follows the
philosophy of doing as little as possible. Note that a lot of other
errata get fixed in the kernel as well already. Depending on firmware
for safe operation of outdated or legacy OS seems silly to me...

OTOH there already is some overlap between coreboot and the OS with
stuff like updating microcode which is not always needed...

> Are there any existing MSR writes inside the coreboot code, so that
> they could be copied and modified into the MSR of Taiidan's interest?
> (MSR C001_1029[1]=1) Maybe that MSR write would even be a C code
> 1-liner?
>
Yes that is quite easy to do, but there is other functionality in that
MSR that is needed for instance when setting up CAR, so care needs to be
taken where this happens. I haven't looked it up but it could also be a
per AP MSR in which case it needs to be programmed on each AP...

Kind regards

-- 
==
Arthur Heymans

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

Re: [coreboot] Looking for a volunteer to add Fam15h spectre MSR to coreboot

[Mike Banon]

Line 869 - "const int amd_erratum_319[] =" --- is this code really
against the Spectre, or its more like against the erratas in general?
Also, What if someone would like to use either a Linux distro which
hasnt been upgraded to the latest kernels, or maybe some alternative
OS like FreeDOS or Kolibri? I think Taiidan has a good point: the
availability of protection from this vulnerability should not depend
on your OS and the version of your Linux kernel.

Are there any existing MSR writes inside the coreboot code, so that
they could be copied and modified into the MSR of Taiidan's interest?
(MSR C001_1029[1]=1) Maybe that MSR write would even be a C code
1-liner?

Best regards,
Mike Banon

On Tue, Apr 10, 2018 at 3:32 AM, Arthur Heymans  wrote:
> Hi
>
> Linux already does that for you: (v4.16) arch/x86/kernel/cpu/amd.c line 869.
>
>
> Kind regards
>
>
> On 5 April 2018 00:51:30 GMT+02:00, "taii...@gmx.com" 
> wrote:
>>
>> As I am not a programmer I do not know how to do this (thanks for the
>> heads-up rmarek) nor am I permitted to add to the repos.
>>
>> MITIGATION G-2
>> Description: Set an MSR in the processor so that LFENCE is a dispatch
>> serializing instruction and then
>> use LFENCE in code streams to serialize dispatch (LFENCE is faster than
>> RDTSCP which is also dispatch
>> serializing).
>>
>> This mode of LFENCE may be enabled by setting MSR C001_1029[1]=1.
>>
>> This is important and covers a variety of boards such as the KGPE-D16,
>> KCMA-D8 and G505s (all the last and best owner controlled x86_64 systems)
>>
>
> --
> Arthur Heymans
>
> --
> 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] KGPE-D16 / Problem booting with two CPUs

[Elisenda Cuadros]

Thank you for your reply Timothy.

Vendor Bios doesn't print any special message regarding this.

In fact it shows a total of 28 cores (16+12).

I thought mixing CPUs from same families was supported.

Regards,

- Eli

On 11/04/18 20:44, Timothy Pearson wrote:
> I don't know if coreboot has support for differing CPUs in the same
> mainboard; it's not something I can recall testing at any point.
>
> The failure is occurring far before memory initialization, in CAR, in
> core setup.  I'd guess it has something to do with the two CPUs you have
> installed having different core counts.
>
> Does the vendor BIOS print a message about the core count being limited
> on one of the CPUs for compatibility reasons?
>
> On 04/11/2018 12:57 PM, Elisenda Cuadros wrote:
> > Hello,
>
> > After testing the board for some weeks I bought another CPU (6276). I
> > installed this into CPU1 slot and a 6238 in CPU2.
>
> > I checked that both CPUs are shining and also the memory (Micron
> > MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).
>
> > The problem is that Coreboot seems to hang at the beginning. I attach
> > console.log.
>
> > I reinstalled all the devices twice, checked the vendor manual, docs in
> > coreboot.org, messages in mailing list, but I don't know what is causing
> > the problem.
>
> > Last test I've done is booting with vendor bios, and it boots without
> > problem.
>
> > Any ideas?
>
> > Thank you for your help.
>
> > Regards,
>
> > - Eli
>
>
>
>
>
>



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

[coreboot] KGPE-D16 / Problem booting with two CPUs

[Elisenda Cuadros]

Hello,

After testing the board for some weeks I bought another CPU (6276). I
installed this into CPU1 slot and a 6238 in CPU2.

I checked that both CPUs are shining and also the memory (Micron
MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).

The problem is that Coreboot seems to hang at the beginning. I attach
console.log.

I reinstalled all the devices twice, checked the vendor manual, docs in
coreboot.org, messages in mailing list, but I don't know what is causing
the problem.

Last test I've done is booting with vendor bios, and it boots without
problem.

Any ideas?

Thank you for your help.

Regards,

- Eli





coreboot-4.7-542-g39e1ab1d25-dirty Sun Mar 18 10:53:23 UTC 2018 romstage starting...
Initial stack pointer: 000dffb8
CPU APICID 00 start flag set
BSP Family_Model: 00600f12
*sysinfo range: [000c2d40,000cd2ac]
bsp_apicid = 00
cpu_init_detectedx = 
sb700 reset flags: 
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'microcode_amd.bin'
CBFS: Found @ offset 75400 size 318c
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'microcode_amd_fam15h.bin'
CBFS: Found @ offset 78600 size 1ec4
[microcode] patch id to apply = 0x0600063d
[microcode] updated to patch id = 0x0600063d success
cpuSetAMDMSR CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
 done
Enter amd_ht_init
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 2 new node: 1
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 0 new node: 2
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 3 new node: 3
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
Forcing HT links to isochronous mode due to enabled IOMMU
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
Exit amd_ht_init
amd_ht_fixup
amd_ht_fixup: node 0 (internal node ID 0): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 1 (internal node ID 1): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 2 (internal node ID 0): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 3 (internal node ID 1): disabling defective HT link (L3 connected: 1)
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
cpuSetAMDPCI 02 done
cpuSetAMDPCI 03 done
Prep FID/VID Node:00
  F3x80: e20be281
  F3x84: 01e200e2
  F3xD4: c3312f17
  F3xD8: 0316
  F3xDC: 05475632
Prep FID/VID Node:01
  F3x80: e20be281
  F3x84: 01e200e2
  F3xD4: c3312f17
  F3xD8: 0316
  F3xDC: 05475632
Prep FID/VID Node:02
  F3x80: e20be281
  F3x84: 01e200e2
  F3xD4: c3312f1a
  F3xD8: 0316
  F3xDC: 05475632
Prep FID/VID Node:03
  F3x80: e20be281
  F3x84: 01e200e2
  F3xD4: c3312f1a
  F3xD8: 0316
  F3xDC: 05475632
setup_remote_node: 01 done
Start node 01 done.
setup_remote_node: 02 done
Start node 02 done.
setup_remote_node: 03 done
Start node 03 done.
core0 started:  01 02

coreboot-4.7-542-g39e1ab1d25-dirty Sun Mar 18 10:53:23 UTC 2018 romstage starting...
Initial stack pointer: 000dffb8
CPU APICID 00 start flag set
BSP Family_Model: 00600f12
*sysinfo range: [000c2d40,000cd2ac]
bsp_apicid = 00
cpu_init_detectedx = 
sb700 reset flags: 
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'microcode_amd.bin'
CBFS: Found @ offset 75400 size 318c
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'microcode_amd_fam15h.bin'
CBFS: Found @ offset 78600 size 1ec4
[microcode] patch id to apply = 0x0600063d
[microcode] updated to patch id = 0x0600063d success
cpuSetAMDMSR CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
 done
Enter amd_ht_init
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 2 new node: 1
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 0 new node: 2
AMD_CB_EventNotify: INFO: HT_EVENT_COH_NODE_DISCOVERED: node 0 link 3 new node: 3
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
Forcing HT links to isochronous mode due to enabled IOMMU
CBFS: 'Master Header Locator' located CBFS at [e00200:c0)
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 2c100 size dc4
Exit amd_ht_init
amd_ht_fixup
amd_ht_fixup: node 0 (internal node ID 0): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 1 (internal node ID 1): disabling defective HT link (L3 connected: 1)
amd_ht_fixup: node 2 (internal node ID 0): 

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I don't know if coreboot has support for differing CPUs in the same
mainboard; it's not something I can recall testing at any point.

The failure is occurring far before memory initialization, in CAR, in
core setup.  I'd guess it has something to do with the two CPUs you have
installed having different core counts.

Does the vendor BIOS print a message about the core count being limited
on one of the CPUs for compatibility reasons?

On 04/11/2018 12:57 PM, Elisenda Cuadros wrote:
> Hello,
> 
> After testing the board for some weeks I bought another CPU (6276). I
> installed this into CPU1 slot and a 6238 in CPU2.
> 
> I checked that both CPUs are shining and also the memory (Micron
> MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).
> 
> The problem is that Coreboot seems to hang at the beginning. I attach
> console.log.
> 
> I reinstalled all the devices twice, checked the vendor manual, docs in
> coreboot.org, messages in mailing list, but I don't know what is causing
> the problem.
> 
> Last test I've done is booting with vendor bios, and it boots without
> problem.
> 
> Any ideas?
> 
> Thank you for your help.
> 
> Regards,
> 
> - Eli
> 
> 
> 
> 


- -- 
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

iQEcBAEBAgAGBQJazleSAAoJEK+E3vEXDOFbrFcH/i6xBhUGli6lYBXFM4d29CW7
UH6Z1Ksr2bD5jNfoKd1bmLx61w0KdG6Fyt/AmFr4dNXmAxTzuudw1ZZxauZe21Sk
neJfuoMtctq/YQTaliMhPawO+6vARiVdNUYaMmDZO6cf4h9252WdpBU99JCJsbhC
BkcIApR+0resb6iO2XpbPelnMA4yjitpgonXqKbVI6OvdYz5b3NViytCKcHunyzc
7H/GzpS93K1hWs7kLdNCJ7J7M0BtUSh2pGu/uaqr1ZSXWZgwBeQGESMG7etpT1Ju
LP+e8C9dm0iLiTS8FIond8WUu4Q4bt7ebAqohrNQoMRpYlmyHWgEVSzecddqMJM=
=ke+3
-END PGP SIGNATURE-

-- 
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

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

That should work, yes.  It's the very early init code that is getting
confused with the differing core counts, likely related to APIC setup or
similar.

On 04/11/2018 03:26 PM, taii...@gmx.com wrote:
> But it would be possible to have two CPU's with the same core count but
> differing frequencies?
> 
> Thanks
> 


- -- 
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

iQEcBAEBAgAGBQJaznCJAAoJEK+E3vEXDOFbfqsH+wegvs3Zu2ZNrM+W54LFXB7U
qVv4eAomKhPsf2UY5XzwhxVqzDn81PFI3HbMolfOwhNu/MfYeJIX7uxSdbMFReSH
3DF2808zOVaPQ5GdK3+dtNz7csM9pSTJUAIXPuDmRRYczrbDGEGYIP2OhMku+12x
b8X2iUVRDk0C9s/Rou+p9dEgJiH/xAf47X8L4BHzf8jna2IrY6WJgJiUvK2wxVx+
fahO6au24/yRsNfsdaG7Ax+1GXQF7imlcL7z1zM0JxQjt1OHExjClW/klaNEshjc
Wn+ebc77Blw6+klh7PdSkzs5nIQ3kCIoQuP9KvR0zbiWdmYKzj5NPk2awKAUTbg=
=P/vl
-END PGP SIGNATURE-

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

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[taii...@gmx.com]

But it would be possible to have two CPU's with the same core count but
differing frequencies?

Thanks


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

[coreboot] Runtime config

[bartek.pastudzki 3mdeb.com]

Hi

We have runtime configuration arguments implemented for our platform in out 
fork.
This is very simple, we just add few lines in SeaBIOS configuration file on CBFS
(https://bit.ly/2qmX9nT — config example, https://bit.ly/2v5Era6 — handling 
code).
There are only boolean values, no syntax, config file of constant size. Perhaps
too simple, but it serves its purpose. We use it to enable/disable additional 
UART,
EHCI and other features. Configuration is done in a payload, but it is supposed 
to
affect hardware initialization in coreboot.

We would like to have this functionality in mainline coreboot. We expect that
this proof-of-concept is not good enough to incorporate it, but the question is 
how
much better we have to do that. We have read some discussion on this topic on
mailing list and we have found many ideas how this should be done, however we
haven't found any definite answer.

IMHO, a simple solution is the best one as long as it works well. It's also 
certainly
better than nothing, especially that question appears again and again. A single
fixed-size CBFS file seems to be enough for most applications. In fact, whole 
coreboot
configuration is just 686 lines, in my configuration, 602 of them are boolean 
or disabled,
so they could be packed in ceil(602/8)=76 bytes. I think 8 bytes for each other 
is quite
safe to assume (most of them needs less, some needs more). 76+8*82=748 b. So 
even
if we'd like to pack the whole configuration into a binary file we'd need 1kB 
or less. No
moving, no resizing, just fixed schema binary file, it could be easily done 
with CBFS.

To make it easy we'd prepare build system so that we could mark some options
runtime-configurable in menuconfig. Based on those choices runtime-config 
structure would
be generated as C header so that it can be easily used in source files.

On the other hand, we have seen quite advanced considerations in the discussion 
so
we've decided to ask for your opinion before we prepare final implementation.

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

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This may be a general coreboot limitation at the moment.  The
compatibility sections for mixed CPUs in the BKDG are more concerned
with total power delivery and proper P-state setup than anything else.

If I recall correctly, coreboot assumes both CPUs have the same core
count when setting up APICs and such.  There are a number of places that
would need to be modified to remove this assumption; it's a leftover
from the original K8 code and would take some significant work to fix.
This also needs to be verified as I am going from memory here from a
couple of years ago.

On 04/11/2018 02:12 PM, Elisenda Cuadros wrote:
> Thank you for your reply Timothy.
> 
> Vendor Bios doesn't print any special message regarding this.
> 
> In fact it shows a total of 28 cores (16+12).
> 
> I thought mixing CPUs from same families was supported.
> 
> Regards,
> 
> - Eli
> 
> On 11/04/18 20:44, Timothy Pearson wrote:
>> I don't know if coreboot has support for differing CPUs in the same
>> mainboard; it's not something I can recall testing at any point.
>>
>> The failure is occurring far before memory initialization, in CAR, in
>> core setup.  I'd guess it has something to do with the two CPUs you have
>> installed having different core counts.
>>
>> Does the vendor BIOS print a message about the core count being limited
>> on one of the CPUs for compatibility reasons?
>>
>> On 04/11/2018 12:57 PM, Elisenda Cuadros wrote:
>>> Hello,
>>
>>> After testing the board for some weeks I bought another CPU (6276). I
>>> installed this into CPU1 slot and a 6238 in CPU2.
>>
>>> I checked that both CPUs are shining and also the memory (Micron
>>> MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots).
>>
>>> The problem is that Coreboot seems to hang at the beginning. I attach
>>> console.log.
>>
>>> I reinstalled all the devices twice, checked the vendor manual, docs in
>>> coreboot.org, messages in mailing list, but I don't know what is causing
>>> the problem.
>>
>>> Last test I've done is booting with vendor bios, and it boots without
>>> problem.
>>
>>> Any ideas?
>>
>>> Thank you for your help.
>>
>>> Regards,
>>
>>> - Eli
>>
>>
>>
>>
>>
>>
> 
> 


- -- 
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

iQEcBAEBAgAGBQJazmI3AAoJEK+E3vEXDOFbYtoH+wTs7rFYkkAq4niZcqSGEqaW
KMuhAUf3G5a86mcmpnhnJNCstFfDrc1+nWBMyF8xVmp6M/sV1mE869W2ppxHWbiD
iuK1jO16zNQGPOddDvLQuVNgn57qGC5D5HEstljNkfcOi2svQkbPF+Fzno46SF/2
skGkg3PPfi5kIYQNWPBWYUUI7gUEg5s5bnQ7lnqNxi4V8hBZaVS8zVjUzHn6RYEs
RpSLepk2iynwBcG5hGsKAPYvsE4WQZcWOz4talVnGVdv6m05KmPxh6MfIMvhnNji
ShGUDjPkLAsk80qDT5ZN4VBImEhcGG6Yg1297HiOI0cklRXhvufVKaG2vufb0XA=
=WGT+
-END PGP SIGNATURE-

-- 
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

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 
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 
> 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

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] When does AMD release the fam15 spectre microcode updates?

[Rudolf Marek]

Hi,

There is slight update from AMD [1], relevant part for you:

*AMD Microcode Updates for GPZ Variant 2/Spectre*

In addition, microcode updates with our recommended mitigations addressing 
Variant 2 (Spectre) have been released to our customers and ecosystem partners 
for AMD processors dating back to the first “Bulldozer” core products introduced 
in 2011.


AMD customers will be able to install the microcode by downloading BIOS updates 
provided by PC and server manufacturers and motherboard providers.  Please check 
with your provider for the latest updates.


Unfortnately, I dont know where to get that microcode. Any ideas?

And also, it changed in [2] the claims that IBPB should be made on context 
switch.

Thanks
Rudolf

[1] https://www.amd.com/en/corporate/security-updates
[2] 
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf


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