On Fri, 19 Nov 2021 at 14:39, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> I suppose I wasn't entirely clear on the kernel/user mapping split, I
> just did the second stage and didn't really care about what exactly
> happens in the guest. Things seemed to be a bit more complicated than
> I thought as bits above 48/52 were not ignored after all and made all
> the difference on the table selection. I had the impression it was
> just the calling context that defined the table to be used.
Calling context defines the "translation regime" to be used;
some translation regimes support having two virtual address
ranges and thus two TTBRx registers. (The usual approach at
the OS level is that you make TTBR0_EL1 cover the userspace
process's mappings and TTBR1_EL1 cover the kernel's mappings,
so you can switch processes by changing TTBR0_EL1 only and
leaving the kernel mappings as-is; but that's not obligatory.)
Yes, I had somewhat simplified this in my mind. Thanks.
Maybe this will now allow us to finish the code making the Linux kernel properly read only. We’re moving our host kernels to the gigabyte boundary such that one half can stay genuinely read-only by locking the ro table mapping with the hypervisor. If this works out quite a lot of the randomization effort may be much less urgent.
—
Janne