coreboot-gerrit August 2022

coreboot-gerrit@coreboot.org

673 discussions

Change in coreboot[master]: mb/google/zork/vilboz: update telemetry settings for vilboz
by Peichao Li (Code Review) 10 Jun '23

10 Jun '23

Peichao Li has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43664 ) Change subject: mb/google/zork/vilboz: update telemetry settings for vilboz ...................................................................... mb/google/zork/vilboz: update telemetry settings for vilboz Update telemetry value for SDLE test result. BUG=b:160698427 b:161084687 BRANCH=None TEST=emerge-zork coreboot chromeos-bootimage Signed-off-by: Peichao.Wang <peichao.wang(a)bitland.corp-partner.google.com> Change-Id: I3e3e8a3ec1c607d1a94761abd9fe1ab5585873e2 --- M src/mainboard/google/zork/variants/vilboz/overridetree.cb 1 file changed, 14 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/43664/1 diff --git a/src/mainboard/google/zork/variants/vilboz/overridetree.cb b/src/mainboard/google/zork/variants/vilboz/overridetree.cb index 49d21d5..3ddbb6c 100644 --- a/src/mainboard/google/zork/variants/vilboz/overridetree.cb +++ b/src/mainboard/google/zork/variants/vilboz/overridetree.cb @@ -16,6 +16,20 @@ register "stapm_time_constant" = "2500" # second register "sustained_power_limit" = "4800" # mW + register "telemetry_vddcr_vdd_slope" = "32435" #mA + register "telemetry_vddcr_vdd_offset" = "168" + register "telemetry_vddcr_soc_slope" = "22644" #mA + register "telemetry_vddcr_soc_offset" = "0-70" + + # VRM Limits + register "vrm_maximum_current_limit" = "19000" #mA + register "vrm_soc_maximum_current_limit" = "13000" #mA + register "vrm_current_limit" = "15000" #mA + register "vrm_soc_current_limit" = "10000" #mA + + # PROCHOT_L de-assertion Ramp Time + register "prochot_l_deassertion_ramp_time" = "20" #mS + # End : OPN Performance Configuration # I2C2 for touchscreen and trackpad -- To view, visit https://review.coreboot.org/c/coreboot/+/43664 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I3e3e8a3ec1c607d1a94761abd9fe1ab5585873e2 Gerrit-Change-Number: 43664 Gerrit-PatchSet: 1 Gerrit-Owner: Peichao Li <peichao.wang(a)bitland.corp-partner.google.com> Gerrit-MessageType: newchange

3 2

Change in coreboot[master]: Documentation/security/intel: add Boot Guard related documentation
by Michał Żygowski (Code Review) 10 Jun '23

10 Jun '23

