Hello,
In the configuration makefile mk/config.mk there are following lines:
# Enable support for detected undefined behavior in C # Uses a lot of memory, can't be enabled by default CFG_CORE_SANITIZE_UNDEFINED ?= n
I've read the sources of the conditionally compiled ubsan.c and, IIUC, how UBSAN is working (mostly by adding simple checks), I don't understand, why UBSAN is marked as using a lot of memory.
Is this comment still valid?
Thank you.
Hi Igor,
On Mon, 5 Feb 2024 at 13:13, Igor Zhbanov izh1979@gmail.com wrote:
Hello,
In the configuration makefile mk/config.mk there are following lines:
# Enable support for detected undefined behavior in C # Uses a lot of memory, can't be enabled by default CFG_CORE_SANITIZE_UNDEFINED ?= n
I've read the sources of the conditionally compiled ubsan.c and, IIUC, how UBSAN is working (mostly by adding simple checks), I don't understand, why UBSAN is marked as using a lot of memory.
Is this comment still valid?
I don't know, but the latest info about USBSAN is that it fails to build on the master branch so I can't even try it and check the memory usage :-/
See https://github.com/OP-TEE/optee_os/issues/6463.
Jérôme, thanks.
пн, 5 февр. 2024 г. в 17:22, Jérôme Forissier jerome.forissier@linaro.org:
I don't know, but the latest info about USBSAN is that it fails to build on the master branch so I can't even try it and check the memory usage :-/
I was curious, how UBSAN is affecting the Linux kernel, so, I've built openSUSE kernel on x86_64 with the default distribution configuration, then checked the sized of the stripped files vmlinux and vmlinux.o.
# CONFIG_UBSAN is not set: vmlinux 48 237 768 vmlinux.o 31 664 696
CONFIG_UBSAN=y # CONFIG_UBSAN_TRAP is not set CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_BOUNDS=y CONFIG_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_SHIFT=y CONFIG_UBSAN_DIV_ZERO=y CONFIG_UBSAN_BOOL=y CONFIG_UBSAN_ENUM=y CONFIG_UBSAN_ALIGNMENT=y CONFIG_UBSAN_SANITIZE_ALL=y vmlinux 96 472 264 (+48 234 496, +99.99%) vmlinux.o 79 215 456 (+47 550 760, +150.17%)
In this case the kernel is twice as big because of disabled CONFIG_UBSAN_TRAP option, which enables (when the option is disabled) printing verbose error location information. Also, pointer alignment is enabled. Of course, such a big overhead is not acceptable in production.
However, without CONFIG_UBSAN_ALIGNMENT=y, the numbers are much more optimistic:
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y CONFIG_UBSAN=y # CONFIG_UBSAN_TRAP is not set CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_BOUNDS=y CONFIG_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_SHIFT=y CONFIG_UBSAN_DIV_ZERO=y CONFIG_UBSAN_BOOL=y CONFIG_UBSAN_ENUM=y # CONFIG_UBSAN_ALIGNMENT is not set CONFIG_UBSAN_SANITIZE_ALL=y vmlinux 50334920 (+2 097 152, +4.35%) vmlinux.o 34402408 (+2 737 712, +8.65%)
And the overhead is even smaller, when CONFIG_UBSAN_TRAP=y is enabled, which results in wordless oopses in the case of error:
CONFIG_UBSAN=y CONFIG_UBSAN_TRAP=y CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_BOUNDS=y CONFIG_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_SHIFT=y CONFIG_UBSAN_DIV_ZERO=y CONFIG_UBSAN_BOOL=y CONFIG_UBSAN_ENUM=y # CONFIG_UBSAN_ALIGNMENT is not set CONFIG_UBSAN_SANITIZE_ALL=y vmlinux 48 237 768 ( +0, +0.00%) vmlinux.o 32 004 392 (+339 696, +1.07%)
In this case the overhead is neglectable, compared to the overall kernel size. (And the final kernel image is even of the same size for some unknown reason.)
Since pointers alignment sanitizing for some reason is incompatible with CONFIG_UBSAN_TRAP=y, I can't test them together.
So, I suppose that the overhead for OP-TEE should also be small, as there is no detailed error logging. But, of course, it is better to be tested.
Hi Igor,
On Mon, Feb 5, 2024 at 5:45 PM Igor Zhbanov izh1979@gmail.com wrote:
Jérôme, thanks.
пн, 5 февр. 2024 г. в 17:22, Jérôme Forissier jerome.forissier@linaro.org:
I don't know, but the latest info about USBSAN is that it fails to build on the master branch so I can't even try it and check the memory usage :-/
I was curious, how UBSAN is affecting the Linux kernel, so, I've built openSUSE kernel on x86_64 with the default distribution configuration, then checked the sized of the stripped files vmlinux and vmlinux.o.
# CONFIG_UBSAN is not set: vmlinux 48 237 768 vmlinux.o 31 664 696
CONFIG_UBSAN=y # CONFIG_UBSAN_TRAP is not set CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_BOUNDS=y CONFIG_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_SHIFT=y CONFIG_UBSAN_DIV_ZERO=y CONFIG_UBSAN_BOOL=y CONFIG_UBSAN_ENUM=y CONFIG_UBSAN_ALIGNMENT=y CONFIG_UBSAN_SANITIZE_ALL=y vmlinux 96 472 264 (+48 234 496, +99.99%) vmlinux.o 79 215 456 (+47 550 760, +150.17%)
In this case the kernel is twice as big because of disabled CONFIG_UBSAN_TRAP option, which enables (when the option is disabled) printing verbose error location information. Also, pointer alignment is enabled. Of course, such a big overhead is not acceptable in production.
However, without CONFIG_UBSAN_ALIGNMENT=y, the numbers are much more optimistic:
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y CONFIG_UBSAN=y # CONFIG_UBSAN_TRAP is not set CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_BOUNDS=y CONFIG_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_SHIFT=y CONFIG_UBSAN_DIV_ZERO=y CONFIG_UBSAN_BOOL=y CONFIG_UBSAN_ENUM=y # CONFIG_UBSAN_ALIGNMENT is not set CONFIG_UBSAN_SANITIZE_ALL=y vmlinux 50334920 (+2 097 152, +4.35%) vmlinux.o 34402408 (+2 737 712, +8.65%)
And the overhead is even smaller, when CONFIG_UBSAN_TRAP=y is enabled, which results in wordless oopses in the case of error:
CONFIG_UBSAN=y CONFIG_UBSAN_TRAP=y CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_BOUNDS=y CONFIG_UBSAN_BOUNDS_STRICT=y CONFIG_UBSAN_SHIFT=y CONFIG_UBSAN_DIV_ZERO=y CONFIG_UBSAN_BOOL=y CONFIG_UBSAN_ENUM=y # CONFIG_UBSAN_ALIGNMENT is not set CONFIG_UBSAN_SANITIZE_ALL=y vmlinux 48 237 768 ( +0, +0.00%) vmlinux.o 32 004 392 (+339 696, +1.07%)
In this case the overhead is neglectable, compared to the overall kernel size. (And the final kernel image is even of the same size for some unknown reason.)
Since pointers alignment sanitizing for some reason is incompatible with CONFIG_UBSAN_TRAP=y, I can't test them together.
So, I suppose that the overhead for OP-TEE should also be small, as there is no detailed error logging. But, of course, it is better to be tested.
I guess that depends on what you mean by detailed, it prints file name, line, and column when logging.
Cheers, Jens
Hi Jens,
Fri, 9 Feb. 2024 г. в 14:33, Jens Wiklander jens.wiklander@linaro.org:
Hi Igor,
On Mon, Feb 5, 2024 at 5:45 PM Igor Zhbanov izh1979@gmail.com wrote:
So, I suppose that the overhead for OP-TEE should also be small, as there is no detailed error logging. But, of course, it is better to be tested.
I guess that depends on what you mean by detailed, it prints file name, line, and column when logging.
I hoped, it is possible to run UBSAN in minimalistic mode, where it would just print the current IP of violation instruction (and optionally reset the device). Then the overhead should be acceptable.
Thanks.
Hi Igor,
On Fri, Feb 9, 2024 at 1:49 PM Igor Zhbanov izh1979@gmail.com wrote:
Hi Jens,
Fri, 9 Feb. 2024 г. в 14:33, Jens Wiklander jens.wiklander@linaro.org:
Hi Igor,
On Mon, Feb 5, 2024 at 5:45 PM Igor Zhbanov izh1979@gmail.com wrote:
So, I suppose that the overhead for OP-TEE should also be small, as there is no detailed error logging. But, of course, it is better to be tested.
I guess that depends on what you mean by detailed, it prints file name, line, and column when logging.
I hoped, it is possible to run UBSAN in minimalistic mode, where it would just print the current IP of violation instruction (and optionally reset the device). Then the overhead should be acceptable.
Sure, that should be possible.
Cheers, Jens
op-tee@lists.trustedfirmware.org
-
Igor Zhbanov -
Jens Wiklander -
Jérôme Forissier