coreboot April 2018

coreboot@coreboot.org

68 participants
128 discussions

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

11 Apr '18

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

1 0

BIOS/CoreBoot/UBOOT
by Raymond Yeung 11 Apr '18

11 Apr '18

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

1 0

Updated AMD microcode for Spectre V2
by Piotr Kubaj 11 Apr '18

11 Apr '18

It looks like they go the same way that Intel did (vendors first): https://www.amd.com/en/corporate/security-updates It's still nice that at last we get new microcode, but it's a shame AMD didn't notify coreboot project :/ -- IQ PL Sp. z o.o. Piotr Kubaj Administrator Systemowy e-mail: pkubaj(a)iq.pl

1 0

Re: [coreboot] Looking for a volunteer to add Fam15h spectre MSR to coreboot
by Arthur Heymans 11 Apr '18

11 Apr '18

Mike Banon <mikebdp2(a)gmail.com> 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

1 0

Looking for a volunteer to add Fam15h spectre MSR to coreboot
by Taiidan＠gmx.com 11 Apr '18

11 Apr '18

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)

3 2

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 10 Apr '18

10 Apr '18

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1388253: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/skylake/romstage/romstage_fsp20.c: 254 in platform_fsp_memory_init_params_cb() ________________________________________________________________________________________________________ *** CID 1388253: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/skylake/romstage/romstage_fsp20.c: 254 in platform_fsp_memory_init_params_cb() 248 const struct device *dev; 249 const struct soc_intel_skylake_config *config; 250 FSP_M_CONFIG *m_cfg = &mupd->FspmConfig; 251 FSP_M_TEST_CONFIG *m_t_cfg = &mupd->FspmTestConfig; 252 253 dev = dev_find_slot(0, PCI_DEVFN(PCH_DEV_SLOT_LPC, 0)); >>> CID 1388253: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "dev". 254 config = dev->chip_info; 255 256 soc_memory_init_params(m_cfg, config); 257 258 /* Skip creating Management Engine MBP HOB */ 259 m_t_cfg->SkipMbpHob = 0x01; ** CID 1361695: Null pointer dereferences (NULL_RETURNS) /src/northbridge/intel/pineview/early_init.c: 45 in early_graphics_setup() ________________________________________________________________________________________________________ *** CID 1361695: Null pointer dereferences (NULL_RETURNS) /src/northbridge/intel/pineview/early_init.c: 45 in early_graphics_setup() 39 { 40 u8 reg8; 41 u16 reg16; 42 u32 reg32; 43 44 const struct device *d0f0 = dev_find_slot(0, PCI_DEVFN(0,0)); >>> CID 1361695: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "d0f0". 45 const struct northbridge_intel_pineview_config *config = d0f0->chip_info; 46 47 pci_write_config8(D0F0, DEVEN, BOARD_DEVEN); 48 49 /* vram size from cmos option */ 50 if (get_option(&reg8, "gfx_uma_size") != CB_SUCCESS) ** CID 1353171: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/skylake/romstage/romstage.c: 66 in soc_memory_init_params() ________________________________________________________________________________________________________ *** CID 1353171: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/skylake/romstage/romstage.c: 66 in soc_memory_init_params() 60 { 61 const struct device *dev; 62 const struct soc_intel_skylake_config *config; 63 64 /* Set the parameters for MemoryInit */ 65 dev = dev_find_slot(0, PCI_DEVFN(PCH_DEV_SLOT_LPC, 0)); >>> CID 1353171: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "dev". 66 config = dev->chip_info; 67 68 /* 69 * Set IGD stolen size to 64MB. The FBC hardware for skylake does not 70 * have access to the bios_reserved range so it always assumes 8MB is 71 * used and so the kernel will avoid the last 8MB of the stolen window. ** CID 1255944: (NULL_RETURNS) /src/northbridge/amd/pi/00730F01/dimmSpd.c: 32 in AmdMemoryReadSPD() /src/northbridge/amd/pi/00630F01/dimmSpd.c: 32 in AmdMemoryReadSPD() /src/northbridge/amd/pi/00660F01/dimmSpd.c: 30 in AmdMemoryReadSPD() ________________________________________________________________________________________________________ *** CID 1255944: (NULL_RETURNS) /src/northbridge/amd/pi/00730F01/dimmSpd.c: 32 in AmdMemoryReadSPD() 26 #define DIMENSION(array)(sizeof(array)/ sizeof(array [0])) 27 28 AGESA_STATUS AmdMemoryReadSPD (UINT32 unused1, UINTN unused2, AGESA_READ_SPD_PARAMS *info) 29 { 30 int spdAddress; 31 DEVTREE_CONST struct device *dev = dev_find_slot(0, PCI_DEVFN(0x18, 2)); >>> CID 1255944: (NULL_RETURNS) >>> Dereferencing a null pointer "dev". 32 DEVTREE_CONST struct northbridge_amd_pi_00730F01_config *config = dev->chip_info; 33 34 if ((dev == 0) || (config == 0)) 35 return AGESA_ERROR; 36 37 if (info->SocketId >= DIMENSION(config->spdAddrLookup )) /src/northbridge/amd/pi/00630F01/dimmSpd.c: 32 in AmdMemoryReadSPD() 26 #define DIMENSION(array)(sizeof(array)/ sizeof(array [0])) 27 28 AGESA_STATUS AmdMemoryReadSPD (UINT32 unused1, UINTN unused2, AGESA_READ_SPD_PARAMS *info) 29 { 30 int spdAddress; 31 DEVTREE_CONST struct device *dev = dev_find_slot(0, PCI_DEVFN(0x18, 2)); >>> CID 1255944: (NULL_RETURNS) >>> Dereferencing a null pointer "dev". 32 DEVTREE_CONST struct northbridge_amd_pi_00630F01_config *config = dev->chip_info; 33 34 if ((dev == 0) || (config == 0)) 35 return AGESA_ERROR; 36 37 if (info->SocketId >= DIMENSION(config->spdAddrLookup )) /src/northbridge/amd/pi/00660F01/dimmSpd.c: 30 in AmdMemoryReadSPD() 24 #include "northbridge/amd/pi/dimmSpd.h" 25 26 AGESA_STATUS AmdMemoryReadSPD (UINT32 unused1, UINTN unused2, AGESA_READ_SPD_PARAMS *info) 27 { 28 int spdAddress; 29 DEVTREE_CONST struct device *dev = dev_find_slot(0, PCI_DEVFN(0x18, 2)); >>> CID 1255944: (NULL_RETURNS) >>> Dereferencing a null pointer "dev". 30 DEVTREE_CONST struct northbridge_amd_pi_00660F01_config *config = dev->chip_info; 31 32 if ((dev == 0) || (config == 0)) 33 return AGESA_ERROR; 34 if (info->SocketId >= ARRAY_SIZE(config->spdAddrLookup)) 35 return AGESA_ERROR; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

AMD Lenovo G505S board status update! + board_status.sh discussion
by Mike Banon 10 Apr '18

10 Apr '18

Hi friends! I have submitted a new board status update for Lenovo G505S laptop. The previous one was exactly 6 month old and I started worrying that our wonderful quad core AMD laptop without Intel ME / AMD PSP hardware backdoors - could be removed ; not because of the lack of users (in fact, there are a lot of G505S+coreboot users!) , but just because of the lack of board status updates :P Three primary obstacles I had to overcome while submitting: 1) board_status.sh is trying to tell too much information about your system : cbfs.txt coreboot_console.txt payload_config.txt config.short.txt coreboot_timestamps.txt revision.txt config.txt kernel_log.txt rom_checksum.txt Two of these files - coreboot_console.txt and especially kernel_log.txt - could contain some information which is very private: in my case, kernel_log.txt contained the MAC address of my Ethernet card, both coreboot_console.txt and kernel_log.txt contained the model of my USB flash drive - knowing a model helps to figure out the controller and raises the possible success of some targeted BadUSB attack against the submitter, and so on Maybe this is why some coreboot users do not want to use this script, a very important one :P But there is an easy solution: To pause the board_status.sh script just before it uploads the logs, so that I could personally look through them and remove the parts of information that I consider as private, I have inserted the following lines just before the "echo "Uploading results" at ~440 line: stty -echo printf "Press_any_key_1...: " read variable1 stty echo printf "\n" sleep 1 stty -echo printf "Press_any_key_2...: " read variable2 stty echo printf "\n" sleep 1 I run a board_status.sh script, it collects the logs and puts them inside the freshly cloned board-status repository, then a script pauses, I could edit the logs until I consider them as OK, and then give a "go ahead" command by pressing the any key two times, and only then a script does the "git add" of them and commits the upload 2) board_status.sh - "Verifying that CBMEM is available" part at 380-390 lines is broken, in particular, line 381 " sudo command -v "$cbmem_cmd" >/dev/null " tells that command not found - perhaps this 'command' command is not available at some linux distros. I had to comment out this code, leaving only cbmem_cmd="sudo $cbmem_cmd" line: echo "Verifying that CBMEM is available" # if [ $(id -u) -ne 0 ]; then # sudo command -v "$cbmem_cmd" >/dev/null # if [ $? -ne 0 ]; then # echo "Failed to run $cbmem_cmd using sudo. Check \$PATH or use -c" \ # "to specify path to cbmem binary." # exit $EXIT_FAILURE # else cbmem_cmd="sudo $cbmem_cmd" # fi # else # test_cmd $LOCAL "$cbmem_cmd" # fi and the rest of board_status.sh script is working, after I supply a path to cmbem executable file, which is obtained by going to ./util/cbmem/ directory and running "make" 3) Despite that I have not modified the coreboot source code, just the couple of changes to config all through "make menuconfig" + some floppies added AFTER the build, I still got a "-dirty" added to my version while building. Maybe some bug there? git diff does not show anything interesting, there were no local changes (except the board_status.sh but that happened much later). Did not like that "-dirty" as it was unfair, and fixed the already-submitted board status to become clean with a follow-up commit. Know thats a bit of cheating, but though it was OK to do in such a situation, as I have not modified anything at the sources that could have changed the working status of that build Best regards, Mike Banon

1 0

Problem with super io NCT6793D
by 王翔 09 Apr '18

09 Apr '18

I want to porting coreboot to MSI's motherboard. However, the super io of this motherboard is the NCT6793D. Which chip is like NCT6793D? Or give me datasheet of the NCT6793D. Thank you very much. ------------------ 王翔安全研究员广州市腾御安信息科技有限公司广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024

3 3

Asus ASMB-iKVM modules
by Piotr Kubaj 09 Apr '18

09 Apr '18

I'm looking to buy some ASMB-iKVM module for my KGPE-D16. I've looked in all the Internet shops I could find, but there are none available. Do any of you have some for sale? I figured it may be the best place to ask about it. -- _______________________________________ / A straw vote only shows which way the \ | hot air blows. | | | \ -- O'Henry / --------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||

1 0

Re: [coreboot] coreboot is going to make kcma-d8 obsolete
by Daniel Gröber 08 Apr '18

08 Apr '18

On Fri, Apr 06, 2018 at 07:14:47PM -0700, David Hendricks wrote: > Which wiki? For commit rights, have you tried https://www.coreboot.org/Git# > Register_with_gerrit ? I just updated the board status wiki to hopefully make that step > easier to follow. Ah, I was looking all over "Developer Guide", "Getting Started" type things and somehow did't see the Git page :) Having a pointer in the Board Status description straight to the Git page is definetly better though. > Please let us know where you get stuck. Many of us set up our accounts years ago and the > documentation may be stale or non-obvious to newcomers, so a fresh perspective is > welcome. I just didn't realise all that was needed is a gerrit account, I though the board status would be some seperate repo where you can push directly without review. Anyways, I figured it out now and uploadded the status report. --Daniel

5 5

← Newer
1
...
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