Michał Żygowski has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43405 ) Change subject: Documentation/security/intel: add Boot Guard related documentation ...................................................................... Documentation/security/intel: add Boot Guard related documentation Signed-off-by: Michał Żygowski <michal.zygowski(a)3mdeb.com> Change-Id: Ifd7d4a4e4054652a5876c7e1ca1c1a1ecb73e176 --- M Documentation/security/index.md A Documentation/security/intel/bootguard.md 2 files changed, 247 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/05/43405/1 diff --git a/Documentation/security/index.md b/Documentation/security/index.md index c9cb4a7..5605148 100644 --- a/Documentation/security/index.md +++ b/Documentation/security/index.md @@ -14,6 +14,10 @@ - [Intel TXT Initial Boot Block](intel/txt_ibb.md) - [Intel Authenticated Code Modules](intel/acm.md) +## Intel Boot Guard + +- [Intel Boot Guard](intel/bootguard.md) + ## SMM - [System Management Mode](smm.md) diff --git a/Documentation/security/intel/bootguard.md b/Documentation/security/intel/bootguard.md new file mode 100644 index 0000000..78d342b --- /dev/null +++ b/Documentation/security/intel/bootguard.md @@ -0,0 +1,243 @@ +# Intel Boot Guard + +Intel Boot Guard allows: + +1. Integrity verification and measurement of the early boot code. +2. Assuring that only authorized firmware can be executed, which can then be + considered trusted. +3. Providing a hardware-rooted Root of Trust for measurement and/or + verification. + +Intel Boot Guard requirements: + +1. Intel Boot Guard requires a **TPM** to measure parts of the firmware before + it's run on the BSP in case of profiles performing measurements. +2. Intel Boot Guard requires signed **Authenticated Code Modules** ([ACM]s), + provided by Intel. These ACMs are different for platforms without Intel TXT. +3. Intel Boot Guard is told to require a **Boot Guard capable CPU** (check on + Intel ARK). Experiments showed that it is not true. Intel 4th generation + processor or newer is sufficient. All that is required is a provisioned ME + firmware for Boot Guard and an ACM. +4. Intel ME has to be in Manufacturing Mode in order to enable Boot Guard. When + the Manufacturing Mode is disabled the FPFs are blown and it is impossible + to change the Boot Guard status (either enabled with keys you do not have + access to or permanently disabled). + +## Authenticated Code Modules + +The ACMs are Intel digitally signed modules that contain code to be run +before the traditional x86 CPU reset vector. + +More details can be found here: [Intel ACM]. + +## Modified bootflow with Intel Boot Guard + +With Intel Boot Guard the first instruction executed on the BSP isn't the +*reset vector*, but the [Intel ACM]. + +It initializes the TPM and measures parts of the firmware, the IBB. + +### Marking the Initial Boot Block + +Individual files in the CBFS can be marked as IBB in similar manner +as in Intel TXT. + +More details can be found in the [Intel TXT IBB] chapter. + +The difference here is that the IBB elements are removed from [FIT table] as +they are not required for Boot Guard. The newly implemented tool to create Boot +Guard manifests, ibmptool (part of cbfstool), handles creation of signed +manifests and calculates the hash of the IBB based on the [FIT] entries. IBB +must complete the memory initialization according to specification, but in +coreboot's case it is not needed, as the verified and measured boot mode may +start in bootblock already. Covering bootblock, verstage (and FSP-T +optionally) is sufficient. + +### Measurements + +The IBBs (Initial Boot Blocks) are measured into TPM's PCR7 by the Boot Guard +[ACM] before the CPU reset vector is executed. The extend operation is +controlled by flags filled for each IBB segment by ibpmtool. Boot Guard also +allows to specify the Locality (0 or 3) from which the TPM starts up and +measures the IBB. To indentify the regions that need to be measured, the [FIT] +contains one ore multiple *Type 7* entries, that point to the IBBs. + +## Boot Guard capable firmware building and options + +In order to build coreboot with Boot Guard support, few preparation steps are +required. + +1. Boot Guard requires 2 RSA keys from user: OEM Root key (for Key Manifest) + and Boot Policy key (for Boot Policy Manifest). The hash of the public part + of Boot Policy gets signed inside Key Manifest by OEM Root key. This allows + the OEM Root key owner to authorize many Boot Policy keys by simply + delivering a signed Key Manifest to end-user. The coreboot's implementation + allows to specify whether the Key Manifest should be built or a ready one to + be included. + + In order to create the keys OpenSSL may be used: + ``` + openssl genrsa -out OEM_Root_key_private.pem 2048 + openssl rsa -in OEM_Root_key_private.pem -outform PEM -pubout -out OEM_Root_key_public.pem + openssl genrsa -out BPM_key_private.pem 2048 + openssl rsa -in BPM_key_private.pem -outform PEM -pubout -out BPM_key_public.pem + ``` + + Boot Guard supports only RSA2048 for now, but it may change in the future. + +2. Obtain the Boot Guard ACM for your microarchitecture/platform. UEFITool is + able to detect the Boot Guard ACM in the firmware. +3. In menuconfig go to Security submenu and select Intel Boot Guard. Then enter + the Boot Guard submenu which appears after selecting previous option. +4. Provide path and filename to Boot Policy key and the ACM. In case you + already have a signed Key Manifest provide path to the file. Otherwise you + will have to change the Key Manifest source to build a Key Manifest. +5. Provide a Key Manifest Key ID (it must match the ID in the ME firmware + image). +6. Fill the ACM revocation value. Values of 0 and 1 are for engineering samples + and are not available for public use, production ACMs have value of 2. If + there were no revocations earlier it is safe to leave the default. + Revocations will be explained later. +7. Fill the Boot Guard ACM location in CBFS. The ACM must be 64k or 128k + aligned and be placed in the top most 2MB under 4GB in memory space. +8. Build the coreboot image. + +### ME provisioning + +Boot Guard requires provisioning of the ME firmware image. That is, ME firmware +must be configured with OEM Root key public hash, the Key Manifest Key ID and +the Boot Guard profile number. Currently it is only possible with Flash Image +Tool included in ME firmware kit available under CNDA. + +The OEM Root key public hash can be retrieved from the coreboot build log. The +ibpmtool prints the manifests content after it finishes its job. The OEM Root +Key hash is printed after dumping Key Manifest: + +``` +FYI: Hash of the KM public key (modulus only): + + B7 94 7B 36 D2 74 74 A5 B0 44 22 23 99 BE 57 07 + FA 84 97 0D 74 A7 8F 6F D0 6F 66 06 8C 41 D3 81 +``` + +For Skylake and Kaby Lake only modulus part of the RSA key is provided as OEM +Root Key public hash. For other microarchitectures the exponent is also +included in public hash calculation. + +As a last step provide the Key Manifest Key ID to the Flash Image Tool, the +same ID as provided to coreboot's menu config and enable desired Boot Guard +profile. Note, profiles 1 and 1 are no longer available since Coffee Lake. + +### ME fusing + +Blowing the FPFs with Boot Guard configuration requires specialized tool called +Flash Programming Tool which is distributed under CNDA. The fusing process is +achieved by closing the Manufacturing process. + +### Firmware layout requirements + +There are certain requirements about the firmware layout. + +1. IBB must reside in top most 4MB under 4GB in memory space. [FIT table], + microcode and Boot Guard Manifests are also expected to reside in this + range. +2. Boot Guard [ACM] must reside in top most 2MB under 4GB in memory space. + Additionally it must be aligned to 64 or 128 kilobytes (32 kilobytes is also + supported but not recommended as [ACM] size may be larger in the future). + +For Coffee Lake and newer microarchitectures, these requirements apply to +top most 8MB under 4GB in memory space. + +## Revocation + +Boot Guard has a few revocation mechanisms designed to keep the platform secure +from downgrading the firmware to vulnerable version. There are 3 main +revocation mechanisms: + +1. [ACM] SVN revocation +2. Kay Manifest (KM) SVN revocation +3. Boot Policy Manifest (BPM) SVN revocation + +### ACM SVN revocation + +The rule is simple. Each ACM has its Security Version Number (SVN). Production +ACMs start at SVN equal to 2. Each newer ACM executed on the hardware can bump +the ACM SVN present in FPFs. If the ACM SVN in FPF is higher than the ACM SVN +in the blob it will not be executed and enforcement logic will be triggered. In +the opposite situation the ACM SVN may be bumped to higher number in FPFs. It +is controlled by the ACMSVN_Auth field in Boot Policy Manifest. If the +ACMSVN_Auth in Boot Policy Manifest is equal to the ACM SVN in the blob and +ACMSVN_Auth is higher than the current ACM SVN in FPF, ACM SVN in FPFs will be +bumped. + +The ACMSVN_Auth value can be controlled by menuconfig option in Boot Guard +submenu. + +### KM SVN revocation + +The KM SVN follows the same rules as the ACM SVN revocation. The difference +here is that by default KM SVN starts at value of 0. OEM, firmware owner may +authorize new Kay Manifests by simply increasing the KM SVN number when +assembling a Key Manifest. + +The Key Manifest revocation value can be controlled by menuconfig option in +Boot Guard submenu. + +### BPM SVN revocation + +The BPM SVN follows the same rules as the KM SVN revocation. + +The Boot Policy Manifest revocation value can be controlled by menuconfig +option in Boot Guard submenu. + +## Boot Guard manifests optional fields + +Boot Guard Manifests have a few optional fields: + +1. Platform Manufacturer's Key Manifest version. +2. Platform Manufacturer's Boot Policy version. +3. Post IBB hash. +4. Platform Manufacturer's structure. + +The first two are just version numbers used by platform manufacturer's +purposes. They are present in according manifests and are not used by Boot +Guard. Free for one's use. + +Post IBB hash was intended to use as verification of code that is executed +after IBB. It may serve as another custom field for example to keep a hash +of vboot key or other firmware component. + +Platform Manufacturer's structure is an optional part of Boot Policy Manifest. +Currently it is not supported by ibpmtool and shouldn't be used to avoid +errors. ibpmtool assumes that there is no Platform Manufacturer's structure in +Boot Policy Manifest, so dumping one with ibpmtool will give false results. + +## TODO list + +There are still some Boot Guard features not covered by current implementation: + +1. Utilize VT-d and set PMRs in manifests to protect IBB from DMA. +2. Allow to set the TPM measurement option in IBB element flag in ibpmtool. +3. vboot does not work with Boot Guard. The amount of data that needs to be + fetched from SPI flash to verify RW partition is too huge to fit in NEM and + platform simply hangs. vboot needs per-file verification in order to work + with Boot Guard. Current working alternative is ELTAN's vboot. +4. Verify support for Boot Guard- and TXT-enabled systems prior to Coffee Lake. +5. Implement support for Converged Boot Guard and TXT. +6. Enforce the firmware layout requirements in the build system to avoid + user input errors. +7. Implement Platform Manufacturer's structure parsing in ibmptool. +8. Implement a simple Boot Guard library that will dump its status and errors. +9. Implement a TPM event log entry for Boot Guard measurement. +10. Boot Guard for Apollo Lake and newer Atom series processors seems to be a + little bit different. It will need additional effort to work. +11. Implement open-source CAR setup for Boot Guard enabled platforms. Currently + we lack a working implementation for Boot Guard flow (Boot Guard releases + CPUs from reset where IBB is already in cache and MTRRs are set for IBB + elements). For he time being FSP-T must be used. + +[Intel TXT IBB]: txt_ibb.md +[FIT]: ../../soc/intel/fit.md +[Intel ACM]: acm.md +[ACM]: acm.md +[FIT table]: ../../soc/intel/fit. -- To view, visit https://review.coreboot.org/c/coreboot/+/43405 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ifd7d4a4e4054652a5876c7e1ca1c1a1ecb73e176 Gerrit-Change-Number: 43405 Gerrit-PatchSet: 1 Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-MessageType: newchange

