GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/security/vboot/vboot_loader.c

93 lines
2.6 KiB
C
Raw Normal View History

vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
/*
* This file is part of the coreboot project.
*
* Copyright 2015 Google, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include <cbfs.h>
#include <console/console.h>
vboot: consolidate google_chromeec_early_init() calls On x86 platforms, google_chromeec_early_init() is used to put the EC into RO mode when there's a recovery request. This is to avoid training memory multiple times when the recovery request is through an EC host event while the EC is running RW code. Under that condition the EC will be reset (along with the rest of the system) when the kernel verification happens. This leads to an execessively long recovery path because of the double reboot performing full memory training each time. By putting this logic into the verstage program this reduces the bootblock size on the skylake boards. Additionally, this provides the the correct logic for all future boards since it's not tied to FSP nor the mainboard itself. Lastly, this double memory training protection works only for platforms which verify starting from bootblock. The platforms which don't start verifying until after romstage need to have their own calls (such as haswell and baytrail). Change-Id: Ia8385dfc136b09fb20bd3519f3cc621e540b11a5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16318 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-08-24 21:58:12 +02:00
#include <ec/google/chromeec/ec.h>
vboot: handle RELOCATABLE_RAMSTAGE The support for RELOCATABLE_RAMSTAGE was accidentally omitted in the vboot loader. Add said support. Change-Id: I569918823253c33f698acefd6a619133543c7aef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10184 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-05-12 23:43:10 +02:00
#include <rmodule.h>
security/vboot: Move vboot2 to security kconfig section This commit just moves the vboot sources into the security directory and fixes kconfig/makefile paths. Fix vboot2 headers Change-Id: Icd87f95640186f7a625242a3937e1dd13347eb60 Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org> Reviewed-on: https://review.coreboot.org/22074 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-10-17 17:02:29 +02:00
#include <security/vboot/misc.h>
#include <security/vboot/symbols.h>
#include <security/vboot/vboot_common.h>
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
vboot: Disallow separate verstage after romstage, try to clarify logic No board has ever tried to combine CONFIG_SEPARATE_VERSTAGE with CONFIG_VBOOT_STARTS_IN_ROMSTAGE. There are probably many reasons why this wouldn't work (e.g. x86 CAR migration logic currently always assumes verstage code to run pre-migration). It would also not really make sense: the reason we use separate verstages is to decrease bootblock size (mitigating the boot speed cost of slow boot ROM SPI drivers) and to allow the SRAM-saving RETURN_FROM_VERSTAGE trick, neither of which would apply to the after-romstage case. It is better to just forbid that case explicitly and give programmers more guarantees about what the verstage is (e.g. now the assumption that it runs pre-RAM is always valid). Since Kconfig dependencies aren't always guaranteed in the face of 'select' statements, also add some explicit compile-time assertions to the vboot code. We can simplify some of the loader logic which now no longer needs to provide for the forbidden case. In addition, also try to make some of the loader logic more readable by writing it in a more functional style that allows us to put more assertions about which cases should be unreachable in there, which will hopefully make it more robust and fail-fast with future changes (e.g. addition of new stages). Change-Id: Iaf60040af4eff711d9b80ee0e5950ce05958b3aa Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18983 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2017-03-18 00:54:48 +01:00
/* Ensure vboot configuration is valid: */
coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX) This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06 01:53:33 +01:00
_Static_assert(CONFIG(VBOOT_STARTS_IN_BOOTBLOCK) +
CONFIG(VBOOT_STARTS_IN_ROMSTAGE) == 1,
vboot: Disallow separate verstage after romstage, try to clarify logic No board has ever tried to combine CONFIG_SEPARATE_VERSTAGE with CONFIG_VBOOT_STARTS_IN_ROMSTAGE. There are probably many reasons why this wouldn't work (e.g. x86 CAR migration logic currently always assumes verstage code to run pre-migration). It would also not really make sense: the reason we use separate verstages is to decrease bootblock size (mitigating the boot speed cost of slow boot ROM SPI drivers) and to allow the SRAM-saving RETURN_FROM_VERSTAGE trick, neither of which would apply to the after-romstage case. It is better to just forbid that case explicitly and give programmers more guarantees about what the verstage is (e.g. now the assumption that it runs pre-RAM is always valid). Since Kconfig dependencies aren't always guaranteed in the face of 'select' statements, also add some explicit compile-time assertions to the vboot code. We can simplify some of the loader logic which now no longer needs to provide for the forbidden case. In addition, also try to make some of the loader logic more readable by writing it in a more functional style that allows us to put more assertions about which cases should be unreachable in there, which will hopefully make it more robust and fail-fast with future changes (e.g. addition of new stages). Change-Id: Iaf60040af4eff711d9b80ee0e5950ce05958b3aa Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18983 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2017-03-18 00:54:48 +01:00
"vboot must either start in bootblock or romstage (not both!)");
coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX) This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06 01:53:33 +01:00
_Static_assert(!CONFIG(VBOOT_SEPARATE_VERSTAGE) ||
CONFIG(VBOOT_STARTS_IN_BOOTBLOCK),
vboot: Disallow separate verstage after romstage, try to clarify logic No board has ever tried to combine CONFIG_SEPARATE_VERSTAGE with CONFIG_VBOOT_STARTS_IN_ROMSTAGE. There are probably many reasons why this wouldn't work (e.g. x86 CAR migration logic currently always assumes verstage code to run pre-migration). It would also not really make sense: the reason we use separate verstages is to decrease bootblock size (mitigating the boot speed cost of slow boot ROM SPI drivers) and to allow the SRAM-saving RETURN_FROM_VERSTAGE trick, neither of which would apply to the after-romstage case. It is better to just forbid that case explicitly and give programmers more guarantees about what the verstage is (e.g. now the assumption that it runs pre-RAM is always valid). Since Kconfig dependencies aren't always guaranteed in the face of 'select' statements, also add some explicit compile-time assertions to the vboot code. We can simplify some of the loader logic which now no longer needs to provide for the forbidden case. In addition, also try to make some of the loader logic more readable by writing it in a more functional style that allows us to put more assertions about which cases should be unreachable in there, which will hopefully make it more robust and fail-fast with future changes (e.g. addition of new stages). Change-Id: Iaf60040af4eff711d9b80ee0e5950ce05958b3aa Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18983 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2017-03-18 00:54:48 +01:00
"stand-alone verstage must start in (i.e. after) bootblock");
coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX) This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06 01:53:33 +01:00
_Static_assert(!CONFIG(VBOOT_RETURN_FROM_VERSTAGE) ||
CONFIG(VBOOT_SEPARATE_VERSTAGE),
vboot: Disallow separate verstage after romstage, try to clarify logic No board has ever tried to combine CONFIG_SEPARATE_VERSTAGE with CONFIG_VBOOT_STARTS_IN_ROMSTAGE. There are probably many reasons why this wouldn't work (e.g. x86 CAR migration logic currently always assumes verstage code to run pre-migration). It would also not really make sense: the reason we use separate verstages is to decrease bootblock size (mitigating the boot speed cost of slow boot ROM SPI drivers) and to allow the SRAM-saving RETURN_FROM_VERSTAGE trick, neither of which would apply to the after-romstage case. It is better to just forbid that case explicitly and give programmers more guarantees about what the verstage is (e.g. now the assumption that it runs pre-RAM is always valid). Since Kconfig dependencies aren't always guaranteed in the face of 'select' statements, also add some explicit compile-time assertions to the vboot code. We can simplify some of the loader logic which now no longer needs to provide for the forbidden case. In addition, also try to make some of the loader logic more readable by writing it in a more functional style that allows us to put more assertions about which cases should be unreachable in there, which will hopefully make it more robust and fail-fast with future changes (e.g. addition of new stages). Change-Id: Iaf60040af4eff711d9b80ee0e5950ce05958b3aa Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18983 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2017-03-18 00:54:48 +01:00
"return from verstage only makes sense for separate verstages");
security/vboot: Drop CAR_GLOBAL_MIGRATION support Change-Id: I9dee03da028b9111b685e325368815a86e444a47 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37028 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-11-20 19:47:10 +01:00
int vboot_executed;
cbfs/vboot: remove firmware component support The Chrome OS verified boot path supported multiple CBFS instances in the boot media as well as stand-alone assets sitting in each vboot RW slot. Remove the support for the stand-alone assets and always use CBFS accesses as the way to retrieve data. This is implemented by adding a cbfs_locator object which is queried for locating the current CBFS. Additionally, it is also signalled prior to when a program is about to be loaded by coreboot for the subsequent stage/payload. This provides the same opportunity as previous for vboot to hook in and perform its logic. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. CQ-DEPEND=CL:307121,CL:31691,CL:31690 Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12689 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-09 00:00:23 +01:00
security/vboot: Removed vboot_prepare from vboot_locator When prog_locate() is called in the stage VBOOT is starting from and the image to be loaded is not the target image vboot_prepare() may be called too early. To prevent this vboot_prepare() is removed from the vboot_locator structure. This allows more control over the start of the vboot logic. To clarify the change the vboot_prepare() has been renamed to vboot_run_logic() and calls to initialize vboot have been added at the following places: postcar_loader: when VBOOT starts in ROMSTAGE romstage_loader: when VBOOT starts in BOOTBLOCK ramstage_loader: when VBOOT starts in ROMSTAGE BUG=N/A TEST=tested on facebook fbg1701 Change-Id: Id5e8fd78458c09dd3896bfd142bd49c2c3d686df Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36543 Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-11-01 10:22:22 +01:00
void vboot_run_logic(void)
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
{
vboot: Call verification_should_run directly in the if statement Using a dedicated variable is slightly less readable and makes the code less consistent, given that other test functions are called directly in the if statements. Change-Id: If52b2a4268acb1e2187574d15cc73a0c1d5fe9bb Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-on: https://review.coreboot.org/14817 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-05-14 15:30:52 +02:00
if (verification_should_run()) {
vboot: Move remaining features out of vendorcode/google/chromeos This patch attempts to finish the separation between CONFIG_VBOOT and CONFIG_CHROMEOS by moving the remaining options and code (including image generation code for things like FWID and GBB flags, which are intrinsic to vboot itself) from src/vendorcode/google/chromeos to src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig options, and clean up menuconfig visibility for them (i.e. some options were visible even though they were tied to the hardware while others were invisible even though it might make sense to change them). CQ-DEPEND=CL:459088 Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18984 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-02-14 02:53:29 +01:00
/* Note: this path is not used for VBOOT_RETURN_FROM_VERSTAGE */
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
verstage_main();
security/vboot: Drop CAR_GLOBAL_MIGRATION support Change-Id: I9dee03da028b9111b685e325368815a86e444a47 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37028 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-11-20 19:47:10 +01:00
vboot_executed = 1;
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
} else if (verstage_should_load()) {
cbfs: add struct cbfsf Now that cbfs is adding more metadata in the cbfs file header one needs to access that metadata. Therefore, add struct cbfsf which tracks the metadata and data of the file separately. Note that stage and payload metadata specific to itself is still contained within the 'data' portion of a cbfs file. Update the cbfs API to use struct cbfsf. Additionally, remove struct cbfsd as there's nothing else associated with a cbfs region aside from offset and size which tracked by a region_device (thanks, CBFS_ALIGNMENT!). BUG=None BRANCH=None TEST=Built and booted through end of ramstage on qemu armv7. Built and booted glados using Chrome OS. Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11679 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-17 23:09:30 +02:00
struct cbfsf file;
assets: abstract away the firmware assets used for booting As there can be more than one source of firmware assets this patch generalizes the notion of locating a particular asset. struct asset is added along with some helper functions for working on assets as a first class citizen. Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10264 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-20 19:08:55 +02:00
struct prog verstage =
lib: remove assets infrastructure Now that only CBFS access is supported for finding resources within the boot media the assets infrastructure can be removed. Remove it. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12690 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-08 21:34:35 +01:00
PROG_INIT(PROG_VERSTAGE,
assets: abstract away the firmware assets used for booting As there can be more than one source of firmware assets this patch generalizes the notion of locating a particular asset. struct asset is added along with some helper functions for working on assets as a first class citizen. Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10264 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-20 19:08:55 +02:00
CONFIG_CBFS_PREFIX "/verstage");
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
vboot: indicate verstage loading on console There was no indication of verstage being loaded. Provide this output so that one can follow the flow from console messages. Change-Id: I67ae6bb334608fe10a4a12fe690498afaf6b8366 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10195 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-13 20:33:27 +02:00
printk(BIOS_DEBUG, "VBOOT: Loading verstage.\n");
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
/* load verstage from RO */
cbfs: add struct cbfsf Now that cbfs is adding more metadata in the cbfs file header one needs to access that metadata. Therefore, add struct cbfsf which tracks the metadata and data of the file separately. Note that stage and payload metadata specific to itself is still contained within the 'data' portion of a cbfs file. Update the cbfs API to use struct cbfsf. Additionally, remove struct cbfsd as there's nothing else associated with a cbfs region aside from offset and size which tracked by a region_device (thanks, CBFS_ALIGNMENT!). BUG=None BRANCH=None TEST=Built and booted through end of ramstage on qemu armv7. Built and booted glados using Chrome OS. Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11679 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-17 23:09:30 +02:00
if (cbfs_boot_locate(&file, prog_name(&verstage), NULL))
die("failed to load verstage");
cbfs_file_data(prog_rdev(&verstage), &file);
if (cbfs_prog_stage_load(&verstage))
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
die("failed to load verstage");
/* verify and select a slot */
prog_run(&verstage);
/* This is not actually possible to hit this condition at
* runtime, but this provides a hint to the compiler for dead
* code elimination below. */
coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX) This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06 01:53:33 +01:00
if (!CONFIG(VBOOT_RETURN_FROM_VERSTAGE))
cbfs/vboot: remove firmware component support The Chrome OS verified boot path supported multiple CBFS instances in the boot media as well as stand-alone assets sitting in each vboot RW slot. Remove the support for the stand-alone assets and always use CBFS accesses as the way to retrieve data. This is implemented by adding a cbfs_locator object which is queried for locating the current CBFS. Additionally, it is also signalled prior to when a program is about to be loaded by coreboot for the subsequent stage/payload. This provides the same opportunity as previous for vboot to hook in and perform its logic. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. CQ-DEPEND=CL:307121,CL:31691,CL:31690 Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12689 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-09 00:00:23 +01:00
return;
security/vboot: Drop CAR_GLOBAL_MIGRATION support Change-Id: I9dee03da028b9111b685e325368815a86e444a47 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37028 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-11-20 19:47:10 +01:00
vboot_executed = 1;
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
}
}
cbfs: switch to region_device for location APIs Drop struct cbfs_props and replace with struct region_device object. The goal of the cbfs locator APIs are to determine the correct region device to find the cbfs files. Therefore, start directly using struct region_device in the cbfs location paths. Update the users of the API and leverage the default boot region device implementation for apollolake. Change-Id: I0158a095cc64c9900d8738f8ffd45ae4040575ea Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36939 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-11-18 20:35:21 +01:00
static int vboot_locate(struct region_device *rdev)
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
{
security/vboot: Ensure firmware body size is respected again CB:36845 simplified how coreboot finds the RW CBFS after vboot has and eliminated a layer of caching. Unfortunately, we missed the fact that the former cached value didn't exactly match the FMAP section... it was in fact truncated to the data actually used by vboot. That patch unintentionally broke this truncation which leads to performance regressions on certain CBFS accesses. This patch makes use of a new API function added to vboot (CL:1965920) which we can use to retrieve the real firmware body length as before. (Also stop making all the vb2_context pointers const. vboot generally never marks context pointers as const in its API functions, even when the function doesn't modify the context. Therefore constifying it inside coreboot just makes things weird because it prevents you from calling random API functions for no reason. If we really want const context pointers, that's a refactoring that would have to start inside vboot first.) This patch brings in upstream vboot commit 4b0408d2: 2019-12-12 Julius Werner 2lib: Move firmware body size reporting to separate function Change-Id: I167cd40cb435dbae7f09d6069c9f1ffc1d99fe13 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37680 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Mathew King <mathewk@chromium.org>
2019-12-12 22:23:06 +01:00
struct vb2_context *ctx;
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
cbfs/vboot: remove firmware component support The Chrome OS verified boot path supported multiple CBFS instances in the boot media as well as stand-alone assets sitting in each vboot RW slot. Remove the support for the stand-alone assets and always use CBFS accesses as the way to retrieve data. This is implemented by adding a cbfs_locator object which is queried for locating the current CBFS. Additionally, it is also signalled prior to when a program is about to be loaded by coreboot for the subsequent stage/payload. This provides the same opportunity as previous for vboot to hook in and perform its logic. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. CQ-DEPEND=CL:307121,CL:31691,CL:31690 Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12689 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-09 00:00:23 +01:00
/* Don't honor vboot results until the vboot logic has run. */
vboot: rename symbols for better consistency Symbols prefixed with vb2_ should be reserved for internal vboot library use. Anything outside of that may choose some other prefix. Here, we choose vboot_ instead. Also, add some documentation to security/vboot/misc.h, which provides headers for a number of different C files. BUG=b:124141368 TEST=Build and deploy to eve TEST=util/lint/checkpatch.pl -g origin/master..HEAD TEST=util/abuild/abuild -B -e -y -c 50 -p none -x TEST=make clean && make test-abuild BRANCH=none Change-Id: I5d9154fd2d5df25ee254bd5ce4a173afaa6588be Signed-off-by: Joel Kitching <kitching@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31886 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-13 15:38:07 +01:00
if (!vboot_logic_executed())
vboot: use only offsets for tracking firmware components Because of the fmap API returning pointers to represent regions within the boot device a vboot_region structure was used to track the case where offsets could be pointers on x86 but not on !x86. Normalize this tracking to use offsets only as it provides consistency in the code. Change-Id: I63c08b31ace3bd0e66ebc17e308f87eb5f857c86 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10221 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-15 22:57:51 +02:00
return -1;
security/vboot: Remove selected_region from struct vboot_working_data Since we already have pre-RAM cache for FMAP (CB:36657), calling load_firmware() multiple times is no longer a problem. This patch replaces vboot_get_selected_region() usage with vboot_locate_firmware(), which locates the firmware by reading from the CBMEM cache. In addition, returning false from vboot_is_slot_selected() implies the recovery path was requested, i.e., vb2_shared_data.recovery_reason was set. Therefore, we simply remove the vboot_is_slot_selected() check from vboot_check_recovery_request(). BRANCH=none BUG=chromium:1021452 TEST=emerge-kukui coreboot Change-Id: I27cb1a2175beb189053fc3e44b17b60aba474bb0 Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36845 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-11-14 08:42:25 +01:00
ctx = vboot_get_context();
if (ctx->flags & VB2_CONTEXT_RECOVERY_MODE)
return -1;
cbfs: switch to region_device for location APIs Drop struct cbfs_props and replace with struct region_device object. The goal of the cbfs locator APIs are to determine the correct region device to find the cbfs files. Therefore, start directly using struct region_device in the cbfs location paths. Update the users of the API and leverage the default boot region device implementation for apollolake. Change-Id: I0158a095cc64c9900d8738f8ffd45ae4040575ea Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36939 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-11-18 20:35:21 +01:00
return vboot_locate_firmware(ctx, rdev);
cbfs: new API and better program loading A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-16 06:39:23 +02:00
}
cbfs/vboot: remove firmware component support The Chrome OS verified boot path supported multiple CBFS instances in the boot media as well as stand-alone assets sitting in each vboot RW slot. Remove the support for the stand-alone assets and always use CBFS accesses as the way to retrieve data. This is implemented by adding a cbfs_locator object which is queried for locating the current CBFS. Additionally, it is also signalled prior to when a program is about to be loaded by coreboot for the subsequent stage/payload. This provides the same opportunity as previous for vboot to hook in and perform its logic. BUG=chromium:445938 BRANCH=None TEST=Built and ran on glados. CQ-DEPEND=CL:307121,CL:31691,CL:31690 Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/12689 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-09 00:00:23 +01:00
const struct cbfs_locator vboot_locator = {
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
.name = "VBOOT",
cbfs: new API and better program loading A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-16 06:39:23 +02:00
.locate = vboot_locate,
vboot: inject vboot loader for stage loading As previously done the vboot loader can be optionally inserted in the stage loading logic in order to decide the source of each stage. This current patch allows for verstage to be loaded and interrogated for the source of all subsequent stages. Additionally, it's also possible to build this logic directly into one of the additional stages. Note that this patch does not allow x86 to work. Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10154 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-01 23:48:54 +02:00
};
Reference in a new issue Copy permalink