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