Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit a025b6c9 authored by Ivaylo Georgiev's avatar Ivaylo Georgiev
Browse files

Merge android-4.19.78 (75337a6f) into msm-4.19 



* refs/heads/tmp-75337a6f:
  ANDROID: usb: gadget: Fix dependency for f_accessory
  ANDROID: properly export new symbols with _GPL tag
  UPSTREAM: mm/kasan: fix false positive invalid-free reports with CONFIG_KASAN_SW_TAGS=y
  UPSTREAM: kasan: initialize tag to 0xff in __kasan_kmalloc
  UPSTREAM: x86/boot: Provide KASAN compatible aliases for string routines
  UPSTREAM: x86/uaccess, kasan: Fix KASAN vs SMAP
  BACKPORT: x86/uaccess: Introduce user_access_{save,restore}()
  UPSTREAM: kasan: fix variable 'tag' set but not used warning
  UPSTREAM: Revert "x86_64: Increase stack size for KASAN_EXTRA"
  UPSTREAM: kasan: fix coccinelle warnings in kasan_p*_table
  UPSTREAM: kasan: fix kasan_check_read/write definitions
  BACKPORT: kasan: remove use after scope bugs detection.
  BACKPORT: kasan: turn off asan-stack for clang-8 and earlier
  UPSTREAM: slub: fix a crash with SLUB_DEBUG + KASAN_SW_TAGS
  UPSTREAM: kasan, slab: remove redundant kasan_slab_alloc hooks
  UPSTREAM: kasan, slab: make freelist stored without tags
  UPSTREAM: kasan, slab: fix conflicts with CONFIG_HARDENED_USERCOPY
  UPSTREAM: kasan: prevent tracing of tags.c
  UPSTREAM: kasan: fix random seed generation for tag-based mode
  UPSTREAM: slub: fix SLAB_CONSISTENCY_CHECKS + KASAN_SW_TAGS
  UPSTREAM: kasan, slub: fix more conflicts with CONFIG_SLAB_FREELIST_HARDENED
  UPSTREAM: kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENED
  UPSTREAM: kasan, slub: move kasan_poison_slab hook before page_address
  UPSTREAM: kasan, kmemleak: pass tagged pointers to kmemleak
  UPSTREAM: kasan: fix assigning tags twice
  UPSTREAM: kasan: mark file common so ftrace doesn't trace it
  UPSTREAM: kasan, arm64: remove redundant ARCH_SLAB_MINALIGN define
  UPSTREAM: kasan: fix krealloc handling for tag-based mode
  UPSTREAM: kasan: make tag based mode work with CONFIG_HARDENED_USERCOPY
  UPSTREAM: kasan, arm64: use ARCH_SLAB_MINALIGN instead of manual aligning
  BACKPORT: mm/memblock.c: skip kmemleak for kasan_init()
  UPSTREAM: kasan: add SPDX-License-Identifier mark to source files
  UPSTREAM: kasan: update documentation
  UPSTREAM: kasan, arm64: select HAVE_ARCH_KASAN_SW_TAGS
  UPSTREAM: kasan: add __must_check annotations to kasan hooks
  UPSTREAM: kasan, mm, arm64: tag non slab memory allocated via pagealloc
  UPSTREAM: kasan, arm64: add brk handler for inline instrumentation
  UPSTREAM: kasan: add hooks implementation for tag-based mode
  UPSTREAM: mm: move obj_to_index to include/linux/slab_def.h
  UPSTREAM: kasan: add bug reporting routines for tag-based mode
  UPSTREAM: kasan: split out generic_report.c from report.c
  UPSTREAM: kasan, mm: perform untagged pointers comparison in krealloc
  BACKPORT: kasan, arm64: enable top byte ignore for the kernel
  BACKPORT: kasan, arm64: fix up fault handling logic
  UPSTREAM: kasan: preassign tags to objects with ctors or SLAB_TYPESAFE_BY_RCU
  UPSTREAM: kasan, arm64: untag address in _virt_addr_is_linear
  UPSTREAM: kasan: add tag related helper functions
  UPSTREAM: arm64: move untagged_addr macro from uaccess.h to memory.h
  BACKPORT: kasan: initialize shadow to 0xff for tag-based mode
  BACKPORT: kasan: rename kasan_zero_page to kasan_early_shadow_page
  UPSTREAM: kasan, arm64: adjust shadow size for tag-based mode
  BACKPORT: kasan: add CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS
  UPSTREAM: kasan: rename source files to reflect the new naming scheme
  UPSTREAM: kasan: move common generic and tag-based code to common.c
  UPSTREAM: kasan, slub: handle pointer tags in early_kmem_cache_node_alloc
  UPSTREAM: kasan, mm: change hooks signatures
  UPSTREAM: arm64: add EXPORT_SYMBOL_NOKASAN()
  BACKPORT: compiler: remove __no_sanitize_address_or_inline again
  UPSTREAM: mm/kasan/quarantine.c: make quarantine_lock a raw_spinlock_t
  UPSTREAM: lib/test_kasan.c: add tests for several string/memory API functions
  UPSTREAM: arm64: lib: use C string functions with KASAN enabled
  UPSTREAM: compiler: introduce __no_sanitize_address_or_inline
  UPSTREAM: arm64: Fix typo in a comment in arch/arm64/mm/kasan_init.c
  ANDROID: enable CONFIG_ION_SYSTEM_HEAP for GKI
  Update ABI definition after libabigail upgrade
  ANDROID: update abi due to 4.19.75 changes
  ANDROID: Remove CONFIG_USELIB from x86 gki config
  ANDROID: net: enable wireless core features with GKI_LEGACY_WEXT_ALLCONFIG
  ANDROID: arm64: bpf: implement arch_bpf_jit_check_func
  ANDROID: bpf: validate bpf_func when BPF_JIT is enabled with CFI
  UPSTREAM: kcm: use BPF_PROG_RUN
  ANDROID: gki_defconfig: CONFIG_MMC_BLOCK=m
  UPSTREAM: psi: get poll_work to run when calling poll syscall next time
  UPSTREAM: sched/psi: Do not require setsched permission from the trigger creator
  UPSTREAM: sched/psi: Reduce psimon FIFO priority
  ANDROID: gki_defconfig: Enable HiSilicon SoCs
  UPSTREAM: PCI: kirin: Fix section mismatch warning
  ANDROID: gki_defconfig: Enable SERIAL_DEV_BUS
  ANDROID: gki_defconfig: Add GKI_HACKS_to_FIX config
  ANDROID: init: GKI: enable hidden configs for GPIO
  ANDROID: init: GKI: enable hidden configs for SND_SOC
  ANDROID: init: GKI: enable hidden configs for regmap
  ANDROID: init: GKI: enable hidden configs for DRM
  ANDROID: init: GKI: add GKI_HACKS_TO_FIX
  ABI: Update ABI after fscrypto merge
  ANDROID: gki_defconfig: enable CONFIG_UIO
  UPSTREAM: ALSA: pcm: add support for 352.8KHz and 384KHz sample rate
  ANDROID: Log which device failed to suspend in dpm_suspend_start()
  UPSTREAM: arm64: Add support for relocating the kernel with RELR relocations
  ANDROID: update ABI after CONFIG_MMC=m
  CONFIG_MMC=m
  ABI: Update ABI for LTS, 8250 changes
  ANDROID: Removed extraneous serial 8250 configs
  Adding SERIAL_OF_PLATFORM module to gki
  fscrypt: document testing with xfstests
  fscrypt: remove selection of CONFIG_CRYPTO_SHA256
  fscrypt: remove unnecessary includes of ratelimit.h
  fscrypt: don't set policy for a dead directory
  fscrypt: decrypt only the needed blocks in __fscrypt_decrypt_bio()
  fscrypt: support decrypting multiple filesystem blocks per page
  fscrypt: introduce fscrypt_decrypt_block_inplace()
  fscrypt: handle blocksize < PAGE_SIZE in fscrypt_zeroout_range()
  fscrypt: support encrypting multiple filesystem blocks per page
  fscrypt: introduce fscrypt_encrypt_block_inplace()
  fscrypt: clean up some BUG_ON()s in block encryption/decryption
  fscrypt: rename fscrypt_do_page_crypto() to fscrypt_crypt_block()
  fscrypt: remove the "write" part of struct fscrypt_ctx
  fscrypt: simplify bounce page handling

