linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	kasan-dev@googlegroups.com,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Marco Elver <elver@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Elena Petrova <lenaptr@google.com>,
	Branislav Rankov <Branislav.Rankov@arm.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 24/39] arm64: mte: Add in-kernel MTE helpers
Date: Fri, 25 Sep 2020 12:28:24 +0100	[thread overview]
Message-ID: <e41f2af1-f208-cc99-64f9-2311ad7d50bf@arm.com> (raw)
In-Reply-To: <20200925101558.GB4846@gaia>

On 9/25/20 11:15 AM, Catalin Marinas wrote:
> On Fri, Sep 25, 2020 at 12:50:31AM +0200, Andrey Konovalov wrote:
>> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
>> index 035003acfa87..bc0dc66a6a27 100644
>> --- a/arch/arm64/include/asm/esr.h
>> +++ b/arch/arm64/include/asm/esr.h
>> @@ -103,6 +103,7 @@
>>  #define ESR_ELx_FSC		(0x3F)
>>  #define ESR_ELx_FSC_TYPE	(0x3C)
>>  #define ESR_ELx_FSC_EXTABT	(0x10)
>> +#define ESR_ELx_FSC_MTE		(0x11)
>>  #define ESR_ELx_FSC_SERROR	(0x11)
>>  #define ESR_ELx_FSC_ACCESS	(0x08)
>>  #define ESR_ELx_FSC_FAULT	(0x04)
>> diff --git a/arch/arm64/include/asm/mte-kasan.h b/arch/arm64/include/asm/mte-kasan.h
>> new file mode 100644
>> index 000000000000..b0f27de8de33
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/mte-kasan.h
>> @@ -0,0 +1,60 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (C) 2020 ARM Ltd.
>> + */
>> +#ifndef __ASM_MTE_ASM_H
>> +#define __ASM_MTE_ASM_H
>> +
>> +#include <asm/compiler.h>
>> +
>> +#define __MTE_PREAMBLE		ARM64_ASM_PREAMBLE ".arch_extension memtag\n"
> 
> Can this not live in mte.h?
>

Yes, I can move it there in the next version.

>> +#define MTE_GRANULE_SIZE	UL(16)
>> +#define MTE_GRANULE_MASK	(~(MTE_GRANULE_SIZE - 1))
>> +#define MTE_TAG_SHIFT		56
>> +#define MTE_TAG_SIZE		4
>> +#define MTE_TAG_MASK		GENMASK((MTE_TAG_SHIFT + (MTE_TAG_SIZE - 1)), MTE_TAG_SHIFT)
>> +#define MTE_TAG_MAX		(MTE_TAG_MASK >> MTE_TAG_SHIFT)
> 
> I'd still like these MTE_* macros in a separate mte-hwdef.h file. The
> only reason I see they were not in mte.h is because they need to be
> included in asm/cache.h. They are not KASAN specific.
> 

Ok, fine I will reintroduce it in the next version.

>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +#include <linux/types.h>
>> +
>> +#ifdef CONFIG_ARM64_MTE
>> +
>> +static inline u8 mte_get_ptr_tag(void *ptr)
>> +{
>> +	u8 tag = (u8)(((u64)(ptr)) >> MTE_TAG_SHIFT);
>> +
>> +	return tag;
>> +}
> 
> So this returns the top 8 bits of the address (i.e. no masking with
> MTE_TAG_MASK). Fine by me.
> 
>> +
>> +u8 mte_get_mem_tag(void *addr);
>> +u8 mte_get_random_tag(void);
>> +void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag);
>> +
>> +#else /* CONFIG_ARM64_MTE */
>> +
>> +static inline u8 mte_get_ptr_tag(void *ptr)
>> +{
>> +	return 0xFF;
>> +}
>> +
>> +static inline u8 mte_get_mem_tag(void *addr)
>> +{
>> +	return 0xFF;
>> +}
>> +static inline u8 mte_get_random_tag(void)
>> +{
>> +	return 0xFF;
>> +}
>> +static inline void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
>> +{
>> +	return addr;
>> +}
> 
> Maybe these can stay in mte-kasan.h, although they are not a direct
> interface for KASAN AFAICT (the arch_* equivalent are defined in
> asm/memory.h. If there's no good reason, we could move them to mte.h.
>

This is here because it is not a direct interface as you noticed. I tried to
keep the separation (even if it I have something to fix based on your comment
below ;)).

The other kasan implementation define the arch_* indirection in asm/memory.h in
every architecture. I think maintaining the design is the best way to non create
confusion.

>> diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
>> index 1c99fcadb58c..3a2bf3ccb26c 100644
>> --- a/arch/arm64/include/asm/mte.h
>> +++ b/arch/arm64/include/asm/mte.h
>> @@ -5,14 +5,13 @@
>>  #ifndef __ASM_MTE_H
>>  #define __ASM_MTE_H
>>  
>> -#define MTE_GRANULE_SIZE	UL(16)
>> -#define MTE_GRANULE_MASK	(~(MTE_GRANULE_SIZE - 1))
>> -#define MTE_TAG_SHIFT		56
>> -#define MTE_TAG_SIZE		4
>> +#include <asm/mte-kasan.h>
>>  
>>  #ifndef __ASSEMBLY__
>>  
>> +#include <linux/bitfield.h>
>>  #include <linux/page-flags.h>
>> +#include <linux/types.h>
>>  
>>  #include <asm/pgtable-types.h>
>>  
>> @@ -45,7 +44,9 @@ long get_mte_ctrl(struct task_struct *task);
>>  int mte_ptrace_copy_tags(struct task_struct *child, long request,
>>  			 unsigned long addr, unsigned long data);
>>  
>> -#else
>> +void mte_assign_mem_tag_range(void *addr, size_t size);
> 
> So mte_set_mem_tag_range() is KASAN specific but
> mte_assign_mem_tag_range() is not. Slightly confusing.
> 

mte_assign_mem_tag_range() is the internal function implemented in assembler
which is not used directly by KASAN. Is it the name that you find confusing? Do
you have a better proposal?

>> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
>> index 52a0638ed967..833b63fdd5e2 100644
>> --- a/arch/arm64/kernel/mte.c
>> +++ b/arch/arm64/kernel/mte.c
>> @@ -13,8 +13,10 @@
>>  #include <linux/swap.h>
>>  #include <linux/swapops.h>
>>  #include <linux/thread_info.h>
>> +#include <linux/types.h>
>>  #include <linux/uio.h>
>>  
>> +#include <asm/barrier.h>
>>  #include <asm/cpufeature.h>
>>  #include <asm/mte.h>
>>  #include <asm/ptrace.h>
>> @@ -72,6 +74,48 @@ int memcmp_pages(struct page *page1, struct page *page2)
>>  	return ret;
>>  }
>>  
>> +u8 mte_get_mem_tag(void *addr)
>> +{
>> +	if (!system_supports_mte())
>> +		return 0xFF;
>> +
>> +	asm volatile(__MTE_PREAMBLE "ldg %0, [%0]"
>> +		    : "+r" (addr));
> 
> Nitpick: do we need volatile or plain asm would do?
> 

No we clearly don't anymore :) I will remove it in the next iteration.

> I wonder whether we'd need the "memory" clobber. I don't see how this
> would fail though, maybe later on with stack tagging if the compiler
> writes tags behind our back.
> 

As you said, I do not see how this can fail either. We can be overcautious
though here and add a comment that the clobber has been added in prevision of
stack tagging.

>> +
>> +	return 0xF0 | mte_get_ptr_tag(addr);
> 
> Since mte_get_ptr_tag() returns the top byte of the address, we don't
> need the additional 0xF0 or'ing. LDG only sets bits 59:56.
> 

Yes, this can clearly go away.

>> +}
>> +
>> +u8 mte_get_random_tag(void)
>> +{
>> +	void *addr;
>> +
>> +	if (!system_supports_mte())
>> +		return 0xFF;
>> +
>> +	asm volatile(__MTE_PREAMBLE "irg %0, %0"
>> +		    : "+r" (addr));
>> +
>> +	return 0xF0 | mte_get_ptr_tag(addr);
> 
> Same here.
> 

Agreed.

>> +}
>> +
>> +void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
>> +{
>> +	void *ptr = addr;
>> +
>> +	if ((!system_supports_mte()) || (size == 0))
>> +		return addr;
>> +
>> +	/* Make sure that size is aligned. */
>> +	WARN_ON(size & (MTE_GRANULE_SIZE - 1));
> 
> Doesn't the address need to be aligned as well?
> 

Yes, we need an extra WARN_ON here. I will add it in the next version.

>> +
>> +	tag = 0xF0 | tag;
>> +	ptr = (void *)__tag_set(ptr, tag);
>> +
>> +	mte_assign_mem_tag_range(ptr, size);
>> +
>> +	return ptr;
>> +}
>> +
>>  static void update_sctlr_el1_tcf0(u64 tcf0)
>>  {
>>  	/* ISB required for the kernel uaccess routines */
>> diff --git a/arch/arm64/lib/mte.S b/arch/arm64/lib/mte.S
>> index 03ca6d8b8670..aa0ab01252fe 100644
>> --- a/arch/arm64/lib/mte.S
>> +++ b/arch/arm64/lib/mte.S
>> @@ -149,3 +149,22 @@ SYM_FUNC_START(mte_restore_page_tags)
>>  
>>  	ret
>>  SYM_FUNC_END(mte_restore_page_tags)
>> +
>> +/*
>> + * Assign allocation tags for a region of memory based on the pointer tag
>> + *   x0 - source pointer
>> + *   x1 - size
>> + *
>> + * Note: size must be non-zero and MTE_GRANULE_SIZE aligned
> 
> Doesn't the address need to be aligned as well?
> 

The comment can be extended.

>> + */
>> +SYM_FUNC_START(mte_assign_mem_tag_range)
>> +	/* if (src == NULL) return; */
>> +	cbz	x0, 2f
>> +	/* if (size == 0) return; */
>> +	cbz	x1, 2f
> 
> I find these checks unnecessary, as I said a couple of times before,
> just document the function pre-conditions. They are also incomplete
> (i.e. you check for NULL but not alignment).
> 

I thought we agreed to harden the code further, based on [1]. Maybe I
misunderstood. I am going to remove them and extend the comment in the next version.

[1]
https://lore.kernel.org/linux-arm-kernel/921c4ed0-b5b5-bc01-5418-c52d80f1af59@arm.com/

>> +1:	stg	x0, [x0]
>> +	add	x0, x0, #MTE_GRANULE_SIZE
>> +	subs	x1, x1, #MTE_GRANULE_SIZE
>> +	b.gt	1b
>> +2:	ret
>> +SYM_FUNC_END(mte_assign_mem_tag_range)
>> -- 
>> 2.28.0.681.g6f77f65b4e-goog
> 

-- 
Regards,
Vincenzo

  reply	other threads:[~2020-09-25 11:25 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 22:50 [PATCH v3 00/39] kasan: add hardware tag-based mode for arm64 Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 01/39] kasan: drop unnecessary GPL text from comment headers Andrey Konovalov
2020-10-01 17:18   ` elver
2020-09-24 22:50 ` [PATCH v3 02/39] kasan: KASAN_VMALLOC depends on KASAN_GENERIC Andrey Konovalov
2020-10-01 17:19   ` elver
2020-09-24 22:50 ` [PATCH v3 03/39] kasan: group vmalloc code Andrey Konovalov
2020-10-01 17:27   ` elver
2020-09-24 22:50 ` [PATCH v3 04/39] kasan: shadow declarations only for software modes Andrey Konovalov
2020-10-01 17:29   ` elver
2020-09-24 22:50 ` [PATCH v3 05/39] kasan: rename (un)poison_shadow to (un)poison_memory Andrey Konovalov
2020-10-01 17:29   ` elver
2020-09-24 22:50 ` [PATCH v3 06/39] kasan: rename KASAN_SHADOW_* to KASAN_GRANULE_* Andrey Konovalov
2020-10-01 17:30   ` elver
2020-09-24 22:50 ` [PATCH v3 07/39] kasan: only build init.c for software modes Andrey Konovalov
2020-10-01 17:31   ` elver
2020-09-24 22:50 ` [PATCH v3 08/39] kasan: split out shadow.c from common.c Andrey Konovalov
2020-10-01 17:32   ` elver
2020-09-24 22:50 ` [PATCH v3 09/39] kasan: define KASAN_GRANULE_PAGE Andrey Konovalov
2020-10-01 17:33   ` elver
2020-09-24 22:50 ` [PATCH v3 10/39] kasan: rename report and tags files Andrey Konovalov
2020-10-01 17:36   ` elver
2020-09-24 22:50 ` [PATCH v3 11/39] kasan: don't duplicate config dependencies Andrey Konovalov
2020-10-01 17:39   ` elver
2020-10-01 21:54     ` Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 12/39] kasan: hide invalid free check implementation Andrey Konovalov
2020-10-01 17:41   ` elver
2020-09-24 22:50 ` [PATCH v3 13/39] kasan: decode stack frame only with KASAN_STACK_ENABLE Andrey Konovalov
2020-10-01 17:43   ` elver
2020-09-24 22:50 ` [PATCH v3 14/39] kasan, arm64: only init shadow for software modes Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 15/39] kasan, arm64: only use kasan_depth " Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 16/39] kasan: rename addr_has_shadow to addr_has_metadata Andrey Konovalov
2020-10-01 17:45   ` elver
2020-09-24 22:50 ` [PATCH v3 17/39] kasan: rename print_shadow_for_address to print_memory_metadata Andrey Konovalov
2020-10-01 17:45   ` elver
2020-09-24 22:50 ` [PATCH v3 18/39] kasan: kasan_non_canonical_hook only for software modes Andrey Konovalov
2020-10-01 17:47   ` elver
2020-09-24 22:50 ` [PATCH v3 19/39] kasan: rename SHADOW layout macros to META Andrey Konovalov
2020-10-01 17:48   ` elver
2020-09-24 22:50 ` [PATCH v3 20/39] kasan: separate metadata_fetch_row for each mode Andrey Konovalov
2020-10-01 17:54   ` elver
2020-10-01 21:56     ` Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 21/39] kasan: don't allow SW_TAGS with ARM64_MTE Andrey Konovalov
2020-10-01 17:55   ` elver
2020-10-01 21:57     ` Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 22/39] kasan: introduce CONFIG_KASAN_HW_TAGS Andrey Konovalov
2020-10-01 17:57   ` elver
2020-09-24 22:50 ` [PATCH v3 23/39] arm64: Enable armv8.5-a asm-arch option Andrey Konovalov
2020-09-25 10:16   ` Catalin Marinas
2020-09-24 22:50 ` [PATCH v3 24/39] arm64: mte: Add in-kernel MTE helpers Andrey Konovalov
2020-09-25 10:15   ` Catalin Marinas
2020-09-25 11:28     ` Vincenzo Frascino [this message]
2020-09-25 12:50       ` Catalin Marinas
2020-09-25 13:36         ` Vincenzo Frascino
2020-09-24 22:50 ` [PATCH v3 25/39] arm64: kasan: Add arch layer for memory tagging helpers Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 26/39] arm64: mte: Add in-kernel tag fault handler Andrey Konovalov
2020-09-25 10:49   ` Catalin Marinas
2020-09-25 11:26     ` Andrey Konovalov
2020-09-25 11:47       ` Catalin Marinas
2020-09-25 11:52         ` Andrey Konovalov
2020-09-25 12:35           ` Catalin Marinas
2020-09-25 12:35   ` Catalin Marinas
2020-09-24 22:50 ` [PATCH v3 27/39] arm64: kasan: Enable in-kernel MTE Andrey Konovalov
2020-09-25 11:14   ` Catalin Marinas
2020-09-24 22:50 ` [PATCH v3 28/39] arm64: mte: Convert gcr_user into an exclude mask Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 29/39] arm64: mte: Switch GCR_EL1 in kernel entry and exit Andrey Konovalov
2020-09-25 11:34   ` Catalin Marinas
2020-09-25 11:50     ` Vincenzo Frascino
2020-09-25 12:38       ` Catalin Marinas
2020-09-24 22:50 ` [PATCH v3 30/39] arm64: kasan: Enable TBI EL1 Andrey Konovalov
2020-09-25 11:37   ` Catalin Marinas
2020-09-25 11:47     ` Vincenzo Frascino
2020-09-24 22:50 ` [PATCH v3 31/39] arm64: kasan: Align allocations for HW_TAGS Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 32/39] kasan: define KASAN_GRANULE_SIZE " Andrey Konovalov
2020-10-01 17:58   ` elver
2020-10-01 21:59     ` Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 33/39] kasan, x86, s390: update undef CONFIG_KASAN Andrey Konovalov
2020-10-01 17:59   ` elver
2020-09-24 22:50 ` [PATCH v3 34/39] kasan, arm64: expand CONFIG_KASAN checks Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 35/39] kasan, arm64: implement HW_TAGS runtime Andrey Konovalov
2020-10-01 18:00   ` elver
2020-09-24 22:50 ` [PATCH v3 36/39] kasan, arm64: print report from tag fault handler Andrey Konovalov
2020-09-25 11:39   ` Catalin Marinas
2020-09-24 22:50 ` [PATCH v3 37/39] kasan, slub: reset tags when accessing metadata Andrey Konovalov
2020-10-01 18:03   ` elver
2020-10-01 22:00     ` Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 38/39] kasan, arm64: enable CONFIG_KASAN_HW_TAGS Andrey Konovalov
2020-09-24 22:50 ` [PATCH v3 39/39] kasan: add documentation for hardware tag-based mode Andrey Konovalov
2020-10-01 18:03   ` elver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e41f2af1-f208-cc99-64f9-2311ad7d50bf@arm.com \
    --to=vincenzo.frascino@arm.com \
    --cc=Branislav.Rankov@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=catalin.marinas@arm.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kevin.brodsky@arm.com \
    --cc=lenaptr@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).