5 5

Change in coreboot[master]: [TESTONLY]cpu/intel/socket_mPGA604: Run romstage from CAR
by Arthur Heymans (Code Review) 10 Jun '23

10 Jun '23

Arthur Heymans has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/36564 ) Change subject: [TESTONLY]cpu/intel/socket_mPGA604: Run romstage from CAR ...................................................................... [TESTONLY]cpu/intel/socket_mPGA604: Run romstage from CAR With a pentium 4 CPU running WP XIP is not possible. To speed up execution copying romstage to CAR might work? TEST: does it boot? is it faster? Change-Id: I4c35d09b87b545944a4465ff695953d1e8a811e4 Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz> --- M src/arch/x86/memlayout.ld M src/cpu/intel/car/p4-netburst/cache_as_ram.S M src/cpu/intel/socket_mPGA604/Kconfig 3 files changed, 20 insertions(+), 3 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/36564/1 diff --git a/src/arch/x86/memlayout.ld b/src/arch/x86/memlayout.ld index 9fd9889..ed89894 100644 --- a/src/arch/x86/memlayout.ld +++ b/src/arch/x86/memlayout.ld @@ -39,7 +39,7 @@ #elif ENV_ROMSTAGE /* The 1M size is not allocated. It's just for basic size checking. * Link at 32MiB address and rely on cbfstool to relocate to XIP. */ - ROMSTAGE(CONFIG_ROMSTAGE_ADDR, 1M) + ROMSTAGE(CONFIG_ROMSTAGE_ADDR, CONFIG_DCACHE_ROMSTAGE_SIZE) #include EARLY_MEMLAYOUT #elif ENV_VERSTAGE diff --git a/src/cpu/intel/car/p4-netburst/cache_as_ram.S b/src/cpu/intel/car/p4-netburst/cache_as_ram.S index 2cd0c5e..fdb5ddc 100644 --- a/src/cpu/intel/car/p4-netburst/cache_as_ram.S +++ b/src/cpu/intel/car/p4-netburst/cache_as_ram.S @@ -23,9 +23,17 @@ .set ap_sipi_vector_in_rom, 0xff #endif -#define CACHE_AS_RAM_SIZE CONFIG_DCACHE_RAM_SIZE +#define CACHE_AS_RAM_SIZE (CONFIG_DCACHE_RAM_SIZE + CONFIG_DCACHE_ROMSTAGE_SIZE) #define CACHE_AS_RAM_BASE CONFIG_DCACHE_RAM_BASE +#if (CACHE_AS_RAM_BASE & (CACHE_AS_RAM_SIZE - 1)) +#error "CONFIG_DCACHE_RAM_BASE is not aligned!" +#endif + +#if ((CACHE_AS_RAM_SIZE & (CACHE_AS_RAM_SIZE - 1)) != 0) +#error "Cache-as-Ram size must be a power of 2!" +#endif + #if CONFIG(C_ENVIRONMENT_BOOTBLOCK) #if ((CONFIG_C_ENV_BOOTBLOCK_SIZE & (CONFIG_C_ENV_BOOTBLOCK_SIZE - 1)) != 0) #error "CONFIG_C_ENV_BOOTBLOCK_SIZE must be a power of 2!" diff --git a/src/cpu/intel/socket_mPGA604/Kconfig b/src/cpu/intel/socket_mPGA604/Kconfig index 4ec46e0..5f9eb9c 100644 --- a/src/cpu/intel/socket_mPGA604/Kconfig +++ b/src/cpu/intel/socket_mPGA604/Kconfig @@ -15,6 +15,7 @@ select C_ENVIRONMENT_BOOTBLOCK select CPU_INTEL_COMMON select CPU_INTEL_COMMON_TIMEBASE + select NO_XIP_EARLY_STAGES # mPGA604 are usually Intel Netburst CPUs which should have SSE2 # but the ramtest.c code on the Dell S1850 seems to choke on @@ -25,7 +26,7 @@ config DCACHE_RAM_BASE hex - default 0xfefc0000 + default 0xfef0000 config DCACHE_RAM_SIZE hex @@ -35,4 +36,12 @@ hex default 0x2000 +config DCACHE_ROMSTAGE_SIZE + hex + default 0xc000 + +config ROMSTAGE_ADRR + hex + default 0xfef4000 + endif # CPU_INTEL_SOCKET_MPGA604 -- To view, visit https://review.coreboot.org/c/coreboot/+/36564 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I4c35d09b87b545944a4465ff695953d1e8a811e4 Gerrit-Change-Number: 36564 Gerrit-PatchSet: 1 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-MessageType: newchange