Conflicts:
	arch/Kconfig
	fs/crypto/bio.c
	fs/ext4/page-io.c
	fs/f2fs/data.c
	fs/f2fs/f2fs.h
	fs/f2fs/super.c
	include/linux/fscrypt.h
	sound/core/pcm_native.c

Change-Id: Ia94ba2ae85e04be9f69115e2da2d69d0dc76545f
Signed-off-by: default avatarIvaylo Georgiev <irgeorgiev@codeaurora.org>
parents 44bb576a 75337a6f

Documentation/dev-tools/kasan.rst

+138 −94
Original line number Diff line number Diff line
@@ -4,15 +4,25 @@ The Kernel Address Sanitizer (KASAN) 
Overview

--------



KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides

a fast and comprehensive solution for finding use-after-free and out-of-bounds

bugs.

KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to

find out-of-bound and use-after-free bugs. KASAN has two modes: generic KASAN

(similar to userspace ASan) and software tag-based KASAN (similar to userspace

HWASan).



KASAN uses compile-time instrumentation for checking every memory access,

therefore you will need a GCC version 4.9.2 or later. GCC 5.0 or later is

required for detection of out-of-bounds accesses to stack or global variables.

KASAN uses compile-time instrumentation to insert validity checks before every

memory access, and therefore requires a compiler version that supports that.



