Attention is currently required from: Furquan Shaikh, Ronak Kanabar.
Tim Wawrzynczak has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/56132 )
Change subject: Revert "mb/google/brya: Enable south XHCI ports 1 and 2"
......................................................................
Patch Set 2:
(1 comment)
Patchset:
PS1:
> signed-off check fail
There has got to be some way to fix Gerrit to add that automatically ....
--
To view, visit https://review.coreboot.org/c/coreboot/+/56132
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I82bae21d185247bc0f3580fd6f92abb8eece6732
Gerrit-Change-Number: 56132
Gerrit-PatchSet: 2
Gerrit-Owner: Tim Wawrzynczak <twawrzynczak(a)chromium.org>
Gerrit-Reviewer: EricR Lai <ericr_lai(a)compal.corp-partner.google.com>
Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com>
Gerrit-Reviewer: Ronak Kanabar <ronak.kanabar(a)intel.corp-partner.google.com>
Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-Attention: Furquan Shaikh <furquan(a)google.com>
Gerrit-Attention: Ronak Kanabar <ronak.kanabar(a)intel.corp-partner.google.com>
Gerrit-Comment-Date: Thu, 15 Jul 2021 15:24:41 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: EricR Lai <ericr_lai(a)compal.corp-partner.google.com>
Gerrit-MessageType: comment
Attention is currently required from: James Chao.
Hello build bot (Jenkins),
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/56341
to look at the new patch set (#2).
Change subject: Ampton: Resume from suspend on critical battery
......................................................................
Ampton: Resume from suspend on critical battery
This patch makes Ampton EC wake up AP from s0ix when the state of
charge drops to 2%.
Demonstrated as follows:
1. Boot Ampton.
2. Run powerd_dbus_suspend.
3. On EC, run battfake 2.
4. System resumes.
BUG=b:189540432
BRANCH=Octopus
TEST=Verified on Ampton.
Change-Id: I98d8e6ea185e8782ad675d4668678b341ca5d350
Signed-off-by: james_chao <james_chao(a)asus.corp-partner.google.com>
---
M src/mainboard/google/octopus/variants/ampton/include/variant/ec.h
1 file changed, 5 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/41/56341/2
--
To view, visit https://review.coreboot.org/c/coreboot/+/56341
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I98d8e6ea185e8782ad675d4668678b341ca5d350
Gerrit-Change-Number: 56341
Gerrit-PatchSet: 2
Gerrit-Owner: James Chao <james_chao(a)asus.corp-partner.google.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-Attention: James Chao <james_chao(a)asus.corp-partner.google.com>
Gerrit-MessageType: newpatchset
Attention is currently required from: Furquan Shaikh, Julius Werner.
Raul Rangel has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/56320 )
Change subject: x86/smp/spinlock: Disable thread coop when taking spinlock
......................................................................
Patch Set 1:
(1 comment)
File src/arch/x86/include/arch/smp/spinlock.h:
https://review.coreboot.org/c/coreboot/+/56320/comment/74dccd0a_8f743793
PS1, Line 61: lock->coop = thread_coop_enabled();
> > These spinlocks are primarily for the actual SMP in ramstage, not for the thread mechanism... […]
So I had the same thought as your did about storing it in the thread structure, but there is only 1 thread that can hold the spinlock. So once the core grabs the spinlock it effectively owns the spinlock struct. So storing the coop state into the struct will not result in anything being overridden. Do you both think we should still head down the semaphore route?
--
To view, visit https://review.coreboot.org/c/coreboot/+/56320
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I1b929070b7f175965d4f37be693462fef26be052
Gerrit-Change-Number: 56320
Gerrit-PatchSet: 1
Gerrit-Owner: Raul Rangel <rrangel(a)chromium.org>
Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Julius Werner <jwerner(a)chromium.org>
Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org>
Gerrit-Attention: Furquan Shaikh <furquan(a)google.com>
Gerrit-Attention: Julius Werner <jwerner(a)chromium.org>
Gerrit-Comment-Date: Thu, 15 Jul 2021 14:54:22 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Furquan Shaikh <furquan(a)google.com>
Comment-In-Reply-To: Julius Werner <jwerner(a)chromium.org>
Gerrit-MessageType: comment
Attention is currently required from: Matt DeVillier, Jeremy Soller, Karthik Ramasubramanian.
Tim Wawrzynczak has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/56008 )
Change subject: cannonlake mainboards: Set PMC as hidden in devicetree
......................................................................
Patch Set 3:
(2 comments)
Patchset:
PS2:
> There should be a warning (error?) when it's `on` but hidden by the FSP, right?
Maybe? The P2SB & PMC are I (IIRC) hidden during FSP-S, just before enumeration, so just like any other device that you claim `on` but doesn't enumerate, it will just disappear from the linked list. This does mean that the device callbacks won't be called then, which in this case would be a problem.
In TGL & ADL, we solved this by using the chipset.cb devicetree, which sets PMC to `hidden` for all of those mainboards (thanks for the reminder Nico, should probably set P2SB to hidden as well).
PS2:
> I also seem to remember hat the PMC is hidden early on these […]
I believe it's hidden during FSP-S.
--
To view, visit https://review.coreboot.org/c/coreboot/+/56008
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ib4a20ce9075ce7653388a5d3e281fe774bf89355
Gerrit-Change-Number: 56008
Gerrit-PatchSet: 3
Gerrit-Owner: Tim Wawrzynczak <twawrzynczak(a)chromium.org>
Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com>
Gerrit-Reviewer: Jeremy Soller <jeremy(a)system76.com>
Gerrit-Reviewer: Karthik Ramasubramanian <kramasub(a)google.com>
Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com>
Gerrit-Reviewer: Michael Niewöhner <foss(a)mniewoehner.de>
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org>
Gerrit-Attention: Matt DeVillier <matt.devillier(a)gmail.com>
Gerrit-Attention: Jeremy Soller <jeremy(a)system76.com>
Gerrit-Attention: Karthik Ramasubramanian <kramasub(a)google.com>
Gerrit-Comment-Date: Thu, 15 Jul 2021 14:53:22 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Nico Huber <nico.h(a)gmx.de>
Comment-In-Reply-To: Tim Wawrzynczak <twawrzynczak(a)chromium.org>
Comment-In-Reply-To: Michael Niewöhner <foss(a)mniewoehner.de>
Gerrit-MessageType: comment
Attention is currently required from: Nico Huber.
Hello Nico Huber,
I'd like you to do a code review. Please visit
https://review.coreboot.org/c/coreboot/+/56344
to review the following change.
Change subject: security/lockdown: Add option to allow NVRAM override
......................................................................
security/lockdown: Add option to allow NVRAM override
Some blobs, e.g. Intel FSP, unconditionally lock protection registers
even if their configuration can still be considered insecure. This
makes them incompatible to coreboot's payload concept if the payload
is in charge of bootmedia protection. To work around this, we add an
option to allow coreboot's bootmedia protection to be skipped on re-
quest. Naturally, the payload has to enforce its own rules when this
option is enabled.
Change-Id: Iaed03a4c67ed895c3e54924739c3791d030586f3
Signed-off-by: Nico Huber <nico.huber(a)secunet.com>
---
M src/security/lockdown/Kconfig
M src/security/lockdown/lockdown.c
2 files changed, 23 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/44/56344/1
diff --git a/src/security/lockdown/Kconfig b/src/security/lockdown/Kconfig
index c3bedd0..ca10351d 100644
--- a/src/security/lockdown/Kconfig
+++ b/src/security/lockdown/Kconfig
@@ -130,3 +130,19 @@
Supported by Winbond parts.
endchoice
+
+config BOOTMEDIA_LOCK_NVRAM_OVERRIDE
+ bool "Allow NVRAM option to override lock decision"
+ depends on !BOOTMEDIA_LOCK_NONE
+ help
+ This option makes coreboot query an `inhibit_flashlock` NVRAM option.
+ If this option is enabled, locking will be skipped. This is useful,
+ for instance, if your payload is in charge of locking decisions and
+ a blob, e.g. FSP, doesn't allow payloads to enable locking.
+
+ The NVRAM option will be reset by coreboot, so the opt-out is only
+ temporary.
+
+ Only select this option if you have another software component that
+ takes care of security. Generally, unprivileged software can set
+ the NVRAM option.
diff --git a/src/security/lockdown/lockdown.c b/src/security/lockdown/lockdown.c
index b1ad512..44d92a9 100644
--- a/src/security/lockdown/lockdown.c
+++ b/src/security/lockdown/lockdown.c
@@ -4,6 +4,7 @@
#include <commonlib/region.h>
#include <console/console.h>
#include <bootstate.h>
+#include <option.h>
#include <fmap.h>
/*
@@ -15,6 +16,12 @@
struct region_device dev;
enum bootdev_prot_type lock_type;
+ if (CONFIG(BOOTMEDIA_LOCK_NVRAM_OVERRIDE) && get_uint_option("inhibit_flashlock", 0)) {
+ printk(BIOS_INFO, "BM-LOCKDOWN: Skipping boot media protection on NVRAM request");
+ set_uint_option("inhibit_flashlock", 0);
+ return;
+ }
+
printk(BIOS_DEBUG, "BM-LOCKDOWN: Enabling boot media protection scheme ");
if (CONFIG(BOOTMEDIA_LOCK_CONTROLLER)) {
--
To view, visit https://review.coreboot.org/c/coreboot/+/56344
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Iaed03a4c67ed895c3e54924739c3791d030586f3
Gerrit-Change-Number: 56344
Gerrit-PatchSet: 1
Gerrit-Owner: Felix Singer <felixsinger(a)posteo.net>
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Attention: Nico Huber <nico.h(a)gmx.de>
Gerrit-MessageType: newchange
Attention is currently required from: Nico Huber.
Hello Nico Huber,
I'd like you to do a code review. Please visit
https://review.coreboot.org/c/coreboot/+/56343
to review the following change.
Change subject: security/lockdown: Allow to lock the controller's full address space
......................................................................
security/lockdown: Allow to lock the controller's full address space
Currently implemented for Intel controllers only, BOOTMEDIA_LOCK_MAX_RO
tells the controller driver to write-protect as much address space as
possible. This simplifies things: We do not rely on coreboot's know-
ledge of the size of the bootmedia. And it makes it easier to verify
that the protect is in place by simply checking for the maximum range
again.
Change-Id: Ib4193e37b072b0f9e4ce69fa6ae15b6bcf26eec2
Signed-off-by: Nico Huber <nico.huber(a)secunet.com>
---
M src/drivers/spi/boot_device_rw_nommap.c
M src/include/boot_device.h
M src/include/spi-generic.h
M src/security/lockdown/Kconfig
M src/security/lockdown/lockdown.c
M src/soc/intel/common/block/fast_spi/fast_spi_flash.c
6 files changed, 26 insertions(+), 4 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/43/56343/1
diff --git a/src/drivers/spi/boot_device_rw_nommap.c b/src/drivers/spi/boot_device_rw_nommap.c
index 58efc87..90a98ce 100644
--- a/src/drivers/spi/boot_device_rw_nommap.c
+++ b/src/drivers/spi/boot_device_rw_nommap.c
@@ -117,6 +117,9 @@
case CTRLR_WP:
ctrlr_pr = WRITE_PROTECT;
break;
+ case CTRLR_WP_MAX:
+ ctrlr_pr = WRITE_PROTECT_MAX;
+ break;
case CTRLR_RP:
ctrlr_pr = READ_PROTECT;
break;
diff --git a/src/include/boot_device.h b/src/include/boot_device.h
index 84bd16e..8178842 100644
--- a/src/include/boot_device.h
+++ b/src/include/boot_device.h
@@ -10,16 +10,18 @@
* The following modes are identified. It depends on the flash chip and the
* controller if mode is actually supported.
*
- * MEDIA_WP : Flash/Boot device enforces write protect
- * CTRLR_WP : Controller device enforces write protect
- * CTRLR_RP : Controller device enforces read protect
- * CTRLR_RWP : Controller device enforces read-write protect
+ * MEDIA_WP : Flash/Boot device enforces write protect
+ * CTRLR_WP : Controller device enforces write protect
+ * CTRLR_WP_MAX : Controller device enforces write protect of its whole address space
+ * CTRLR_RP : Controller device enforces read protect
+ * CTRLR_RWP : Controller device enforces read-write protect
*/
enum bootdev_prot_type {
CTRLR_WP = 1,
CTRLR_RP = 2,
CTRLR_RWP = 3,
MEDIA_WP = 4,
+ CTRLR_WP_MAX = 5,
};
/*
* Please note that the read-only boot device may not be coherent with
diff --git a/src/include/spi-generic.h b/src/include/spi-generic.h
index 77a3c09..dfc3813 100644
--- a/src/include/spi-generic.h
+++ b/src/include/spi-generic.h
@@ -107,6 +107,7 @@
READ_PROTECT = 1,
WRITE_PROTECT = 2,
READ_WRITE_PROTECT = 3,
+ WRITE_PROTECT_MAX = 4,
};
enum {
diff --git a/src/security/lockdown/Kconfig b/src/security/lockdown/Kconfig
index 8d48beb..c3bedd0 100644
--- a/src/security/lockdown/Kconfig
+++ b/src/security/lockdown/Kconfig
@@ -43,6 +43,14 @@
you won't be able to write to the whole flash chip using the
internal controller any more.
+config BOOTMEDIA_LOCK_MAX_RO
+ bool "Write-protect the controller's complete address space"
+ depends on SOC_INTEL_COMMON_BLOCK_FAST_SPI
+ depends on BOOTMEDIA_LOCK_CONTROLLER
+ help
+ Select this if you want to write-protect the whole address space of
+ the flash controller.
+
config BOOTMEDIA_LOCK_WHOLE_NO_ACCESS
depends on BOOTMEDIA_LOCK_CONTROLLER
bool "Read- and write-protect the whole boot medium"
diff --git a/src/security/lockdown/lockdown.c b/src/security/lockdown/lockdown.c
index c2e2ac3..b1ad512 100644
--- a/src/security/lockdown/lockdown.c
+++ b/src/security/lockdown/lockdown.c
@@ -21,6 +21,9 @@
if (CONFIG(BOOTMEDIA_LOCK_WHOLE_RO)) {
printk(BIOS_DEBUG, "'readonly'");
lock_type = CTRLR_WP;
+ } else if (CONFIG(BOOTMEDIA_LOCK_MAX_RO)) {
+ printk(BIOS_DEBUG, "'readonly (full address space)'");
+ lock_type = CTRLR_WP_MAX;
} else if (CONFIG(BOOTMEDIA_LOCK_WHOLE_NO_ACCESS)) {
printk(BIOS_DEBUG, "'no access'");
lock_type = CTRLR_RWP;
diff --git a/src/soc/intel/common/block/fast_spi/fast_spi_flash.c b/src/soc/intel/common/block/fast_spi/fast_spi_flash.c
index 1b0652d..4d77452 100644
--- a/src/soc/intel/common/block/fast_spi/fast_spi_flash.c
+++ b/src/soc/intel/common/block/fast_spi/fast_spi_flash.c
@@ -358,6 +358,11 @@
case WRITE_PROTECT:
protect_mask |= SPI_FPR_WPE;
break;
+ case WRITE_PROTECT_MAX:
+ protect_mask |= SPI_FPR_WPE;
+ start = 0x00000000;
+ end = 0xffffffff;
+ break;
case READ_PROTECT:
protect_mask |= SPI_FPR_RPE;
break;
--
To view, visit https://review.coreboot.org/c/coreboot/+/56343
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ib4193e37b072b0f9e4ce69fa6ae15b6bcf26eec2
Gerrit-Change-Number: 56343
Gerrit-PatchSet: 1
Gerrit-Owner: Felix Singer <felixsinger(a)posteo.net>
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Attention: Nico Huber <nico.h(a)gmx.de>
Gerrit-MessageType: newchange