On Tue, 11 Jan 2022 at 16:33, zadig <zadig@qbool.fr> wrote:
Thanks for your celerity.
The architecture specifies that the number of bits used for the
signature depends on various properties of the CPU and of
the configuration that the host OS has put it into.
Yes, this is why I checked for the TCR value, because basically it only
depends on its value and if BTI is enabled.
This sounds like a bug -- can you provide a repro case ?
Also, if you could confirm that this still happens on a
QEMU built from current git that would be helpful.
(We do have some test cases for pauth -- see tests/tcg/aarch64/pauth*.c --
but it looks like they only test against the aut* instructions, not
against retab.)
I checked using commit 64c01c7da449bcafc614b27ecf1325bb08031c84 and the
RETAB was honored.
You can't change TCR from usermode, because it's a privileged
register. What you get is what QEMU sets it as, which in theory
should be the value that a real Linux kernel would set it to
for the kind of CPU that is being emulated. Looking at the code
I'm not sure if we're setting TCR the same way the kernel does:
to confirm that we'd need to look at the kernel source code and
cross-check what values it uses.
I do not have a clue about how the Linux kernel set the TCR, but I do
not understand why we cannot change it
(for example with a command-line option), since we just emulate code ?
Because qemu-user is specifically emulating a Linux kernel.
We don't want to provide a million tweakable command line options,
it gets unmaintainable very quickly. We just want to provide the
process with the environment that the Linux kernel gives it.
I guess it would be possible if I implement a new machine which derives
from TYPE_VIRT_MACHINE
and I set custom page granule size and page size.
That's system emulation, which is unrelated to usermode emulation
provided by qemu-aarch64. (If you use system emulation, then the
guest kernel that you run under QEMU gets to choose what page
size and so on it configures.)
-- PMM
OpenPGP_signature