# 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.