3 17

Change in coreboot[master]: msrtool: Fix enum type declaration
by Peter Lemenkov (Code Review) 10 Jun '23

10 Jun '23

Peter Lemenkov has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/39162 ) Change subject: msrtool: Fix enum type declaration ...................................................................... msrtool: Fix enum type declaration This patch fixes compilation and linking with GCC 10: * https://kojipkgs.fedoraproject.org//work/tasks/3541/41983541/build.log ``` gcc -o msrtool msrtool.o msrutils.o sys.o linux.o darwin.o freebsd.o geodegx2.o geodelx.o cs5536.o k8.o via_c7.o intel_pentium3_early.o intel_pentium3.o intel_pentium4_early.o intel_pentium4_later.o intel_pentium_d.o intel_core1.o intel_core2_early.o intel_core2_later.o intel_nehalem.o intel_atom.o -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/lib64 -lpci /usr/bin/ld: msrutils.o:/builddir/build/BUILD/coreboot-4.10/util/msrtool/msrtool.h:50: multiple definition of `PresentTypes'; msrtool.o:/builddir/build/BUILD/coreboot-4.10/util/msrtool/msrtool.h:50: first defined here /usr/bin/ld: msrutils.o:/builddir/build/BUILD/coreboot-4.10/util/msrtool/msrtool.h:40: multiple definition of `MsrTypes'; msrtool.o:/builddir/build/BUILD/coreboot-4.10/util/msrtool/msrtool.h:40: first defined here ``` Look at this expression: enum { ... } name; It declares a variable with type of anonymous enumeration. Before GCC 10 it wasn't an issue since compiler defines -fcommon. With GCC 10 this declaration is no longer permitted - see the following link for further details: * https://gcc.gnu.org/gcc-10/porting_to.html#common * https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common Let's remove unnecessary variable declaration. Change-Id: Ie154375ad6e3c1845f7937dac0121f3b63b6dd63 Signed-off-by: Peter Lemenkov <lemenkov(a)gmail.com> --- M util/msrtool/msrtool.h 1 file changed, 4 insertions(+), 4 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/62/39162/1 diff --git a/util/msrtool/msrtool.h b/util/msrtool/msrtool.h index 8cba4c7..192ebf2 100644 --- a/util/msrtool/msrtool.h +++ b/util/msrtool/msrtool.h @@ -32,14 +32,14 @@ #define HEXCHARS "0123456789abcdefABCDEF" -enum { +enum MsrTypes { MSRTYPE_RDONLY, MSRTYPE_RDWR, MSRTYPE_WRONLY, MSRTYPE_EOT -} MsrTypes; +}; -enum { +enum PresentTypes { PRESENT_RSVD, PRESENT_DEC, PRESENT_BIN, @@ -47,7 +47,7 @@ PRESENT_HEX, PRESENT_HEXDEC, PRESENT_STR, -} PresentTypes; +}; struct msr { uint32_t hi; -- To view, visit https://review.coreboot.org/c/coreboot/+/39162 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ie154375ad6e3c1845f7937dac0121f3b63b6dd63 Gerrit-Change-Number: 39162 Gerrit-PatchSet: 1 Gerrit-Owner: Peter Lemenkov <lemenkov(a)gmail.com> Gerrit-MessageType: newchange

3 4

Change in coreboot[master]: [RFC, scratch] Documentation/fsp: Start discussion around FSP-S issues
by Nico Huber (Code Review) 10 Jun '23

10 Jun '23

