| Message ID | cover.1597425745.git.andreyknvl@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | kasan: add hardware tag-based mode for arm64 | expand |
> This patchset adds a new hardware tag-based mode to KASAN [1]. The new mode > is similar to the existing software tag-based KASAN, but relies on arm64 > Memory Tagging Extension (MTE) [2] to perform memory and pointer tagging > (instead of shadow memory and compiler instrumentation). What does one need to do to enable MTE in the kernel? I am trying to color some kernel module data, but when I call mte_get_mem_tag after calling mte_set_mem_tag_range, I get an invalid value. I have assured that mte_assign_mem_tag_range has been called in mte_set_mem_tag_range, so the initial sanity checks pass. Thanks.
On Mon, Sep 14, 2020 at 9:06 PM Derrick McKee <derrick.mckee@gmail.com> wrote: > > > This patchset adds a new hardware tag-based mode to KASAN [1]. The new mode > > is similar to the existing software tag-based KASAN, but relies on arm64 > > Memory Tagging Extension (MTE) [2] to perform memory and pointer tagging > > (instead of shadow memory and compiler instrumentation). > > What does one need to do to enable MTE in the kernel? I am trying to > color some kernel module data, but when I call mte_get_mem_tag after > calling mte_set_mem_tag_range, I get an invalid value. I have assured > that mte_assign_mem_tag_range has been called in mte_set_mem_tag_range, > so the initial sanity checks pass. Thanks. Hi Derrick, One needs to use the latest QEMU master and provide "-machine virt,mte=on -cpu max" arguments to it. I'll add this information into the cover letter for v2. Thanks!
On 9/14/20 4:04 PM, Andrey Konovalov wrote: > One needs to use the latest QEMU master and provide "-machine > virt,mte=on -cpu max" arguments to it. I'll add this information into > the cover letter for v2. I am using the latest QEMU as of Sep. 8, and starting the system with virt,mte=on, and I have also checked that the appropriate bits are set in sctlr_el1 and ID_AA64PFR1_EL1. Finally, when I print out the tag immediately before and after mte_assign_mem_tag_range I get the same result.
On 9/14/20 5:36 PM, Derrick McKee wrote: > On 9/14/20 4:04 PM, Andrey Konovalov wrote: >> One needs to use the latest QEMU master and provide "-machine >> virt,mte=on -cpu max" arguments to it. I'll add this information into >> the cover letter for v2. > > I am using the latest QEMU as of Sep. 8, and starting the system with > virt,mte=on, and I have also checked that the appropriate bits are set > in sctlr_el1 and ID_AA64PFR1_EL1. Finally, when I print out the tag > immediately before and after mte_assign_mem_tag_range I get the same > result. I should also mention that CONFIG_KASAN_HW_TAGS=n in my configuration, but I have added my own macro to enable my code and added it to the conditional macro in memory.h:224. I have also ensured that mte_init_tags is called from setup_arch. But still the result of the ldg instruction to get the address tag is always 0, despite the desired tag of 2. Perhaps I am missing some other needed setup or configuration?
On Tue, Sep 15, 2020 at 12:41 AM Derrick McKee <derrick.mckee@gmail.com> wrote: > > On 9/14/20 5:36 PM, Derrick McKee wrote: > > On 9/14/20 4:04 PM, Andrey Konovalov wrote: > >> One needs to use the latest QEMU master and provide "-machine > >> virt,mte=on -cpu max" arguments to it. I'll add this information into > >> the cover letter for v2. > > > > I am using the latest QEMU as of Sep. 8, and starting the system with > > virt,mte=on, and I have also checked that the appropriate bits are set > > in sctlr_el1 and ID_AA64PFR1_EL1. Finally, when I print out the tag > > immediately before and after mte_assign_mem_tag_range I get the same > > result. > > I should also mention that CONFIG_KASAN_HW_TAGS=n in my configuration, > but I have added my own macro to enable my code and added it to the > conditional macro in memory.h:224. I have also ensured that > mte_init_tags is called from setup_arch. But still the result of the > ldg instruction to get the address tag is always 0, despite the desired > tag of 2. Perhaps I am missing some other needed setup or configuration? Hm, this should work I guess. Could you try CONFIG_KASAN_HW_TAGS=y and check if that works?
On 9/14/20 6:50 PM, Andrey Konovalov wrote: > Hm, this should work I guess. > > Could you try CONFIG_KASAN_HW_TAGS=y and check if that works? This seems to work, as the tags change appropriately. So I guess I need to figure out what I am doing differently. Thanks for the help.
On 9/15/20 5:46 AM, Derrick McKee wrote: > This seems to work, as the tags change appropriately. So I guess I need > to figure out what I am doing differently. Thanks for the help. The problem was that the kernel uses the PAGE_KERNEL flag when allocating memory for modules, and the solution was to change that to PAGE_KERNEL_TAGGED. It might be worth adding this new flag to the documentation somewhere.
This patchset adds a new hardware tag-based mode to KASAN [1]. The new mode is similar to the existing software tag-based KASAN, but relies on arm64 Memory Tagging Extension (MTE) [2] to perform memory and pointer tagging (instead of shadow memory and compiler instrumentation). This patchset is available here: https://github.com/xairy/linux/tree/up-kasan-mte-v1 and has also been uploaded to the Linux kernel Gerrit instance: https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2700 This patchset is based on the v7 of the user MTE patches [3], along with some KASAN patches cherry-picked from the current mainline. This patchset consists of three parts: 1. Rework KASAN code to allow easier integration of the hardware tag-based mode. 2. Introduce core in-kernel MTE routines. 3. Combine the two parts together and introduce the new mode. For testing in QEMU hardware tag-based KASAN requires: 1. QEMU built from master [4] with these patches [5] on top. 2. GCC version 10. [1] https://www.kernel.org/doc/html/latest/dev-tools/kasan.html [2] https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety [3] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/mte [4] https://github.com/qemu/qemu [5] https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg02677.html ====== Overview The underlying ideas of the approach used by hardware tag-based KASAN are: 1. By relying on the Top Byte Ignore (TBI) arm64 CPU feature, pointer tags are stored in the top byte of each kernel pointer. 2. With the Memory Tagging Extension (MTE) arm64 CPU feature, memory tags for kernel memory allocations are stored in a dedicated memory not accessible via normal instuctions. 3. On each memory allocation, a random tag is generated, embedded it into the returned pointer, and the corresponding memory is tagged with the same tag value. 4. With MTE the CPU performs a check on each memory access to make sure that the pointer tag matches the memory tag. 5. On a tag mismatch the CPU generates a tag fault, and a KASAN report is printed. Same as other KASAN modes, hardware tag-based KASAN is intended as a debugging feature at this point. ====== Rationale There are two main reasons for this new hardware tag-based mode: 1. Previously implemented software tag-based KASAN is being successfully used on dogfood testing devices due to its low memory overhead (as initially planned). The new hardware mode keeps the same low memory overhead, and is expected to have significantly lower performance impact, due to the tag checks being performed by the hardware. Therefore the new mode can be used as a better alternative in dogfood testing for hardware that supports MTE. 2. The new mode lays the groundwork for the planned in-kernel MTE-based memory corruption mitigation to be used in production. ====== Technical details From the implementation perspective, hardware tag-based KASAN is almost identical to the software mode. The key difference is using MTE for assigning and checking tags. Compared to the software mode, the hardware mode uses 4 bits per tag, as dictated by MTE. Pointer tags are stored in bits [56:60), the top 4 bits have the normal value 0xF. Having less distict tags increases the probablity of false negatives (from ~1/256 to ~1/16) in certain cases. Only synchronous exceptions are set up and used by hardware tag-based KASAN. ====== Benchmarks Note: all measurements have been performed with software emulation of Memory Tagging Extension, performance numbers for hardware tag-based KASAN on the actual hardware are expected to be better. Boot time [1]: * 2.8 sec for clean kernel * 5.7 sec for hardware tag-based KASAN * 11.8 sec for software tag-based KASAN * 11.6 sec for generic KASAN Slab memory usage after boot [2]: * 7.0 kb for clean kernel * 9.7 kb for hardware tag-based KASAN * 9.7 kb for software tag-based KASAN * 41.3 kb for generic KASAN Measurements have been performed with: * defconfig-based configs * Manually built QEMU master with these patches on top [3] * QEMU arguments: -machine virt,mte=on -cpu max * CONFIG_KASAN_STACK_ENABLE disabled * CONFIG_KASAN_INLINE enabled * clang-10 as the compiler and gcc-10 as the assembler [1] Time before the ext4 driver is initialized. [2] Measured as `cat /proc/meminfo | grep Slab`. [3] https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg02677.html ====== Notes The cover letter for software tag-based KASAN patchset can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0116523cfffa62aeb5aa3b85ce7419f3dae0c1b8 Andrey Konovalov (29): kasan: KASAN_VMALLOC depends on KASAN_GENERIC kasan: group vmalloc code kasan: shadow declarations only for software modes kasan: rename (un)poison_shadow to (un)poison_memory kasan: rename KASAN_SHADOW_* to KASAN_GRANULE_* kasan: only build init.c for software modes kasan: split out shadow.c from common.c kasan: rename generic/tags_report.c files kasan: don't duplicate config dependencies kasan: hide invalid free check implementation kasan: decode stack frame only with KASAN_STACK_ENABLE kasan, arm64: only init shadow for software modes kasan, arm64: only use kasan_depth for software modes kasan: rename addr_has_shadow to addr_has_metadata kasan: rename print_shadow_for_address to print_memory_metadata kasan: kasan_non_canonical_hook only for software modes kasan: rename SHADOW layout macros to META kasan: separate metadata_fetch_row for each mode kasan: don't allow SW_TAGS with ARM64_MTE kasan: introduce CONFIG_KASAN_HW_TAGS kasan, arm64: align allocations for HW_TAGS kasan: define KASAN_GRANULE_SIZE for HW_TAGS kasan, x86, s390: update undef CONFIG_KASAN kasan, arm64: expand CONFIG_KASAN checks kasan, arm64: implement HW_TAGS runtime kasan, arm64: print report from tag fault handler kasan, slub: reset tags when accessing metadata kasan, arm64: enable CONFIG_KASAN_HW_TAGS kasan: add documentation for hardware tag-based mode Vincenzo Frascino (6): arm64: mte: Add in-kernel MTE helpers arm64: mte: Add in-kernel tag fault handler arm64: mte: Enable in-kernel MTE arm64: mte: Convert gcr_user into an exclude mask arm64: mte: Switch GCR_EL1 in kernel entry and exit kasan, arm64: Enable TBI EL1 Documentation/dev-tools/kasan.rst | 75 ++- arch/arm64/Kconfig | 3 +- arch/arm64/Makefile | 2 +- arch/arm64/include/asm/assembler.h | 2 +- arch/arm64/include/asm/cache.h | 3 + arch/arm64/include/asm/esr.h | 1 + arch/arm64/include/asm/kasan.h | 8 +- arch/arm64/include/asm/memory.h | 6 +- arch/arm64/include/asm/mte.h | 54 ++- arch/arm64/include/asm/mte_asm.h | 10 + arch/arm64/include/asm/processor.h | 2 +- arch/arm64/include/asm/string.h | 5 +- arch/arm64/kernel/asm-offsets.c | 3 + arch/arm64/kernel/cpufeature.c | 11 +- arch/arm64/kernel/entry.S | 28 ++ arch/arm64/kernel/head.S | 2 +- arch/arm64/kernel/image-vars.h | 2 +- arch/arm64/kernel/mte.c | 87 +++- arch/arm64/kernel/setup.c | 1 - arch/arm64/lib/mte.S | 41 ++ arch/arm64/mm/dump.c | 6 +- arch/arm64/mm/fault.c | 59 ++- arch/arm64/mm/kasan_init.c | 22 +- arch/arm64/mm/proc.S | 2 +- arch/s390/boot/string.c | 1 + arch/x86/boot/compressed/misc.h | 1 + include/linux/kasan-checks.h | 2 +- include/linux/kasan.h | 110 +++-- include/linux/mm.h | 2 +- include/linux/moduleloader.h | 3 +- include/linux/page-flags-layout.h | 2 +- include/linux/sched.h | 2 +- include/linux/string.h | 2 +- init/init_task.c | 2 +- kernel/fork.c | 4 +- lib/Kconfig.kasan | 60 ++- lib/test_kasan.c | 2 +- mm/kasan/Makefile | 21 +- mm/kasan/common.c | 554 ++-------------------- mm/kasan/generic.c | 33 +- mm/kasan/generic_report.c | 165 ------- mm/kasan/init.c | 10 +- mm/kasan/kasan.h | 45 +- mm/kasan/mte.c | 76 +++ mm/kasan/report.c | 254 ++-------- mm/kasan/report_generic.c | 331 +++++++++++++ mm/kasan/report_mte.c | 47 ++ mm/kasan/{tags_report.c => report_tags.c} | 7 +- mm/kasan/shadow.c | 509 ++++++++++++++++++++ mm/kasan/tags.c | 14 +- mm/page_poison.c | 2 +- mm/ptdump.c | 13 +- mm/slab_common.c | 2 +- mm/slub.c | 25 +- scripts/Makefile.lib | 2 + 55 files changed, 1653 insertions(+), 1085 deletions(-) create mode 100644 arch/arm64/include/asm/mte_asm.h delete mode 100644 mm/kasan/generic_report.c create mode 100644 mm/kasan/mte.c create mode 100644 mm/kasan/report_generic.c create mode 100644 mm/kasan/report_mte.c rename mm/kasan/{tags_report.c => report_tags.c} (94%) create mode 100644 mm/kasan/shadow.c