Currently KASAN is supported only for the x86_64 and arm64 architectures.

Generic KASAN is supported in both GCC and Clang. With GCC it requires version

4.9.2 or later for basic support and version 5.0 or later for detection of

out-of-bounds accesses for stack and global variables and for inline

instrumentation mode (see the Usage section). With Clang it requires version

7.0.0 or later and it doesn't support detection of out-of-bounds accesses for

global variables yet.



Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later.



Currently generic KASAN is supported for the x86_64, arm64, xtensa and s390

architectures, and tag-based KASAN is supported only for arm64.



Usage

-----
@@ -21,12 +31,14 @@ To enable KASAN configure kernel with:: 


	  CONFIG_KASAN = y



and choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline and

inline are compiler instrumentation types. The former produces smaller binary

the latter is 1.1 - 2 times faster. Inline instrumentation requires a GCC

version 5.0 or later.

and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN) and

CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN).



You also need to choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE.

Outline and inline are compiler instrumentation types. The former produces

smaller binary while the latter is 1.1 - 2 times faster.



KASAN works with both SLUB and SLAB memory allocators.

Both KASAN modes work with both SLUB and SLAB memory allocators.

For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.



To disable instrumentation for specific files or directories, add a line
@@ -43,85 +55,85 @@ similar to the following to the respective kernel Makefile: 
Error reports

~~~~~~~~~~~~~



A typical out of bounds access report looks like this::