Hello Aaron Durbin, Patrick Rudolph, Arthur Heymans, Michael Niewöhner, Duncan Laurie, David Wu, Furquan Shaikh, I'd like you to do a code review. Please visit https://review.coreboot.org/c/coreboot/+/36328 to review the following change. Change subject: [RFC, scratch] Documentation/fsp: Start discussion around FSP-S issues ...................................................................... [RFC, scratch] Documentation/fsp: Start discussion around FSP-S issues To get some discussion started, list some heavy issues with FSP(-S). I've copy pasted some things together, and added a few words on top and bottom. Not sure yet, where this should lead. To convince Intel to contribute open-source code on their own, we might want to add a list of initialization steps, that should be open. Feel free to amend this commit in any way :) Change-Id: Ied0d8ad60fa487272a05fc73b16a7c343cc4d993 Signed-off-by: Nico Huber <nico.huber(a)secunet.com> --- A Documentation/fsp/fsp-s_discussion.md 1 file changed, 165 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/28/36328/1 diff --git a/Documentation/fsp/fsp-s_discussion.md b/Documentation/fsp/fsp-s_discussion.md new file mode 100644 index 0000000..7ac649a --- /dev/null +++ b/Documentation/fsp/fsp-s_discussion.md @@ -0,0 +1,165 @@ +Introduction +============ + +*FSP* is an ABI that allows silicon vendors to provide pre-compiled +binaries of their silicon-initialization code for the integration +into firmware frameworks such as coreboot. Current, 2.x versions +of *FSP* describe three binaries with rough responsibilities: + +* `FSP-T`: Sets up a temporary RAM environment (usually some sort + of Cache as RAM, CAR) among other things. + +* `FSP-M`: Initializes the memory (DRAM) controller, among other + things. + +* `FSP-S`: Performs various silicon-initialization steps left. + +However, what operations these binaries perform exactly and what +operations are left to the firmware framework, is neither specified +nor documented. + +Historically, all these responsibilities were left to coreboot. +Later, pre-compiled reference code for the memory-controller +initialization was introduced, then for other silicon init, and +finally there are attempts to replace coreboot's CAR setup with +FSP-T. + +While the FSP-M integration saves coreboot developers time, because +of the complex nature of the memory-controller initialization, the +integration of FSP-S turns out to be harder than implementing the +necessary code natively in coreboot. We'll discuss why that is the +case and provide an incomplete list of issues with current FSP-S +binaries. + + +Bug Fixing +---------- + +Many companies rely on the pre-built FSP binaries. Yet, there is +no common procedure to get bugs fixed or even acknowledged. This +leads to an increase of workarounds in firmware frameworks, +especially for older hardware generations. + + +Lack of Documentation +--------------------- + +Many of the initialization steps performed by FSP-S are merely +translating mainboard-specific configuration into register settings. +This is reflected by a list of hundreds of configuration options of +FSP-S. While these steps are quite simple, the additional translation +from FSP options to register values heavily increases the integration +costs. Not only are the register settings usually much better documented +than their FSP counterparts, but FSP also uses different terms so that +the existing hardware documentation often can't assist developers when +dealing with FSP. + +FSP-S also performs locking of several registers so that they can't +be written anymore afterwards. It is not documented what locks are +set by FSP. This creates heavy security issues for multiple reasons: + +* One either has to assume that FSP doesn't perform any locking + and do it redundantly in the firmware framework, or expensively + test what is locked and keep doing so for every new FSP revision. + +* Some registers may be locked before they are configured in a + secure manner. This may result in workarounds in the firmware + framework to configure things early. Sometimes it's even + impossible to do so, because relevant information isn't + available yet. + +This shows that no matter the many options that are implemented in +FSP-S, there will always be things that must be controlled by the +firmware framework. Locking should either be a separate, last step +in FSP, or be left entirely to the firmware framework. And most of +all, the locking has to be documented. + + +Arbitrary Interface Changes +--------------------------- + +Within coreboot, we try to keep code-compatibility with older hardware +generations. The FSP ABI isn't stable, however. Even when the hardware +doesn't change between minor platform updates, the configuration +settings of FSP are sometimes adapted without backwards compatibility +in mind. This increases costs, just to translate configuration data +from one representation to another only to let FSP translate it again. +In such cases, directly configuring registers from coreboot, would +save two layers of indirection. + +Another problem is the disappearance of options in newer FSP releases. +See [SpiFlashCfgLockDown UPD vanished after KBL] +(https://github.com/IntelFsp/FSP/issues/25), for instance. Current +coreboot code seems to still rely on this option. It boots, though, +only security assumptions are broken. Which again shows, locking +shouldn't be part of FSP, or at least optional. + + +FSP Switches SAI +---------------- + +A problem that multiplies with the lack of documentation is that FSP-S +switches to `POSTBOOT_SAI` on newer platforms. While it probably tries +to achieve the opposite, this undermines firmware quality and security. + +* In some firmware frameworks FSP may run long before End-of-Post, this + means most of the framework runs with `POSTBOOT_SAI`. + +* In the EDS, implications of the SAI switch are _not_ documented. + Virtually for every register, it is unknown if it is still accessible + after the SAI switch. This seems to be a problem for developers both + inside and outside of Intel. + +* The SAI switch seems to force the firmware framework to do some things + in SMM. However, the use of SMM as a more privileged execution mode is + generally discouraged. This means FSP forces firmware development to + go backwards. + +Especially the lack of documentation leads to many bugs in firmware. +Even Intel developers working on coreboot don't seem to know the +implications of the SAI switch or lack the resources to re-evaluate +all code wrt. the SAI switch. + + +FSP Creates Legal Uncertainty +----------------------------- + +Many companies sell coreboot together with FSP as part of their products. +Especially, the function pointers to GPL code that were introduced with +FSP 2.1 seem unprecedented. However, they could be compared with runtime +linking which seems troubling. + + +Mitigations +----------- + +None of the listed issues would exist if FSP were open-source and the +initialization steps could be integrated into coreboot, like they were +before. An open-source approach would not only cut costs heavily but +might also decrease time-to-market if the whole coreboot community +could work together on new platforms. + +However, in the absence of such a firmware-development utopia, there +may be more realistic approaches. As mentioned earlier, not all of FSP +has a negative impact on development performance. FSP-M, for instance, +rarely causes trouble. And due to its complex nature, it is no surprise +if memory-controller initialization is kept secret. The configuration +done by FSP-S, on the other hand, overlaps with many of coreboot's +responsibilities. The few lines of code in FSP-S that help to get a +mainboard running, don't outweigh the damage it does. However, one +can't have the cherries without taking the whole menu, which takes +years to digest. + +One approach could be to split FSP-S further up and identify parts +that are necessarily closed source and parts that could as well be +reimplemented in coreboot. However, if parts that are left closed +source change the state of the execution environment (e.g. switch +SAI), finalize any settings or raise legal concerns, the ABI would +have to change to solve all aforementioned issues. + +Another approach could be to align older platforms with open-source +coreboot, step by step. Currently, everything from Skylake on relies +on FSP-S. However, it seems Intel has already abandoned development +for this platform (while the coreboot integration was never finished). +It would seem reasonable to release abandoned code to the public, or +at least clear existing documentation for older platforms from NDAs. -- To view, visit https://review.coreboot.org/c/coreboot/+/36328 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ied0d8ad60fa487272a05fc73b16a7c343cc4d993 Gerrit-Change-Number: 36328 Gerrit-PatchSet: 1 Gerrit-Owner: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: David Wu <david_wu(a)quantatw.com> Gerrit-Reviewer: Duncan Laurie <dlaurie(a)chromium.org> Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Michael Niewöhner Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-MessageType: newchange

