[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] [PATCH 0/5] ARMv8.5-MemTag disassembly
From: |
Rémi Denis-Courmont |
Subject: |
Re: [RFC] [PATCH 0/5] ARMv8.5-MemTag disassembly |
Date: |
Fri, 13 Mar 2020 18:05:44 +0200 |
Le perjantaina 13. maaliskuuta 2020, 17.49.06 EET Richard Henderson a écrit :
> 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.
Yes, I'm sure it's feasible on the system mode. Physical indexing is not a
problem there.
> > 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.
>
> 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.
Oh, absolutely: if you only support anonymous memory, then the user mode case
is easy as you can index tags on virtual address - much easier than system
mode in all likelihood. I already had kludgy implementation of that a year
ago, but that was not in a level of code quality that I'd ever submit publicly
to an OSS project. It works fine as long as there's no named mappings in the
tested code. My point was *only* that I can't think of a reasonable way to
implement user mode *correctly*, no more.
And given that it was neither correct nor fast, it seemed doubly questionable
in QEMU. AFAIU, QEMU tries to optimize for speed anyway (hence that it does
not trigger SP alignment exception, for instance).
--
雷米‧德尼-库尔蒙
http://www.remlab.net/