[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~