Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 11 May 2022 14:20:45 +0900
From:   Hyeonggon Yoo <42.hyeyoo@gmail.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Tom Lendacky <thomas.lendacky@amd.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Tianyu Lan <Tianyu.Lan@microsoft.com>,
        "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org, vbabka@suse.cz,
        akpm@linux-foundation.org, mgorman@techsingularity.net,
        willy@infradead.org
Subject: Is _PAGE_PROTNONE set only for user mappings?
Message-ID: <YntHrTX12TGp35aF@hyeyoo>
References: <20220506051940.156952-1-42.hyeyoo@gmail.com>
 <56f89895-601e-44c9-bda4-5fae6782e27e@amd.com>
 <YnpTHMvOO/pLJQ+l@hyeyoo>
 <5fe161cb-6c55-6c4d-c208-16c77e115d3f@amd.com>
 <8c2735ac-0335-6e2a-8341-8266d5d13c30@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8c2735ac-0335-6e2a-8341-8266d5d13c30@intel.com>
Precedence: bulk

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