Arthur Heymans has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/44318 )
Change subject: cpu/x86/smm.h: Add function to return the SMM revision
......................................................................
cpu/x86/smm.h: Add function to return the SMM revision
Change-Id: I3e4450088adbb654050e7420956cf58ee1170a98
Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz>
---
M src/cpu/x86/smm/smihandler.c
M src/cpu/x86/smm/smm_module_handler.c
M src/include/cpu/x86/smm.h
3 files changed, 20 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/18/44318/1
diff --git a/src/cpu/x86/smm/smihandler.c b/src/cpu/x86/smm/smihandler.c
index 8fd95bb..8f7ebfb 100644
--- a/src/cpu/x86/smm/smihandler.c
+++ b/src/cpu/x86/smm/smihandler.c
@@ -120,6 +120,14 @@
return (void *)base;
}
+/* This returns the SMM revision from the savestate of CPU0,
+ which is assumed to be the same for all CPU's. See the memory
+ map in smmhandler.S */
+uint32_t smm_revision(void)
+{
+ return *(uint32_t *)(SMM_BASE + SMM_ENTRY_OFFSET * 2 - SMM_REVISION_OFFSET_FROM_TOP);
+}
+
bool smm_region_overlaps_handler(const struct region *r)
{
const struct region r_smm = {SMM_BASE, SMM_DEFAULT_SIZE};
diff --git a/src/cpu/x86/smm/smm_module_handler.c b/src/cpu/x86/smm/smm_module_handler.c
index 02682b4..e50061d 100644
--- a/src/cpu/x86/smm/smm_module_handler.c
+++ b/src/cpu/x86/smm/smm_module_handler.c
@@ -106,6 +106,13 @@
return base;
}
+uint32_t smm_revision(void)
+{
+ const uintptr_t save_state = (uintptr_t)(smm_get_save_state(0));
+
+ return *(uint32_t *)(save_state + smm_runtime->save_state_size - SMM_REVISION_OFFSET_FROM_TOP);
+}
+
bool smm_region_overlaps_handler(const struct region *r)
{
const struct region r_smm = {smm_runtime->smbase, smm_runtime->smm_size};
diff --git a/src/include/cpu/x86/smm.h b/src/include/cpu/x86/smm.h
index a3101e5..ff91c96 100644
--- a/src/include/cpu/x86/smm.h
+++ b/src/include/cpu/x86/smm.h
@@ -175,4 +175,9 @@
/* Print the SMM memory layout on console. */
void smm_list_regions(void);
+#define SMM_REVISION_OFFSET_FROM_TOP (0x8000 - 0x7efc)
+/* Return the SMM revision. The revision is can be fetched from the smm savestate
+ which is always at the same offset downward from the top of the save state. */
+uint32_t smm_revision(void);
+
#endif /* CPU_X86_SMM_H */
--
To view, visit https://review.coreboot.org/c/coreboot/+/44318
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I3e4450088adbb654050e7420956cf58ee1170a98
Gerrit-Change-Number: 44318
Gerrit-PatchSet: 1
Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-MessageType: newchange
Patrick Georgi has submitted this change. ( https://review.coreboot.org/c/coreboot/+/45384 )
Change subject: volteer: set GSPI CS to deasserted by default
......................................................................
volteer: set GSPI CS to deasserted by default
This sets the state of GSPI chip select to 1 (deasserted) as applied
by the FSP during the silicon init phase. GSPI 0 and 1 are set to CS
mode manual in the SerialIoGSpiCsMode section which means we need to
explicitly configure CS to deasserted in the SerialIoGSpiCsState
section. GSPI0 is the CR50 and GSPI1 is the fingerprint sensor. We
were running into problems where the normal expected CS toggle
sequence to wake up CR50 did not work because CS was already asserted
when it was expected to be deasserted, leading to TPM timeouts.
BUG=b:168090038
TEST=booted on volteer, no more "TPM flow control failure" messages;
verified fingerprint enrollment still works.
Change-Id: I47aa5db429d75e66095d58a1eb77963dcfc3b9f3
Signed-off-by: Caveh Jalali <caveh(a)chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45384
Reviewed-by: Tim Wawrzynczak <twawrzynczak(a)chromium.org>
Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org>
---
M src/mainboard/google/volteer/variants/baseboard/devicetree.cb
1 file changed, 2 insertions(+), 2 deletions(-)
Approvals:
build bot (Jenkins): Verified
Tim Wawrzynczak: Looks good to me, approved
diff --git a/src/mainboard/google/volteer/variants/baseboard/devicetree.cb b/src/mainboard/google/volteer/variants/baseboard/devicetree.cb
index 3c1c5f0..11542f8 100644
--- a/src/mainboard/google/volteer/variants/baseboard/devicetree.cb
+++ b/src/mainboard/google/volteer/variants/baseboard/devicetree.cb
@@ -142,8 +142,8 @@
}"
register "SerialIoGSpiCsState" = "{
- [PchSerialIoIndexGSPI0] = 0,
- [PchSerialIoIndexGSPI1] = 0,
+ [PchSerialIoIndexGSPI0] = 1,
+ [PchSerialIoIndexGSPI1] = 1,
[PchSerialIoIndexGSPI2] = 0,
[PchSerialIoIndexGSPI3] = 0,
}"
--
To view, visit https://review.coreboot.org/c/coreboot/+/45384
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I47aa5db429d75e66095d58a1eb77963dcfc3b9f3
Gerrit-Change-Number: 45384
Gerrit-PatchSet: 3
Gerrit-Owner: Caveh Jalali <caveh(a)chromium.org>
Gerrit-Reviewer: Andrey Pronin <apronin(a)chromium.org>
Gerrit-Reviewer: Jes Klinke <jbk(a)chromium.org>
Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)google.com>
Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Reviewer: Tim Wawrzynczak <twawrzynczak(a)chromium.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-MessageType: merged
Werner Zeh has submitted this change. ( https://review.coreboot.org/c/coreboot/+/44814 )
Change subject: Documentation: Add ASan documentation
......................................................................
Documentation: Add ASan documentation
Change-Id: I710ea495798597189941620c7e48fd5aa7476781
Signed-off-by: Harshit Sharma <harshitsharmajs(a)gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44814
Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh(a)siemens.com>
Reviewed-by: Arthur Heymans <arthur(a)aheymans.xyz>
---
A Documentation/technotes/asan.md
M Documentation/technotes/index.md
2 files changed, 303 insertions(+), 0 deletions(-)
Approvals:
build bot (Jenkins): Verified
Werner Zeh: Looks good to me, approved
Arthur Heymans: Looks good to me, approved
diff --git a/Documentation/technotes/asan.md b/Documentation/technotes/asan.md
new file mode 100644
index 0000000..e0d503a
--- /dev/null
+++ b/Documentation/technotes/asan.md
@@ -0,0 +1,302 @@
+# Address Sanitizer
+
+Memory safety is hard to achieve. We, as humans, are bound to make mistakes in
+our code. While it may be straightforward to detect memory corruption bugs in
+few lines of code, it becomes quite challenging to find those bugs in a massive
+code. In such cases, 'Address Sanitizer' may prove to be useful and could help
+save time.
+
+[Address Sanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer)
+, also known as ASan, is a runtime memory debugger designed to find
+out-of-bounds accesses and use-after-scope bugs. coreboot has an in-built
+Address Sanitizer. Therefore, it is advised to take advantage of this debugging
+tool while working on large patches. This would further help to ensure code
+quality and make runtime code more robust.
+
+## Types of errors detected
+ASan in coreboot catches the following types of memory bugs:
+
+### Stack buffer overflow
+Example stack-out-of-bounds:
+```c
+void foo()
+{
+ int stack_array[5] = {0};
+ int i, out;
+ for (i = 0; i < 10; i++)
+ out = stack_array[i];
+}
+```
+In this example, the array is of length 5 but it is being read even beyond the
+index 4.
+
+### Global buffer overflow
+Example global-out-of-bounds:
+```c
+char a[] = "I use coreboot";
+
+void foo()
+{
+ char b[] = "proprietary BIOS";
+ strcpy(a + 6, b);
+}
+```
+In this example,
+> well, you are replacing coreboot with proprietary BIOS. In any case, that's
+an "error".
+
+Let's come to the memory bug. The string 'a' is of length 14 but it is being
+written to even beyond that.
+
+### Use after scope
+Example use-after-scope:
+```c
+volatile int *p = 0;
+
+void foo() {
+ {
+ int x = 0;
+ p = &x;
+ }
+ *p = 5;
+}
+```
+In this example, the value 5 is written to an undefined address instead of the
+variable 'x'. This happens because 'x' can't be accessed outside its scope.
+
+## Using ASan
+
+In order to enable ASan on a supported platform,
+select `Address sanitizer support` from `General setup` menu while configuring
+coreboot.
+
+Then build coreboot and run the image as usual. If your code contains any of the
+above-mentioned memory bugs, ASan will report them in the console log as shown
+below:
+```text
+ASan: <bug type> in <ip>
+<access type> of <access size> bytes at addr <access address>
+```
+where,
+
+`bug type` is either `stack-out-of-bounds`, `global-out-of-bounds` or
+`use-after-scope`,
+
+`ip` is the address of the last good instruction before the bad access,
+
+`access type` is either `Read` or `Write`,
+
+`access size` is the number of bytes read or written, and
+
+`access address` is the memory location which is accessed while the error
+occurs.
+
+Next, you have to use `ip` to retrieve the instruction which causes the error.
+Since stages in coreboot are relocated, you need to normalize `ip`. For this,
+first subtract the start address of the stage from `ip`. Then, read the section
+headers from `<stage>.debug` file to determine the offset of the text segment.
+Add this offset to the difference you calculated earlier. Let's call the
+resultant address `ip'`.
+
+Next, read the contents of the symbol table and search for a function having
+an address closest to `ip'`. This is the function in which our memory bug is
+present. Let's denote the address of this function by `ip''`.
+
+Finally, read the assembly contents of the object file where this function is
+present. Look for the affected function. Here, the instruction which exists at
+the offset `ip' - ip''` corresponds to the address `ip`. Therefore, the very
+next instruction is the one which causes the error.
+
+To see ASan in action, let's take an example. Suppose, there is a
+stack-out-of-bounds error in cbfs.c that we aren’t aware of and we want ASan
+to help us detect it.
+```c
+int cbfs_boot_region_device(struct region_device *rdev)
+{
+ int array[5], i;
+ boot_device_init();
+
+ for (i = 10; i > 0; i--)
+ array[i] = i;
+
+ return vboot_locate_cbfs(rdev) &&
+ fmap_locate_area_as_rdev("COREBOOT", rdev);
+}
+```
+First, we enable ASan from the configuration menu as shown above. Then, we
+build coreboot and run the image.
+
+ASan reports the following error in the console log:
+```text
+ASan: stack-out-of-bounds in 0x7f7432fd
+Write of 4 bytes at addr 0x7f7c2ac8
+```
+Here 0x7f7432fd is `ip` i.e. the address of the last good instruction before
+the bad access. First we have to normalize this address as stated above.
+As per the console log, this error happened in ramstage and the stage starts
+from 0x7f72c000. So, let’s look at the sections headers of ramstage from
+`ramstage.debug`.
+```text
+$ objdump -h build/cbfs/fallback/ramstage.debug
+
+build/cbfs/fallback/ramstage.debug: file format elf32-i386
+
+Sections:
+Idx Name Size VMA LMA File off Algn
+ 0 .text 00070b20 00e00000 00e00000 00001000 2**12
+ CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
+ 1 .ctors 0000036c 00e70b20 00e70b20 00071b20 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, DATA
+ 2 .data 0001c8f4 00e70e8c 00e70e8c 00071e8c 2**2
+ CONTENTS, ALLOC, LOAD, RELOC, DATA
+ 3 .bss 00012940 00e8d780 00e8d780 0008e780 2**7
+ ALLOC
+ 4 .heap 00004000 00ea00c0 00ea00c0 0008e780 2**0
+ ALLOC
+```
+As you can see, the offset of the text segment is 0x00e00000. Let's subtract the
+start address of the stage from `ip` and add this offset to the difference. The
+resultant address i.e. `ip'` is 0x00e172fd.
+
+Next, we read the contents of the symbol table and search for a function having
+an address closest to 0x00e172fd.
+```text
+$ nm -n build/cbfs/fallback/ramstage.debug
+........
+........
+00e17116 t _GLOBAL__sub_I_65535_1_gfx_get_init_done
+00e17129 t tohex16
+00e171db T cbfs_load_and_decompress
+00e1729b T cbfs_boot_region_device
+00e17387 T cbfs_boot_locate
+00e1740d T cbfs_boot_map_with_leak
+00e174ef T cbfs_boot_map_optionrom
+........
+........
+```
+The symbol having an address closest to 0x00e172fd is `cbfs_boot_region_device` and
+its address i.e. `ip''` is 0x00e1729b.
+
+Now, as we know the affected function, let's read the assembly contents of
+`cbfs_boot_region_device()` which is present in `cbfs.o` to find the faulty
+instruction.
+```text
+$ objdump -d build/ramstage/lib/cbfs.o
+........
+........
+ 51: e8 fc ff ff ff call 52 <cbfs_boot_region_device+0x52>
+ 56: 83 ec 0c sub $0xc,%esp
+ 59: 57 push %edi
+ 5a: 83 ef 04 sub $0x4,%edi
+ 5d: e8 fc ff ff ff call 5e <cbfs_boot_region_device+0x5e>
+ 62: 83 c4 10 add $0x10,%esp
+ 65: 89 5f 04 mov %ebx,0x4(%edi)
+ 68: 4b dec %ebx
+ 69: 75 eb jne 56 <cbfs_boot_region_device+0x56>
+........
+........
+```
+Here, we look for the instruction present at the offset 62 i.e. `ip' - ip''`.
+The instruction is `add $0x10,%esp` and it corresponds to
+`for (i = 10; i > 0; i--)` in our code. It means the very next instruction
+i.e. `mov %ebx,0x4(%edi)` is the one that causes the error. Now, as we look at
+C code of `cbfs_boot_region_device()` again, we find that this instruction
+corresponds to `array[i] = i`.
+
+Voilà! We just caught the memory bug using ASan.
+
+## Supported platforms
+Presently, the following architectures support ASan in ramstage:
+```eval_rst
++------------------+--------------------------------+
+| Architecture | Notes |
++==================+================================+
+| x86 | Support for all x86 platforms |
++------------------+--------------------------------+
+```
+
+And in romstage ASan is available on the following platforms:
+```eval_rst
++---------------------+-----------------------------+
+| Platform | Notes |
++=====================+=============================+
+| QEMU i440-fx | |
++---------------------+-----------------------------+
+| Intel Apollo Lake | |
++---------------------+-----------------------------+
+| Intel Haswell | |
++---------------------+-----------------------------+
+```
+Alternatively, you can use `grep` to view the list of platforms that support
+ASan in romstage:
+
+ $ git grep "select HAVE_ASAN_IN_ROMSTAGE"
+
+If the x86 platform you are using is not listed here, there is
+still a chance that it supports ASan in romstage.
+
+To test it, select `HAVE_ASAN_IN_ROMSTAGE` from the Kconfig file in the
+platform's dedicated directory. Then, enable ASan from the config menu as
+indicated in the previous section.
+
+If you are able to build coreboot without any errors and boot cleanly, that
+means the platform supports ASan in romstage. In that case, please upload a
+patch on Gerrit selecting this config option using 'ASan' topic. Also, update
+the platform name in the table.
+
+However, if you end up in compilation errors or the linker error saying that
+the cache got full, additional steps need to be taken to enable ASan in
+romstage on the platform. While compile errors could be resolved easily and
+therefore ASan in romstage has a good chance to be supported, a full cache is
+an indication that it is way more work or even likely impossible to enable
+ASan in romstage.
+
+## Future work
+### Heap buffer overflow
+Presently, ASan doesn't detect out-of-bounds accesses for the objects defined
+in heap.
+
+To add support for these type of memory bugs, you have to make sure that
+whenever some block of memory is allocated in the heap, the surrounding areas
+(redzones) are poisoned. Correspondingly, these redzones should be unpoisoned
+when the memory block is de-allocated.
+
+### ASan on other architectures
+The following points should help when adding support for ASan to other
+architectures like ARM or RISC-V:
+
+* Enabling ASan in ramstage on other architectures should be easy. You just
+have to make sure the shadow memory is initialized as early as possible when
+ramstage is loaded. This can be done by making a function call to `asan_init()`
+at the appropriate place.
+
+* For romstage, you have to find out if there is enough room in the cache to fit
+the shadow memory region. For this, find the boundary linker symbols for the
+region you'd want to run ASan on, excluding the hardware mapped addresses.
+Then define a new linker section named `asan_shadow` of size
+`(_end - _start) >> 3`, where `_start` and `_end` are the linker symbols you
+found earlier. This section should be appended to the region already occupied
+by the coreboot program. Now build coreboot. If you don't see any errors while
+building with the current translation function, ASan can be enabled on that
+platform.
+
+* The shadow region we currently use consumes memory equal to 1/8th of the
+program memory. So, if you end up in a linker error saying that the memory got
+full, you'll have to use a more compact shadow region. In that case, the
+translation function could be something like
+`shadow = (mem >> 7) | shadow_offset`. Since the stack buffers are protected by
+the compiler, you'll also have to create a GCC patch forcing it to use the new
+translation function for this particular architecture.
+
+* Once you are sure that the architecture supports ASan in ramstage, select
+`HAVE_ASAN_IN_RAMSTAGE` from the Kconfig file of that architecture. Similarly,
+if the platform supports ASan in romstage, select `HAVE_ASAN_IN_ROMSTAGE` from
+the platform's dedicated Kconfig file.
+
+### Post-processing script
+Unlike Linux, coreboot doesn't have `%pS` printk format to dereference pointer
+to its symbolic name. Therefore, we normalise the pointer address manually to
+determine the name of the affected function and further use it to find the
+instruction which causes the error.
+
+A custom script can be written to automate this process.
diff --git a/Documentation/technotes/index.md b/Documentation/technotes/index.md
index 5367e69..a9320fb 100644
--- a/Documentation/technotes/index.md
+++ b/Documentation/technotes/index.md
@@ -3,3 +3,4 @@
* [Dealing with Untrusted Input in SMM](2017-02-dealing-with-untrusted-input-in-smm.md)
* [Rebuilding coreboot image generation](2015-11-rebuilding-coreboot-image-generation.md)
* [Unit testing coreboot](2020-03-unit-testing-coreboot.md)
+* [Address Sanitizer](asan.md)
--
To view, visit https://review.coreboot.org/c/coreboot/+/44814
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I710ea495798597189941620c7e48fd5aa7476781
Gerrit-Change-Number: 44814
Gerrit-PatchSet: 8
Gerrit-Owner: Harshit Sharma <harshitsharmajs(a)gmail.com>
Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com>
Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net>
Gerrit-Reviewer: Werner Zeh <werner.zeh(a)siemens.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-MessageType: merged