| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 27 Nov 2018 17:12:45 +0100
From: Andrey Konovalov <andreyknvl@...gle.com>
To: Mark Rutland <mark.rutland@....com>
Cc: Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Christoph Lameter <cl@...ux.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Marc Zyngier <marc.zyngier@....com>,
Dave Martin <dave.martin@....com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Ingo Molnar <mingo@...nel.org>,
Paul Lawrence <paullawrence@...gle.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Arnd Bergmann <arnd@...db.de>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kate Stewart <kstewart@...uxfoundation.org>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
kasan-dev@...glegroups.com,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-sparse@...r.kernel.org,
Linux Memory Management List <linux-mm@...ck.org>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Kostya Serebryany <kcc@...gle.com>,
Evgeniy Stepanov <eugenis@...gle.com>,
Lee Smith <Lee.Smith@....com>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
Jacob Bramley <Jacob.Bramley@....com>,
Ruben Ayrapetyan <Ruben.Ayrapetyan@....com>,
Jann Horn <jannh@...gle.com>,
Mark Brand <markbrand@...gle.com>,
Chintan Pandya <cpandya@...eaurora.org>,
Vishwath Mohan <vishwath@...gle.com>
Subject: Re: [PATCH v11 05/24] kasan: add CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS
On Fri, Nov 23, 2018 at 6:43 PM, Mark Rutland <mark.rutland@....com> wrote:
> On Mon, Nov 19, 2018 at 06:26:21PM +0100, Andrey Konovalov wrote:
>> This commit splits the current CONFIG_KASAN config option into two:
>> 1. CONFIG_KASAN_GENERIC, that enables the generic KASAN mode (the one
>> that exists now);
>> 2. CONFIG_KASAN_SW_TAGS, that enables the software tag-based KASAN mode.
>>
>> The name CONFIG_KASAN_SW_TAGS is chosen as in the future we will have
>> another hardware tag-based KASAN mode, that will rely on hardware memory
>> tagging support in arm64.
>>
>> With CONFIG_KASAN_SW_TAGS enabled, compiler options are changed to
>> instrument kernel files with -fsantize=kernel-hwaddress (except the ones
>> for which KASAN_SANITIZE := n is set).
>>
>> Both CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS support both
>> CONFIG_KASAN_INLINE and CONFIG_KASAN_OUTLINE instrumentation modes.
>>
>> This commit also adds empty placeholder (for now) implementation of
>> tag-based KASAN specific hooks inserted by the compiler and adjusts
>> common hooks implementation to compile correctly with each of the
>> config options.
>>
>> Reviewed-by: Andrey Ryabinin <aryabinin@...tuozzo.com>
>> Reviewed-by: Dmitry Vyukov <dvyukov@...gle.com>
>> Signed-off-by: Andrey Konovalov <andreyknvl@...gle.com>
>> ---
>> arch/arm64/Kconfig | 1 +
>> include/linux/compiler-clang.h | 5 +-
>> include/linux/compiler-gcc.h | 6 ++
>> include/linux/compiler_attributes.h | 13 ----
>> include/linux/kasan.h | 16 +++--
>> lib/Kconfig.kasan | 96 +++++++++++++++++++++++------
>> mm/kasan/Makefile | 6 +-
>> mm/kasan/generic.c | 2 +-
>> mm/kasan/kasan.h | 3 +-
>> mm/kasan/tags.c | 75 ++++++++++++++++++++++
>> mm/slub.c | 2 +-
>> scripts/Makefile.kasan | 53 +++++++++-------
>> 12 files changed, 216 insertions(+), 62 deletions(-)
>> create mode 100644 mm/kasan/tags.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 787d7850e064..8b331dcfb48e 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -111,6 +111,7 @@ config ARM64
>> select HAVE_ARCH_JUMP_LABEL
>> select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
>> + select HAVE_ARCH_KASAN_SW_TAGS if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
>
>> --- a/lib/Kconfig.kasan
>> +++ b/lib/Kconfig.kasan
>> @@ -1,35 +1,95 @@
>> +# This config refers to the generic KASAN mode.
>> config HAVE_ARCH_KASAN
>> bool
>>
>> +config HAVE_ARCH_KASAN_SW_TAGS
>> + bool
>> +
>> +config CC_HAS_KASAN_GENERIC
>> + def_bool $(cc-option, -fsanitize=kernel-address)
>> +
>> +config CC_HAS_KASAN_SW_TAGS
>> + def_bool $(cc-option, -fsanitize=kernel-hwaddress)
>
>> +if HAVE_ARCH_KASAN_SW_TAGS
>> +
>> +config KASAN_SW_TAGS
>> + bool "Software tag-based mode"
>> + depends on CC_HAS_KASAN_SW_TAGS
>> + depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
>> + select SLUB_DEBUG if SLUB
>> + select CONSTRUCTORS
>> + select STACKDEPOT
>> + help
>> + Enables software tag-based KASAN mode.
>> + This mode requires Top Byte Ignore support by the CPU and therefore
>> + is only supported for arm64.
>> + This mode requires Clang version 7.0.0 or later.
>> + This mode consumes about 1/16th of available memory at kernel start
>> + and introduces an overhead of ~20% for the rest of the allocations.
>> + This mode may potentially introduce problems relating to pointer
>> + casting and comparison, as it embeds tags into the top byte of each
>> + pointer.
>> + For better error detection enable CONFIG_STACKTRACE.
>> + Currently CONFIG_KASAN_SW_TAGS doesn't work with CONFIG_DEBUG_SLAB
>> + (the resulting kernel does not boot).
>> +
>> +endif
>
> IIUC as of this patch a user can select KASAN_SW_TAGS...
>
>> +ifdef CONFIG_KASAN_SW_TAGS
>> +
>> +ifdef CONFIG_KASAN_INLINE
>> + instrumentation_flags := -mllvm -hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET)
>> +else
>> + instrumentation_flags := -mllvm -hwasan-instrument-with-calls=1
>> +endif
>> +
>> +CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
>> + -mllvm -hwasan-instrument-stack=0 \
>> + $(instrumentation_flags)
>> +
>> +endif # CONFIG_KASAN_SW_TAGS
>
> ... and therefore we start using the compiler option, even though we
> haven't introduced all of the necessary infrastructure yet.
>
> That doesn't sound right to me. At the very least, that breaks
> randconfig builds.
>
> What we can do, in-order, is:
>
> 1) introduce the core refactoring, dependent on HAVE_ARCH_KASAN_SW_TAGS
> 2) instroduce the new infrastructure and arch code
> 3) select HAVE_ARCH_KASAN_SW_TAGS
>
> ... such that at (3), all KASAN configurations are known to work.
>
> Thanks,
> Mark.
Will do in v12, thanks!
Powered by blists - more mailing lists