commit | 578a4d2b6a0ac96d70ea3b8490872a21dcf19df2 | [log] [tgz] |
---|---|---|
author | Angel Pons <th3fanbus@gmail.com> | Fri Aug 28 00:59:14 2020 +0200 |
committer | Philipp Deppenwiese <zaolin.daisuki@gmail.com> | Sat Oct 17 09:32:47 2020 +0000 |
tree | b10325e23598ba62bc225614a90cec3a544a8927 | |
parent | 038cef9dffdd0df89e50799826e521b1e26b3081 [diff] |
security/intel/txt: Improve MTRR setup for GETSEC[ENTERACCS] The BIOS ACM will check that enabled variable MTRRs do not cover more than the ACM's size, rounded up to 4 KiB. If that is not the case, launching the ACM will result in a lovely TXT reset. How boring. The new algorithm simply performs a reverse bit scan in a loop, and allocates one MTRR for each set bit in the rounded-up size to cache. Before allocating anything, it checks if there are enough variable MTRRs; if not, it will refuse to cache anything. This will result in another TXT reset, initiated by the processor, with error type 5: Load memory type error in Authenticated Code Execution Area. This can only happen if the ACM has specific caching requirements that the current code does not know about, or something has been compromised. Therefore, causing a TXT reset should be a reasonable enough approach. Also, disable all MTRRs before clearing the variable MTRRs and only enable them again once they have been set up with the new values. Tested on Asrock B85M Pro4 with a BIOS ACM whose size is 101504 bytes. Without this patch, launching the ACM would result in a TXT reset. This no longer happens when this patch is applied. Change-Id: I8d411f6450928357544be20250262c2005d1e75d Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44880 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Christian Walter <christian.walter@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot is a Free Software project aimed at replacing the proprietary BIOS (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a payload.
With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like PC BIOS services or UEFI. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required.
coreboot was formerly known as LinuxBIOS.
After the basic initialization of the hardware has been performed, any desired "payload" can be started by coreboot.
See https://www.coreboot.org/Payloads for a list of supported payloads.
coreboot supports a wide range of chipsets, devices, and mainboards.
For details please consult:
ANY_TOOLCHAIN
Kconfig option if you're feeling lucky (no support in this case).Optional:
make menuconfig
and make nconfig
)Please consult https://www.coreboot.org/Build_HOWTO for details.
If you want to test coreboot without any risks before you really decide to use it on your hardware, you can use the QEMU system emulator to run coreboot virtually in QEMU.
Please see https://www.coreboot.org/QEMU for details.
Further details on the project, a FAQ, many HOWTOs, news, development guidelines and more can be found on the coreboot website:
You can contact us directly on the coreboot mailing list:
https://www.coreboot.org/Mailinglist
The copyright on coreboot is owned by quite a large number of individual developers and companies. Please check the individual source files for details.
coreboot is licensed under the terms of the GNU General Public License (GPL). Some files are licensed under the "GPL (version 2, or any later version)", and some files are licensed under the "GPL, version 2". For some parts, which were derived from other projects, other (GPL-compatible) licenses may apply. Please check the individual source files for details.
This makes the resulting coreboot images licensed under the GPL, version 2.