15 60

Change in coreboot[master]: device/cardbus: Check for NULL
by Paul Menzel (Code Review) 10 Jun '23

10 Jun '23

Paul Menzel has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43656 ) Change subject: device/cardbus: Check for NULL ...................................................................... device/cardbus: Check for NULL While debugging problems on a Lenovo T60 device, Kyösti noticed a NULL pointer access. Check before accessing garbage value. Change-Id: I6f62229e6870897544b45d44278380bb5820416b Signed-off-by: Paul Menzel <pmenzel(a)molgen.mpg.de> --- M 3rdparty/blobs M src/device/cardbus_device.c 2 files changed, 10 insertions(+), 6 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/56/43656/1 diff --git a/3rdparty/blobs b/3rdparty/blobs index bbe5d99..7ad2d22 160000 --- a/3rdparty/blobs +++ b/3rdparty/blobs @@ -1 +1 @@ -Subproject commit bbe5d99780d2d085e92d9bae2c0f7b6787419d72 +Subproject commit 7ad2d22452225a14c19b17570cb77920d8fc81a5 diff --git a/src/device/cardbus_device.c b/src/device/cardbus_device.c index cbe0c72..5fe2296 100644 --- a/src/device/cardbus_device.c +++ b/src/device/cardbus_device.c @@ -139,11 +139,15 @@ u16 ctrl; ctrl = pci_read_config16(dev, PCI_CB_BRIDGE_CONTROL); - ctrl |= (dev->link_list->bridge_ctrl & ( - PCI_BRIDGE_CTL_NO_ISA | - PCI_BRIDGE_CTL_VGA | - PCI_BRIDGE_CTL_MASTER_ABORT | - PCI_BRIDGE_CTL_BUS_RESET)); + if (dev->link_list) + ctrl |= (dev->link_list->bridge_ctrl & ( + PCI_BRIDGE_CTL_NO_ISA | + PCI_BRIDGE_CTL_VGA | + PCI_BRIDGE_CTL_MASTER_ABORT | + PCI_BRIDGE_CTL_BUS_RESET)); + else + printk(BIOS_ERR, "cardbus: dev->link_list is NULL\n"); + /* Error check */ ctrl |= (PCI_CB_BRIDGE_CTL_PARITY | PCI_CB_BRIDGE_CTL_SERR); printk(BIOS_DEBUG, "%s bridge ctrl <- %04x\n", dev_path(dev), ctrl); -- To view, visit https://review.coreboot.org/c/coreboot/+/43656 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I6f62229e6870897544b45d44278380bb5820416b Gerrit-Change-Number: 43656 Gerrit-PatchSet: 1 Gerrit-Owner: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-MessageType: newchange

4 10

Change in ...coreboot[master]: for review d945gclf/Kconig and devicetree.cb . these files are modif...
by junaid (Code Review) 10 Jun '23

10 Jun '23

