[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Nov 2019 15:52:52 +0300
From: Andrey Ryabinin <aryabinin@...tuozzo.com>
To: Kees Cook <keescook@...omium.org>
Cc: Elena Petrova <lenaptr@...gle.com>,
Alexander Potapenko <glider@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Dan Carpenter <dan.carpenter@...cle.com>,
"Gustavo A. R. Silva" <gustavo@...eddedor.com>, Arnd Bergmann
<arnd@...db.de>, Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Andrew Morton <akpm@...ux-foundation.org>, kasan-dev@...glegroups.com,
linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 1/3] ubsan: Add trap instrumentation option
On 11/20/19 4:06 AM, Kees Cook wrote:
> +config UBSAN_TRAP
> + bool "On Sanitizer warnings, stop the offending kernel thread"
That description seems inaccurate and confusing. It's not about kernel threads.
UBSAN may trigger in any context - kernel thread/user process/interrupts...
Probably most of the kernel code runs in the context of user process, so "stop the offending kernel thread"
doesn't sound right.
> + depends on UBSAN
> + depends on $(cc-option, -fsanitize-undefined-trap-on-error)
> + help
> + Building kernels with Sanitizer features enabled tends to grow
> + the kernel size by over 5%, due to adding all the debugging
> + text on failure paths. To avoid this, Sanitizer instrumentation
> + can just issue a trap. This reduces the kernel size overhead but
> + turns all warnings into full thread-killing exceptions.
I think we should mention that enabling this option also has a potential to
turn some otherwise harmless bugs into more severe problems like lockups, kernel panic etc..
So the people who enable this would better understand what they signing up for.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