A typical out-of-bounds access generic KASAN report looks like this::



    ==================================================================

    BUG: AddressSanitizer: out of bounds access in kmalloc_oob_right+0x65/0x75 [test_kasan] at addr ffff8800693bc5d3

    Write of size 1 by task modprobe/1689

    =============================================================================

    BUG kmalloc-128 (Not tainted): kasan error

    -----------------------------------------------------------------------------



    Disabling lock debugging due to kernel taint

    INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 pid=1689

     __slab_alloc+0x4b4/0x4f0

     kmem_cache_alloc_trace+0x10b/0x190

     kmalloc_oob_right+0x3d/0x75 [test_kasan]

     init_module+0x9/0x47 [test_kasan]

     do_one_initcall+0x99/0x200

     load_module+0x2cb3/0x3b20

     SyS_finit_module+0x76/0x80

     system_call_fastpath+0x12/0x17

    INFO: Slab 0xffffea0001a4ef00 objects=17 used=7 fp=0xffff8800693bd728 flags=0x100000000004080

    INFO: Object 0xffff8800693bc558 @offset=1368 fp=0xffff8800693bc720



    Bytes b4 ffff8800693bc548: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  ........ZZZZZZZZ

    Object ffff8800693bc558: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc568: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc5a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc5b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk

    Object ffff8800693bc5c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkkkkkkkkkkkk.

    Redzone ffff8800693bc5d8: cc cc cc cc cc cc cc cc                          ........

    Padding ffff8800693bc718: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ

    CPU: 0 PID: 1689 Comm: modprobe Tainted: G    B          3.18.0-rc1-mm1+ #98

    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014

     ffff8800693bc000 0000000000000000 ffff8800693bc558 ffff88006923bb78

     ffffffff81cc68ae 00000000000000f3 ffff88006d407600 ffff88006923bba8

     ffffffff811fd848 ffff88006d407600 ffffea0001a4ef00 ffff8800693bc558

    BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan]

    Write of size 1 at addr ffff8801f44ec37b by task insmod/2760



    CPU: 1 PID: 2760 Comm: insmod Not tainted 4.19.0-rc3+ #698

    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014

    Call Trace:

     [<ffffffff81cc68ae>] dump_stack+0x46/0x58

     [<ffffffff811fd848>] print_trailer+0xf8/0x160

     [<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan]

     [<ffffffff811ff0f5>] object_err+0x35/0x40

     [<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan]

     [<ffffffff8120b9fa>] kasan_report_error+0x38a/0x3f0

     [<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40

     [<ffffffff8120b344>] ? kasan_unpoison_shadow+0x14/0x40

     [<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40

     [<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan]

     [<ffffffff8120a995>] __asan_store1+0x75/0xb0

     [<ffffffffa0002601>] ? kmem_cache_oob+0x1d/0xc3 [test_kasan]

     [<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan]

     [<ffffffffa0002065>] kmalloc_oob_right+0x65/0x75 [test_kasan]

     [<ffffffffa00026b0>] init_module+0x9/0x47 [test_kasan]

     [<ffffffff810002d9>] do_one_initcall+0x99/0x200

     [<ffffffff811e4e5c>] ? __vunmap+0xec/0x160

     [<ffffffff81114f63>] load_module+0x2cb3/0x3b20

     [<ffffffff8110fd70>] ? m_show+0x240/0x240

     [<ffffffff81115f06>] SyS_finit_module+0x76/0x80

     [<ffffffff81cd3129>] system_call_fastpath+0x12/0x17

     dump_stack+0x94/0xd8

     print_address_description+0x73/0x280

     kasan_report+0x144/0x187

     __asan_report_store1_noabort+0x17/0x20

     kmalloc_oob_right+0xa8/0xbc [test_kasan]

     kmalloc_tests_init+0x16/0x700 [test_kasan]

     do_one_initcall+0xa5/0x3ae

     do_init_module+0x1b6/0x547

     load_module+0x75df/0x8070

     __do_sys_init_module+0x1c6/0x200

     __x64_sys_init_module+0x6e/0xb0

     do_syscall_64+0x9f/0x2c0

     entry_SYSCALL_64_after_hwframe+0x44/0xa9

    RIP: 0033:0x7f96443109da

    RSP: 002b:00007ffcf0b51b08 EFLAGS: 00000202 ORIG_RAX: 00000000000000af

    RAX: ffffffffffffffda RBX: 000055dc3ee521a0 RCX: 00007f96443109da

    RDX: 00007f96445cff88 RSI: 0000000000057a50 RDI: 00007f9644992000

    RBP: 000055dc3ee510b0 R08: 0000000000000003 R09: 0000000000000000

    R10: 00007f964430cd0a R11: 0000000000000202 R12: 00007f96445cff88

    R13: 000055dc3ee51090 R14: 0000000000000000 R15: 0000000000000000



    Allocated by task 2760:

     save_stack+0x43/0xd0

     kasan_kmalloc+0xa7/0xd0

     kmem_cache_alloc_trace+0xe1/0x1b0

     kmalloc_oob_right+0x56/0xbc [test_kasan]

     kmalloc_tests_init+0x16/0x700 [test_kasan]

     do_one_initcall+0xa5/0x3ae

     do_init_module+0x1b6/0x547

     load_module+0x75df/0x8070

     __do_sys_init_module+0x1c6/0x200

     __x64_sys_init_module+0x6e/0xb0

     do_syscall_64+0x9f/0x2c0

     entry_SYSCALL_64_after_hwframe+0x44/0xa9



    Freed by task 815:

     save_stack+0x43/0xd0

     __kasan_slab_free+0x135/0x190

     kasan_slab_free+0xe/0x10

     kfree+0x93/0x1a0

     umh_complete+0x6a/0xa0

     call_usermodehelper_exec_async+0x4c3/0x640

     ret_from_fork+0x35/0x40



    The buggy address belongs to the object at ffff8801f44ec300

     which belongs to the cache kmalloc-128 of size 128

    The buggy address is located 123 bytes inside of

     128-byte region [ffff8801f44ec300, ffff8801f44ec380)

    The buggy address belongs to the page:

    page:ffffea0007d13b00 count:1 mapcount:0 mapping:ffff8801f7001640 index:0x0

    flags: 0x200000000000100(slab)

    raw: 0200000000000100 ffffea0007d11dc0 0000001a0000001a ffff8801f7001640

    raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000

    page dumped because: kasan: bad access detected



    Memory state around the buggy address:

     ffff8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc380: fc fc 00 00 00 00 00 00 00 00 00 00 00 00 00 fc

     ffff8800693bc400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc500: fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00

    >ffff8800693bc580: 00 00 00 00 00 00 00 00 00 00 03 fc fc fc fc fc

     ffff8801f44ec200: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb

     ffff8801f44ec280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc

    >ffff8801f44ec300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03

                                                                    ^

     ffff8800693bc600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

     ffff8800693bc700: fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb fb

     ffff8800693bc780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

     ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

     ffff8801f44ec380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb

     ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc

    ==================================================================



The header of the report discribe what kind of bug happened and what kind of

access caused it. It's followed by the description of the accessed slub object

(see 'SLUB Debug output' section in Documentation/vm/slub.rst for details) and

the description of the accessed memory page.

The header of the report provides a short summary of what kind of bug happened

and what kind of access caused it. It's followed by a stack trace of the bad

access, a stack trace of where the accessed memory was allocated (in case bad

access happens on a slab object), and a stack trace of where the object was

freed (in case of a use-after-free bug report). Next comes a description of

the accessed slab object and information about the accessed memory page.



In the last section the report shows memory state around the accessed address.

Reading this part requires some understanding of how KASAN works.
@@ -138,18 +150,24 @@ inaccessible memory like redzones or freed memory (see mm/kasan/kasan.h). 
In the report above the arrows point to the shadow byte 03, which means that

the accessed address is partially accessible.



For tag-based KASAN this last report section shows the memory tags around the

accessed address (see Implementation details section).





Implementation details

----------------------



Generic KASAN

~~~~~~~~~~~~~



From a high level, our approach to memory error detection is similar to that

of kmemcheck: use shadow memory to record whether each byte of memory is safe

to access, and use compile-time instrumentation to check shadow memory on each

memory access.

to access, and use compile-time instrumentation to insert checks of shadow

memory on each memory access.



AddressSanitizer dedicates 1/8 of kernel memory to its shadow memory

(e.g. 16TB to cover 128TB on x86_64) and uses direct mapping with a scale and

offset to translate a memory address to its corresponding shadow address.

Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB

to cover 128TB on x86_64) and uses direct mapping with a scale and offset to

translate a memory address to its corresponding shadow address.



Here is the function which translates an address to its corresponding shadow

address::
@@ -162,12 +180,38 @@ address:: 


where ``KASAN_SHADOW_SCALE_SHIFT = 3``.



Compile-time instrumentation used for checking memory accesses. Compiler inserts

function calls (__asan_load*(addr), __asan_store*(addr)) before each memory

access of size 1, 2, 4, 8 or 16. These functions check whether memory access is

valid or not by checking corresponding shadow memory.

Compile-time instrumentation is used to insert memory access checks. Compiler

inserts function calls (__asan_load*(addr), __asan_store*(addr)) before each

memory access of size 1, 2, 4, 8 or 16. These functions check whether memory

access is valid or not by checking corresponding shadow memory.



GCC 5.0 has possibility to perform inline instrumentation. Instead of making

function calls GCC directly inserts the code to check the shadow memory.

This option significantly enlarges kernel but it gives x1.1-x2 performance

boost over outline instrumented kernel.



Software tag-based KASAN

~~~~~~~~~~~~~~~~~~~~~~~~



Tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64 CPUs to

store a pointer tag in the top byte of kernel pointers. Like generic KASAN it

uses shadow memory to store memory tags associated with each 16-byte memory

cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).