junaid has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30798 Change subject: for review d945gclf/Kconig and devicetree.cb . these files are modified according to the superIO chip Winbond w83627DHG ...................................................................... for review d945gclf/Kconig and devicetree.cb . these files are modified according to the superIO chip Winbond w83627DHG Change-Id: I1449d9351bd1b76ecad16e6d81c501c1d4dd80f5 Signed-off-by: junaid <junaidimpex(a)gmail.com> --- M src/mainboard/intel/d945gclf/Kconfig M src/mainboard/intel/d945gclf/devicetree.cb 2 files changed, 37 insertions(+), 38 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/98/30798/1 diff --git a/src/mainboard/intel/d945gclf/Kconfig b/src/mainboard/intel/d945gclf/Kconfig index 70fa848..906dd01 100644 --- a/src/mainboard/intel/d945gclf/Kconfig +++ b/src/mainboard/intel/d945gclf/Kconfig @@ -20,7 +20,8 @@ select NORTHBRIDGE_INTEL_I945 select NORTHBRIDGE_INTEL_SUBTYPE_I945GC select SOUTHBRIDGE_INTEL_I82801GX - select SUPERIO_SMSC_LPC47M15X +## changed as per Advantech SOM 4461 + select SUPERIO_WINBOND_W83627DHG select HAVE_OPTION_TABLE select HAVE_CMOS_DEFAULT select HAVE_PIRQ_TABLE diff --git a/src/mainboard/intel/d945gclf/devicetree.cb b/src/mainboard/intel/d945gclf/devicetree.cb index 90c517f..864775a 100644 --- a/src/mainboard/intel/d945gclf/devicetree.cb +++ b/src/mainboard/intel/d945gclf/devicetree.cb @@ -65,44 +65,42 @@ device pci 1d.1 on end # USB UHCI device pci 1d.2 on end # USB UHCI device pci 1d.3 off end # USB UHCI - device pci 1d.7 on end # USB2 EHCI - device pci 1e.0 on end # PCI bridge - device pci 1e.2 off end # AC'97 Audio + device pci 1d.7 on end # USB2 EHCI + device pci 1e.0 on end # PCI bridge + device pci 1e.2 off end # AC'97 Audio device pci 1e.3 off end # AC'97 Modem device pci 1f.0 on # LPC bridge - chip superio/smsc/lpc47m15x - device pnp 2e.0 off # Floppy - end - device pnp 2e.3 off # Parport - end - device pnp 2e.4 on - io 0x60 = 0x3f8 - irq 0x70 = 4 - end - device pnp 2e.5 on - io 0x60 = 0x2f8 - irq 0x70 = 3 - irq 0xf1 = 4 # set IRMODE 0 # XXX not an irq - end - device pnp 2e.7 on # Keyboard+Mouse - io 0x60 = 0x60 - io 0x62 = 0x64 - irq 0x70 = 1 - irq 0x72 = 12 - irq 0xf0 = 0x82 # HW accel A20. - end - device pnp 2e.8 on # GAME - # all default - end - device pnp 2e.a on # PME - end - device pnp 2e.b on # MPU - end - end - end + chip superio/winbond/w83627dhg + device pnp 2e.0 off end # Floppy + device pnp 2e.1 off end # Parallel Port + device pnp 2e.2 on # COM1 + io 0x60 = 0x3f8 + irq 0x70 = 4 + end + device pnp 2e.3 on # COM2 + io 0x60 = 0x2f8 + irq 0x70 = 3 + end + device pnp 2e.5 on # Keyboard,Mouse + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 + irq 0x72 = 12 + end + #device pnp 2e.6 off end # SPI + device pnp 2e.307 off end # GPIO6 + device pnp 2e.8 off end # WDTO, PLED + device pnp 2e.009 off end # GPIO2 + device pnp 2e.109 off end # GPIO3 + device pnp 2e.209 off end # GPIO4 + device pnp 2e.309 off end # GPIO5 + device pnp 2e.A off end # ACPI + device pnp 2e.B off end # HW Monitor + end # w83627dhg + end device pci 1f.1 off end # IDE - device pci 1f.2 on end # SATA - device pci 1f.3 on end # SMBus - end - end + device pci 1f.2 on end # SATA + device pci 1f.3 on end # SMBus + end + end end -- To view, visit https://review.coreboot.org/c/coreboot/+/30798 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I1449d9351bd1b76ecad16e6d81c501c1d4dd80f5 Gerrit-Change-Number: 30798 Gerrit-PatchSet: 1 Gerrit-Owner: junaid <junaidimpex(a)gmail.com> Gerrit-MessageType: newchange

4 3

Change in coreboot[master]: superio/*: Standardise config state entry/exit prototype in pnp_ops.h
by Keith Hui (Code Review) 10 Jun '23

10 Jun '23

Keith Hui has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/40962 ) Change subject: superio/*: Standardise config state entry/exit prototype in pnp_ops.h ...................................................................... superio/*: Standardise config state entry/exit prototype in pnp_ops.h pnp_{entry,exit}_conf_state() is declared and implemented under each super I/O with not that much variation. Place them to a central location along with other pre-RAM pnp functions. This provides a standard pre-RAM PNP API, with the eventual goal of consolidating all implementations, with only one implementation per actual known config state entry/exit sequence. Remove the prototype from winbond/common. All code that use pre-RAM pnp include pnp_ops.h and all basic functions will be brought in. The correct implementation is selected at compile time via Makefile.inc. Change-Id: If4e742edb17ca73c01ff7b552e00e18acc6779dd Signed-off-by: Keith Hui <buurin(a)gmail.com> --- M src/include/device/pnp_ops.h M src/superio/fintek/common/fintek.h M src/superio/winbond/common/winbond.h 3 files changed, 3 insertions(+), 6 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/62/40962/1 diff --git a/src/include/device/pnp_ops.h b/src/include/device/pnp_ops.h index 93a5dc8..f43cb33 100644 --- a/src/include/device/pnp_ops.h +++ b/src/include/device/pnp_ops.h @@ -10,6 +10,9 @@ #if ENV_PNP_SIMPLE_DEVICE +void pnp_enter_conf_state(pnp_devfn_t dev); +void pnp_exit_conf_state(pnp_devfn_t dev); + static __always_inline void pnp_write_config( pnp_devfn_t dev, uint8_t reg, uint8_t value) { diff --git a/src/superio/fintek/common/fintek.h b/src/superio/fintek/common/fintek.h index 81e8e67..915c148 100644 --- a/src/superio/fintek/common/fintek.h +++ b/src/superio/fintek/common/fintek.h @@ -9,7 +9,4 @@ void fintek_enable_serial(pnp_devfn_t dev, u16 iobase); -void pnp_enter_conf_state(pnp_devfn_t dev); -void pnp_exit_conf_state(pnp_devfn_t dev); - #endif /* SUPERIO_FINTEK_COMMON_PRE_RAM_H */ diff --git a/src/superio/winbond/common/winbond.h b/src/superio/winbond/common/winbond.h index 58297e5..9816db0 100644 --- a/src/superio/winbond/common/winbond.h +++ b/src/superio/winbond/common/winbond.h @@ -11,7 +11,4 @@ void winbond_set_pinmux(pnp_devfn_t dev, uint8_t offset, uint8_t mask, uint8_t state); void winbond_set_clksel_48(pnp_devfn_t dev); -void pnp_enter_conf_state(pnp_devfn_t dev); -void pnp_exit_conf_state(pnp_devfn_t dev); - #endif /* SUPERIO_WINBOND_COMMON_PRE_RAM_H */ -- To view, visit https://review.coreboot.org/c/coreboot/+/40962 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: If4e742edb17ca73c01ff7b552e00e18acc6779dd Gerrit-Change-Number: 40962 Gerrit-PatchSet: 1 Gerrit-Owner: Keith Hui <buurin(a)gmail.com> Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-MessageType: newchange

