On Tue, 11 Jan 2022 at 17:06, zadig <za...@qbool.fr> wrote:
>
> > 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.
> Yes, I agree.
I should note that I'm increasingly sure our usermode emulation
code isn't setting up TCR_EL1 correctly. Fixing this might make
more bits available for authentication. I'll put this on my
todo list to investigate.
> > 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.)
> I know this is about system emulation, but I do not know how
> the Linux kernel works, for example if it sources the ID_AA64MMFR0_EL1
> register or not (which - I think - hints the granule size).
ID_AA64MMFR0_EL1 tells guest OS code which page sizes the
emulated CPU supports. QEMU's emulated CPUs always support
all 3 pagesizes (4K, 16K, 64K); real hardware often only
supports a subset of those. The guest OS itself then decides
what page size it wants to use and programs TCR_EL1.{TG0,TG1}
appropriately (assuming that it was built with support for
at least one page size that the hardware supports.)
> Anyways, I will try using system emulation and a custom kernel, to see
> if I can extend the signature size in pointers.
There are definitely config options which can affect it
(for instance the ARM64_VA_BITS_52 config option notes that
it will reduce the size of the pointer auth signature size
to 3 bits !)
-- PMM
