On Tue, Nov 28, 2023 at 06:06:54PM +0100, David Hildenbrand wrote: > On 19.11.23 17:57, Alexandru Elisei wrote: > > On arm64, the zero page receives special treatment by having the tagged > > flag set on MTE initialization, not when the page is mapped in a process > > address space. Reserve the corresponding tag block when tag storage > > management is being activated. > > Out of curiosity: why does the shared zeropage require tagged storage? What > about the huge zeropage? There are two different tags that are used for tag checking: the logical tag, the tag embedded in bits 59:56 of an address, and the physical tag corresponding to the address. This tag is stored in a separate memory location, called tag storage. When an access is performed, hardware compares the logical tag (from the address) with the physical tag (from the tag storage). If they match, the access is permitted. The physical tag is set with special instructions. Userspace pointers have bits 59:56 zero. If the pointer is in a VMA with MTE enabled, then for userspace to be able to access this address, the physical tag must also be 0b0000. To make it easier on userspace, when a page is first mapped as tagged, its tags are cleared by the kernel; this way, userspace can access the address immediately, without clearing the physical tags beforehand. Another reason for clearing the physical tags when a page is mapped as tagged would be to avoid leaking uninitialized tags to userspace. The zero page is special, because the physical tags are not zeroed every time the page is mapped in a process; instead, the zero page is marked as tagged (by setting a page flag) and the physical tags are zeroed only once, when MTE is enabled at boot. All of this means that when tag storage is enabled, which happens after MTE is enabled, the tag storage corresponding to the zero page is already in use and must be rezerved, and it can never be used for data allocations. I hope all of the above makes sense. I can also put it in the commit message :) As for the zero huge page, the MTE code in the kernel treats it like a regular page, and it zeroes the tags when it is mapped as tagged in a process. I agree that this might not be the best solution from a performance perspective, but it has worked so far. With tag storage management enabled, set_pte_at()->mte_sync_tags() will discover that the huge zero page doesn't have tag storage reserved, the table entry will be mapped as invalid to use the page fault-on-access mechanism that I introduce later in the series [1] to reserve tag storage, and after that set_pte_at() will zero the physical tags. [1] https://lore.kernel.org/all/20231119165721.9849-20-alexandru.elisei@xxxxxxx/ Thanks, Alex > > -- > Cheers, > > David / dhildenb >
