Is _PAGE_PROTNONE set only for user mappings?

[Hyeonggon Yoo <42.hyeyoo@gmail.com>]

On Tue, May 10, 2022 at 07:39:30AM -0700, Dave Hansen wrote:
> On 5/10/22 06:35, Tom Lendacky wrote:
> > I'm wondering if adding a specific helper that takes a boolean to
> > indicate whether to set the global flag would be best. I'll let some of
> > the MM maintainers comment about that.
> 
> First of all, I'm not positive that _PAGE_BIT_PROTNONE is ever used for
> kernel mappings.  This would all get a lot easier if we decided that
> _PAGE_BIT_PROTNONE is only for userspace mappings and we don't have to
> worry about it when _PAGE_USER is clear.

After quickly skimming code it seems the place that actually sets _PAGE_PROTNONE
is via mm/mmap.c's protection_map:

> /* description of effects of mapping type and prot in current implementation.
>  * this is due to the limited x86 page protection hardware.  The expected
>  * behavior is in parens:
>  *
>  * map_type     prot
>  *              PROT_NONE       PROT_READ       PROT_WRITE      PROT_EXEC
>  * MAP_SHARED   r: (no) no      r: (yes) yes    r: (no) yes     r: (no) yes
>  *              w: (no) no      w: (no) no      w: (yes) yes    w: (no) no
>  *              x: (no) no      x: (no) yes     x: (no) yes     x: (yes) yes
>  *              
>  * MAP_PRIVATE  r: (no) no      r: (yes) yes    r: (no) yes     r: (no) yes
>  *              w: (no) no      w: (no) no      w: (copy) copy  w: (no) no
>  *              x: (no) no      x: (no) yes     x: (no) yes     x: (yes) yes
>  *
>  */
> pgprot_t protection_map[16] = { 
>        __P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111,
>        __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111
> };

Where __P000, __S000 is PAGE_NONE (_PAGE_ACCESSED | _PAGE_PROTNONE).

And protection_map is accessed via:
> pgprot_t vm_get_page_prot(unsigned long vm_flags)
> {
>        pgprot_t ret = __pgprot(pgprot_val(protection_map[vm_flags &
>                                (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
>                        pgprot_val(arch_vm_get_page_prot(vm_flags)));
>
>        return arch_filter_pgprot(ret);
> }
> EXPORT_SYMBOL(vm_get_page_prot);

I guess it's only set for processes' VMA if no caller is abusing
vm_get_page_prot() for kernel mappings.

But yeah, just quick guessing does not make us convinced.
Let's Cc people working on mm.

If kernel never uses _PAGE_PROTNONE for kernel mappings, it's just okay
not to clear _PAGE_GLOBAL at first in __change_page_attr() if it's not user address,
because no user will confuse _PAGE_GLOBAL as _PAGE_PROTNONE if it's kernel
address. right?

> 
> Second, the number of places that do these
> __set_pages_p()/__set_pages_np() pairs is pretty limited.  Some of them
> are *quite* unambiguous over whether they are dealing with the direct map:
> 
> > int set_direct_map_invalid_noflush(struct page *page)
> > {
> >         return __set_pages_np(page, 1);
> > }
> > 
> > int set_direct_map_default_noflush(struct page *page)
> > {
> >         return __set_pages_p(page, 1);
> > }
> 
> which would make it patently obvious whether __set_pages_p() should
> restore the global bit.  That would have been a problem in the "old" PTI
> days where _some_ of the direct map was exposed to Meltdown.  I don't
> think we have any of those mappings left, though.  They're all aliases
> like text and cpu_entry_area.
>
> It would be nice if someone could look into unraveling
> _PAGE_BIT_PROTNONE.  We could even probably move it to another bit for
> kernel mappings if we actually need it (I'm not convinced we do).

-- 
Thanks,
Hyeonggon