Hello,

The following changes since commit d4f7d56759f7c75270c13d5f3f5f736a9558929c:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200312' into staging (2020-03-12 17:34:34 +0000)

adds support for the ARM MTE compatibility subset (which does not seem to have
an official name) to QEMU user mode and system mode on "max" CPU. This
corresponds to MTE == 1 in the instruction set feature field, and allows
running code with MTE instructions without actual tag storage.

Similar to the SP alignment checks, it also adds stubs for memory tag checks
that don't actually do anything at this point and would be optimized out by
the compiler.

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.

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.

----------------------------------------------------------------
Rémi Denis-Courmont (5):
      target/arm: MTE processor state
      target/arm: MTE user mode disassembly
      target/arm: MTE unprivileged system mode disassembly
      target/arm: MTE privileged system mode assembly
      target/arm: MTE tag check stubs

 target/arm/cpu.h           |  17 +++
 target/arm/cpu64.c         |   5 +
 target/arm/helper-a64.c    |   2 +
 target/arm/helper.c        | 118 +++++++++++++++
 target/arm/translate-a64.c | 370 ++++++++++++++++++++++++++++++++++++++++++---
 5 files changed, 494 insertions(+), 18 deletions(-)

-- 
Реми Дёни-Курмон
http://www.remlab.net/

Woops, forgot the --in-reply-to, sorry.

-- 
Реми Дёни-Курмон
http://www.remlab.net/

On Fri, 13 Mar 2020 at 13:59, Rémi Denis-Courmont <remi@remlab.net> wrote:
>
>         Hello,
>
> The following changes since commit d4f7d56759f7c75270c13d5f3f5f736a9558929c:
>
>   Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200312' into staging (2020-03-12 17:34:34 +0000)
>
> adds support for the ARM MTE compatibility subset (which does not seem to have
> an official name) to QEMU user mode and system mode on "max" CPU. This
> corresponds to MTE == 1 in the instruction set feature field, and allows
> running code with MTE instructions without actual tag storage.

Hi; how does this interact with Richard's series for MemTag ?
https://patchew.org/QEMU/20200312194219.24406-1-richard.henderson@linaro.org/

Also, your subject seems odd -- your patches don't touch the
disassembler, only the translator.

thnaks
-- PMM

Le perjantaina 13. maaliskuuta 2020, 16.03.36 EET Peter Maydell a écrit :
> On Fri, 13 Mar 2020 at 13:59, Rémi Denis-Courmont <remi@remlab.net> wrote:
> >         Hello,
> > 
> > The following changes since commit 
d4f7d56759f7c75270c13d5f3f5f736a9558929c:
> >   Merge remote-tracking branch
> >   'remotes/pmaydell/tags/pull-target-arm-20200312' into staging
> >   (2020-03-12 17:34:34 +0000)> 
> > adds support for the ARM MTE compatibility subset (which does not seem to
> > have an official name) to QEMU user mode and system mode on "max" CPU.
> > This corresponds to MTE == 1 in the instruction set feature field, and
> > allows running code with MTE instructions without actual tag storage.
> 
> Hi; how does this interact with Richard's series for MemTag ?
> https://patchew.org/QEMU/20200312194219.24406-1-richard.henderson@linaro.org

It does not. I don't know about that seriers. The patches are part of the 
patchset that lead to my PAuth fixes a year ago. At that time, only beta spec 
was available, including obvious bugs (sysregs with duplicate opcodes), 
suspicious things (TCO being EL3) and generally being a beta. I thus sat on 
that part of the work until I now got time to rebase, clean and update to the 
released spec.

Meanwhile if there's a high-profile developer working on the same thing, I 
guess there's no point for me to carry on.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/

On Fri, 13 Mar 2020 at 15:17, Rémi Denis-Courmont <remi@remlab.net> wrote:
> It does not. I don't know about that seriers. The patches are part of the
> patchset that lead to my PAuth fixes a year ago. At that time, only beta spec
> was available, including obvious bugs (sysregs with duplicate opcodes),
> suspicious things (TCO being EL3) and generally being a beta. I thus sat on
> that part of the work until I now got time to rebase, clean and update to the
> released spec.

Ah, I see.

> Meanwhile if there's a high-profile developer working on the same thing, I
> guess there's no point for me to carry on.

It does sound like Richard's implementation is further advanced.
If you're interested in testing or even reviewing Richard's
patchset that would definitely be appreciated.

thanks
-- PMM

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/20191015163507.12153-1-richard.henderson@linaro.org/

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~

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/