On each memory allocation tag-based KASAN generates a random tag, tags the

allocated memory with this tag, and embeds this tag into the returned pointer.

Software tag-based KASAN uses compile-time instrumentation to insert checks

before each memory access. These checks make sure that tag of the memory that

is being accessed is equal to tag of the pointer that is used to access this

memory. In case of a tag mismatch tag-based KASAN prints a bug report.



Software tag-based KASAN also has two instrumentation modes (outline, that

emits callbacks to check memory accesses; and inline, that performs the shadow

memory checks inline). With outline instrumentation mode, a bug report is

simply printed from the function that performs the access check. With inline

instrumentation a brk instruction is emitted by the compiler, and a dedicated

brk handler is used to print bug reports.



A potential expansion of this mode is a hardware tag-based mode, which would

use hardware memory tagging support instead of compiler instrumentation and

manual shadow memory manipulation.

Documentation/filesystems/fscrypt.rst

+42 −1
Original line number Diff line number Diff line
@@ -191,7 +191,9 @@ Currently, the following pairs of encryption modes are supported: 
If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair.



AES-128-CBC was added only for low-powered embedded devices with

crypto accelerators such as CAAM or CESA that do not support XTS.

crypto accelerators such as CAAM or CESA that do not support XTS.  To

use AES-128-CBC, CONFIG_CRYPTO_SHA256 (or another SHA-256

implementation) must be enabled so that ESSIV can be used.



