qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] [PATCH 0/5] ARMv8.5-MemTag disassembly


From: Richard Henderson
Subject: Re: [RFC] [PATCH 0/5] ARMv8.5-MemTag disassembly
Date: Fri, 13 Mar 2020 08:49:06 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 3/13/20 6:59 AM, Rémi Denis-Courmont wrote:
> For proper storage and checking of memory tags, MTE == 2 would be
> necessary. I have some code (on top of this RFC but not included) to add the
> tag allocation logic. But I have no clue how to actually store the tags in 
> QEMU
> system mode at this point, so it's mostly dead code.

I have implemented this, and posted version 6 yesterday.
Peter gave you the link.

> In user mode, it seems impossible anyway, as tags are indexed by physical, not
> virtual address and QEMU cannot know which virtual memory address may
> physically alias another within the user process.

I have implemented this as well, with a made-up ABI controlled by a
command-line option, which only works with non-shared memory.  Because the
memory is non-shared, we know a priori that it does not alias another address.

Version 5 was posted in October:

https://patchew.org/QEMU/address@hidden/

My branch referenced in that cover letter is still available.

You will be interested to follow the Linux kernel development of this feature
and the user-space ABI:

http://lists.infradead.org/pipermail/linux-arm-kernel/2020-February/714413.html

In particular, only anonymous memory and files in filesystems backed by ram
will be supported.  Userspace will get an error if they attempt to enable
PROT_MTE on a VMA that does not support tags.

When I update my mte user branch, I will only support anonymous memory, since I
cannot share my on-the-side data structure for tags between aarch64-linux-user
processes, whether or not they are in a tmpfs filesystem.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]