303 lines
12 KiB
Markdown
303 lines
12 KiB
Markdown
|
# 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.
|