Adiantum is a (primarily) stream cipher-based mode that is fast even

on CPUs without dedicated crypto instructions.  It's also a true
@@ -647,3 +649,42 @@ Note that the precise way that filenames are presented to userspace 
without the key is subject to change in the future.  It is only meant

as a way to temporarily present valid filenames so that commands like

``rm -r`` work as expected on encrypted directories.



Tests

=====



To test fscrypt, use xfstests, which is Linux's de facto standard

filesystem test suite.  First, run all the tests in the "encrypt"

group on the relevant filesystem(s).  For example, to test ext4 and

f2fs encryption using `kvm-xfstests

<https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md>`_::



    kvm-xfstests -c ext4,f2fs -g encrypt



UBIFS encryption can also be tested this way, but it should be done in

a separate command, and it takes some time for kvm-xfstests to set up

emulated UBI volumes::



    kvm-xfstests -c ubifs -g encrypt



No tests should fail.  However, tests that use non-default encryption

modes (e.g. generic/549 and generic/550) will be skipped if the needed

algorithms were not built into the kernel's crypto API.  Also, tests

that access the raw block device (e.g. generic/399, generic/548,

generic/549, generic/550) will be skipped on UBIFS.



Besides running the "encrypt" group tests, for ext4 and f2fs it's also

possible to run most xfstests with the "test_dummy_encryption" mount

option.  This option causes all new files to be automatically

encrypted with a dummy key, without having to make any API calls.

This tests the encrypted I/O paths more thoroughly.  To do this with

kvm-xfstests, use the "encrypt" filesystem configuration::



    kvm-xfstests -c ext4/encrypt,f2fs/encrypt -g auto



Because this runs many more tests than "-g encrypt" does, it takes

much longer to run; so also consider using `gce-xfstests

<https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md>`_

instead of kvm-xfstests::



    gce-xfstests -c ext4/encrypt,f2fs/encrypt -g auto

Makefile

+4 −0
Original line number Diff line number Diff line
@@ -954,6 +954,10 @@ ifeq ($(CONFIG_STRIP_ASM_SYMS),y) 
LDFLAGS_vmlinux	+= $(call ld-option, -X,)

endif



ifeq ($(CONFIG_RELR),y)

LDFLAGS_vmlinux	+= --pack-dyn-relocs=relr

endif



# insure the checker run with the right endianness

CHECKFLAGS += $(if $(CONFIG_CPU_BIG_ENDIAN),-mbig-endian,-mlittle-endian)

abi_gki_aarch64.xml

+103846 −113491

File changed.

Preview size limit exceeded, changes collapsed.

arch/Kconfig

+14 −0
Original line number Diff line number Diff line
@@ -939,6 +939,20 @@ config PANIC_ON_REFCOUNT_ERROR 
	  or potential memory-leaks) with an object associated with that

	  reference counter.



# Select if the architecture has support for applying RELR relocations.

config ARCH_HAS_RELR

	bool



config RELR

	bool "Use RELR relocation packing"

	depends on ARCH_HAS_RELR && TOOLS_SUPPORT_RELR

	default y

	help

	  Store the kernel's dynamic relocations in the RELR relocation packing

	  format. Requires a compatible linker (LLD supports this feature), as

	  well as compatible NM and OBJCOPY utilities (llvm-nm and llvm-objcopy

	  are compatible).



source "kernel/gcov/Kconfig"



source "scripts/gcc-plugins/Kconfig"