GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/src/include/boot_device.h

73 lines
2.1 KiB
C
Raw Normal View History

src/include: Use SPDX for GPL-2.0-only files Done with sed and God Lines. Only done for C-like code for now. Change-Id: I2fa3bad88bb5b068baa1cfc6bbcddaabb09da1c5 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40053 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-04-02 23:48:27 +02:00
/* SPDX-License-Identifier: GPL-2.0-only */
tegra124: Add a stub implementation of the tegra124 SOC. Most things still needs to be filled in, but this will allow us to build boards which use this SOC. Change-Id: Ic790685a78193ccb223f4d9355bd3db57812af39 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/170836 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 462456fd00164c10c80eff72240226a04445fe60) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6431 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2013-09-27 01:22:09 +02:00
coreboot: introduce boot_device The boot_device is a region_device that represents the device from which coreboot retrieves and boots its stages. The existing cbfs implementations use the boot_device as the intermediary for accessing the CBFS region. Also, there's currently only support for a read-only view of the boot_device. i.e. one cannot write to the boot_device using this view. However, a writable boot_device could be added in the future. Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10216 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-15 20:15:34 +02:00
#ifndef _BOOT_DEVICE_H_
#define _BOOT_DEVICE_H_
tegra124: Add a stub implementation of the tegra124 SOC. Most things still needs to be filled in, but this will allow us to build boards which use this SOC. Change-Id: Ic790685a78193ccb223f4d9355bd3db57812af39 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/170836 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 462456fd00164c10c80eff72240226a04445fe60) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6431 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2013-09-27 01:22:09 +02:00
coreboot: introduce commonlib Instead of reaching into src/include and re-writing code allow for cleaner code sharing within coreboot and its utilities. The additional thing needed at this point is for the utilities to provide a printk() declaration within a <console/console.h> file. That way code which uses printk() can than be mapped properly to verbosity of utility parameters. Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11592 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-09-08 20:34:43 +02:00
#include <commonlib/region.h>
tegra124: Add a stub implementation of the tegra124 SOC. Most things still needs to be filled in, but this will allow us to build boards which use this SOC. Change-Id: Ic790685a78193ccb223f4d9355bd3db57812af39 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/170836 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 462456fd00164c10c80eff72240226a04445fe60) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6431 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2013-09-27 01:22:09 +02:00
lib/boot_device: Add API for write protect a region Add API that should be implemented by the boot media drivers for write-protecting a subregion. Change-Id: I4c9376e2c2c7a4852f13c65824c6cd64a1c6ac0a Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/c/28724 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-10-26 13:24:42 +02:00
/*
* Boot device region can be protected by 2 sources, media and controller.
* 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
*/
enum bootdev_prot_type {
CTRLR_WP = 1,
CTRLR_RP = 2,
CTRLR_RWP = 3,
MEDIA_WP = 4,
};
lib/boot_device: add RW boot device construct The current boot device usage assumes read-only semantics to the boot device. Any time someone wants to write to the boot device a device-specific API is invoked such as SPI flash. Instead, provide a mechanism to retrieve an object that can be used to perform writes to the boot device. On systems where the implementations are symmetric these devices can be treated one-in-the-same. However, for x86 systems with memory mapped SPI the read-only boot device provides different operations. BUG=chrome-os-partner:55932 Change-Id: I0af324824f9e1a8e897c2453c36e865b59c4e004 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16194 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-10 18:42:42 +02:00
/*
* Please note that the read-only boot device may not be coherent with
* the read-write boot device. Thus, mixing mmap() and writeat() is
* most likely not to work so don't rely on such semantics.
*/
coreboot: introduce boot_device The boot_device is a region_device that represents the device from which coreboot retrieves and boots its stages. The existing cbfs implementations use the boot_device as the intermediary for accessing the CBFS region. Also, there's currently only support for a read-only view of the boot_device. i.e. one cannot write to the boot_device using this view. However, a writable boot_device could be added in the future. Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10216 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-15 20:15:34 +02:00
/* Return the region_device for the read-only boot device. */
const struct region_device *boot_device_ro(void);
lib/boot_device: add RW boot device construct The current boot device usage assumes read-only semantics to the boot device. Any time someone wants to write to the boot device a device-specific API is invoked such as SPI flash. Instead, provide a mechanism to retrieve an object that can be used to perform writes to the boot device. On systems where the implementations are symmetric these devices can be treated one-in-the-same. However, for x86 systems with memory mapped SPI the read-only boot device provides different operations. BUG=chrome-os-partner:55932 Change-Id: I0af324824f9e1a8e897c2453c36e865b59c4e004 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16194 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-10 18:42:42 +02:00
/* Return the region_device for the read-write boot device. */
const struct region_device *boot_device_rw(void);
coreboot: introduce boot_device The boot_device is a region_device that represents the device from which coreboot retrieves and boots its stages. The existing cbfs implementations use the boot_device as the intermediary for accessing the CBFS region. Also, there's currently only support for a read-only view of the boot_device. i.e. one cannot write to the boot_device using this view. However, a writable boot_device could be added in the future. Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10216 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-15 20:15:34 +02:00
/*
* Create a sub-region of the read-only boot device.
* Returns 0 on success, < 0 on error.
*/
int boot_device_ro_subregion(const struct region *sub,
struct region_device *subrd);
lib/boot_device: add RW boot device construct The current boot device usage assumes read-only semantics to the boot device. Any time someone wants to write to the boot device a device-specific API is invoked such as SPI flash. Instead, provide a mechanism to retrieve an object that can be used to perform writes to the boot device. On systems where the implementations are symmetric these devices can be treated one-in-the-same. However, for x86 systems with memory mapped SPI the read-only boot device provides different operations. BUG=chrome-os-partner:55932 Change-Id: I0af324824f9e1a8e897c2453c36e865b59c4e004 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16194 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-10 18:42:42 +02:00
/*
* Create a sub-region of the read-write boot device.
* Returns 0 on success, < 0 on error.
*/
int boot_device_rw_subregion(const struct region *sub,
struct region_device *subrd);
lib/boot_device: Add API for write protect a region Add API that should be implemented by the boot media drivers for write-protecting a subregion. Change-Id: I4c9376e2c2c7a4852f13c65824c6cd64a1c6ac0a Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/c/28724 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-10-26 13:24:42 +02:00
/*
* Write protect a sub-region of the boot device represented
* by the region device.
* Returns 0 on success, < 0 on error.
*/
boot_device: Constify argument Add const qualifier to first argument. Change-Id: I6655e04401b6a7aa5cafb717ff6f46b80b96646e Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32703 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
2019-05-09 13:43:49 +02:00
int boot_device_wp_region(const struct region_device *rd,
lib/boot_device: Add API for write protect a region Add API that should be implemented by the boot media drivers for write-protecting a subregion. Change-Id: I4c9376e2c2c7a4852f13c65824c6cd64a1c6ac0a Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/c/28724 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-10-26 13:24:42 +02:00
const enum bootdev_prot_type type);
coreboot: introduce boot_device The boot_device is a region_device that represents the device from which coreboot retrieves and boots its stages. The existing cbfs implementations use the boot_device as the intermediary for accessing the CBFS region. Also, there's currently only support for a read-only view of the boot_device. i.e. one cannot write to the boot_device using this view. However, a writable boot_device could be added in the future. Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10216 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-15 20:15:34 +02:00
/*
* Initialize the boot device. This may be called multiple times within
* a stage so boot device implementations should account for this behavior.
**/
void boot_device_init(void);
security: Add common boot media write protection Introduce boot media protection settings and use the existing boot_device_wp_region() function to apply settings on all platforms that supports it yet. Also remove the Intel southbridge code, which is now obsolete. Every platform locks the SPIBAR in a different stage. For align up with the common mrc cache driver and lock after it has been written to. Tested on Supermicro X11SSH-TF. The whole address space is write-protected. Change-Id: Iceb3ecf0bde5cec562bc62d1d5c79da35305d183 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32704 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-12-03 19:43:06 +01:00
/*
* Restrict read/write access to the bootmedia using platform defined rules.
*/
security/lockdown: Write-protect WP_RO Allow to write protect only the WP_RO region in case of enabled VBOOT. One can either lock the boot device in VERSTAGE early if VBOOT is enabled, or late in RAMSTAGE. Both options have their downsides as explained below. Lock early if you don't trust the code that's stored in the writeable flash partition. This prevents write-protecting the MRC cache, which is written in ramstage. In case the contents of the MRC cache are corrupted this can lead to system instability or trigger unwanted code flows inside the firmware. Lock late if you trust the code that's stored in the writeable flash partition. This allows write-protecting the MRC cache, but if a vulnerability is found in the code of the writeable partition an attacker might be able to overwrite the whole flash as it hasn't been locked yet. Change-Id: I72c3e1a0720514b9b85b0433944ab5fb7109b2a2 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Christian Walter <christian.walter@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32705 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
2019-05-08 18:36:39 +02:00
#if CONFIG(BOOTMEDIA_LOCK_NONE) || (CONFIG(BOOTMEDIA_LOCK_IN_VERSTAGE) && ENV_RAMSTAGE)
security: Add common boot media write protection Introduce boot media protection settings and use the existing boot_device_wp_region() function to apply settings on all platforms that supports it yet. Also remove the Intel southbridge code, which is now obsolete. Every platform locks the SPIBAR in a different stage. For align up with the common mrc cache driver and lock after it has been written to. Tested on Supermicro X11SSH-TF. The whole address space is write-protected. Change-Id: Iceb3ecf0bde5cec562bc62d1d5c79da35305d183 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32704 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-12-03 19:43:06 +01:00
static inline void boot_device_security_lockdown(void) {}
#else
void boot_device_security_lockdown(void);
#endif
coreboot: introduce boot_device The boot_device is a region_device that represents the device from which coreboot retrieves and boots its stages. The existing cbfs implementations use the boot_device as the intermediary for accessing the CBFS region. Also, there's currently only support for a read-only view of the boot_device. i.e. one cannot write to the boot_device using this view. However, a writable boot_device could be added in the future. Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10216 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-15 20:15:34 +02:00
#endif /* _BOOT_DEVICE_H_ */