5 11

Change in coreboot[master]: cpu/x86/16bit/entry16.inc: Stop PBET timer on Boot Guard platforms
by Michał Żygowski (Code Review) 10 Jun '23

10 Jun '23

Michał Żygowski has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43395 ) Change subject: cpu/x86/16bit/entry16.inc: Stop PBET timer on Boot Guard platforms ...................................................................... cpu/x86/16bit/entry16.inc: Stop PBET timer on Boot Guard platforms PBET timer has to be stopped before APs are launched and initialized. Otherwise the platform will reset. The PBET expiration time may be very low so stop timer as quickly as possible. The expiration time is defined in Boot Guard manifests. Signed-off-by: Michał Żygowski <michal.zygowski(a)3mdeb.com> Change-Id: I545a36d60597fe37a30b8207336ae7fa7831674d --- M src/cpu/x86/16bit/entry16.inc 1 file changed, 9 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/95/43395/1 diff --git a/src/cpu/x86/16bit/entry16.inc b/src/cpu/x86/16bit/entry16.inc index babed02..c555c5c 100644 --- a/src/cpu/x86/16bit/entry16.inc +++ b/src/cpu/x86/16bit/entry16.inc @@ -29,6 +29,7 @@ #include <cpu/x86/post_code.h> #define BOOTGUARD_SACM_INFO 0x13a +#define BOOTGUARD_PBEC 0x139 /* Symbol _start16bit must be aligned to 4kB to start AP CPUs with * Startup IPI message without RAM. @@ -118,6 +119,14 @@ andl $0x7FFAFFD1, %ebx /* PG,AM,WP,NE,TS,EM,MP = 0 */ orl $0x60000001, %ebx /* CD, NW, PE = 1 */ #if CONFIG(INTEL_BOOTGUARD) + /* + * Stop PBET timer. It is recommended to stop the PBET timer + * regardless of Boot Guard status. + */ + movl $BOOTGUARD_PBEC, %ecx + movl $0, %edx + movl $1, %eax + wrmsr /* DO NOT disable cache if Intel BootGuard is supported */ movl $BOOTGUARD_SACM_INFO, %ecx -- To view, visit https://review.coreboot.org/c/coreboot/+/43395 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I545a36d60597fe37a30b8207336ae7fa7831674d Gerrit-Change-Number: 43395 Gerrit-PatchSet: 1 Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

6 8

Change in coreboot[master]: program layout: align to 64 bytes when Boot Guard is enabled
by Michał Żygowski (Code Review) 10 Jun '23

10 Jun '23

Michał Żygowski has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43401 ) Change subject: program layout: align to 64 bytes when Boot Guard is enabled ...................................................................... program layout: align to 64 bytes when Boot Guard is enabled FIT entries for IBB segmnets have 64 byte granularity. Enforce the 64 bytes alignment on all programs and FIT table to ensure the entires for IBB will be added correctly. Signed-off-by: Michał Żygowski <michal.zygowski(a)3mdeb.com> Change-Id: I3ce09e24d716fe9845104205bc934bd2a0efc9cb --- M src/arch/x86/memlayout.ld M src/cpu/intel/fit/fit.S M src/lib/program.ld 3 files changed, 24 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/01/43401/1 diff --git a/src/arch/x86/memlayout.ld b/src/arch/x86/memlayout.ld index 3659cc9..605ed24 100644 --- a/src/arch/x86/memlayout.ld +++ b/src/arch/x86/memlayout.ld @@ -47,3 +47,8 @@ #include <cpu/intel/fit/fit.ld> #endif #endif /* ENV_BOOTBLOCK */ + +/* Each program stage needs to be 64 bytes aligned to be added as FIT entry */ +#if CONFIG_INTEL_BOOTGUARD +. = ALIGN(64); +#endif diff --git a/src/cpu/intel/fit/fit.S b/src/cpu/intel/fit/fit.S index 3b7396c..037918a 100644 --- a/src/cpu/intel/fit/fit.S +++ b/src/cpu/intel/fit/fit.S @@ -9,7 +9,15 @@ .previous .section .text +#if CONFIG(INTEL_BOOTGUARD) +/* + * FIT must be excluded from IBB with BootGuard. As the IBB segments have 64 + * byte granularity, align the FIT to 64 bytes. + */ +.align 64 +#else .align 16 +#endif .global fit_table .global fit_table_end fit_table: @@ -28,5 +36,12 @@ /* Checksum byte - must add to zero. */ .byte 0x7d .fill CONFIG_CPU_INTEL_NUM_FIT_ENTRIES*16 +#if CONFIG(INTEL_BOOTGUARD) +/* + * Just in case the FIT does not end on 64 byte aligned address, maintain the + * 64 byte boundaries of IBB segments. + */ +.align 64 +#endif fit_table_end: .previous diff --git a/src/lib/program.ld b/src/lib/program.ld index 88a3126..ee105e3 100644 --- a/src/lib/program.ld +++ b/src/lib/program.ld @@ -48,6 +48,10 @@ *(.rodata); *(.rodata.*); . = ALIGN(ARCH_POINTER_ALIGN_SIZE); +#if CONFIG_INTEL_BOOTGUARD +/* Each program stage needs to be 64 bytes aligned to be added as FIT entry */ + . = ALIGN(64); +#endif _etext = .; } : to_load -- To view, visit https://review.coreboot.org/c/coreboot/+/43401 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I3ce09e24d716fe9845104205bc934bd2a0efc9cb Gerrit-Change-Number: 43401 Gerrit-PatchSet: 1 Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-MessageType: newchange

4 6

← Newer
1
...
49
50
51
52
53
54
55
...
68
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit August 2022