All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Naveen N Rao <naveen@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>
Cc: <dave.hansen@linux.intel.com>, Ingo Molnar <mingo@kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] x86/devmem: Remove duplicate range_is_allowed() definition
Date: Wed, 16 Apr 2025 14:25:49 -0700	[thread overview]
Message-ID: <6800205d86e73_71fe294e4@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <s6fek3k3zsgf74yuppzckhcnud67pgfitz66n6uwkky7gvjcpc@rp4pxvie2dpb>

Naveen N Rao wrote:
> On Thu, Apr 10, 2025 at 06:22:23PM -0700, Dan Williams wrote:
> > It looks like x86 has a local re-implementation of range_is_allowed()
> > just to add a pat_enabled() check for the strong symbol override of
> > phys_mem_access_prot_allowed() from drivers/char/mem.c.
> > 
> > In preparation for updating range_is_allowed() logic, arrange for there
> > to be only one shared instance of "range_is_allowed()" in the kernel by
> > moving a common helper to include/linux/io.h.
> > 
> > Cc: Dave Hansen <dave.hansen@linux.intel.com>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > ---
> >  arch/x86/mm/pat/memtype.c |   31 ++++---------------------------
> >  drivers/char/mem.c        |   18 ------------------
> >  include/linux/io.h        |   21 +++++++++++++++++++++
> >  3 files changed, 25 insertions(+), 45 deletions(-)
> > 
> > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> > index 72d8cbc61158..c97b6598f187 100644
> > --- a/arch/x86/mm/pat/memtype.c
> > +++ b/arch/x86/mm/pat/memtype.c
> > @@ -38,6 +38,7 @@
> >  #include <linux/kernel.h>
> >  #include <linux/pfn_t.h>
> >  #include <linux/slab.h>
> > +#include <linux/io.h>
> >  #include <linux/mm.h>
> >  #include <linux/highmem.h>
> >  #include <linux/fs.h>
> > @@ -773,38 +774,14 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> >  	return vma_prot;
> >  }
> >  
> > -#ifdef CONFIG_STRICT_DEVMEM
> > -/* This check is done in drivers/char/mem.c in case of STRICT_DEVMEM */
> > -static inline int range_is_allowed(unsigned long pfn, unsigned long size)
> > -{
> > -	return 1;
> > -}
> 
> It looks like no checks were done here if CONFIG_STRICT_DEVMEM was set, 
> so this patch changes that.

Yes, but this still matches the historical intent, and the historical
intent is a tad messy.

The pat_enabled check was originally added as a *bypass* of additional
logic in phys_mem_access_prot_allowed() [1] to validate that /dev/mem was
establishing compatible mappings of "System-RAM" via /dev/mem. This
patch maintains that expectation that phys_mem_access_prot_allowed()
returns immediately when there is no potential cache conflict.

However, the point is moot in current code because [2] and [3] removed
all cache type validation from phys_mem_access_prot_allowed() in favor
track_pfn_remap().

According to:
Commit 9e41bff2708e ("x86: fix /dev/mem mmap breakage when PAT is disabled") [1]
Commit 1886297ce0c8 ("x86/mm/pat: Fix BUG_ON() in mmap_mem() on QEMU/i386") [2]
Commit 0c3c8a18361a ("x86, PAT: Remove duplicate memtype reserve in devmem mmap") [3]

> > -#else
> > -/* This check is needed to avoid cache aliasing when PAT is enabled */
> > -static inline int range_is_allowed(unsigned long pfn, unsigned long size)
> > -{
> > -	u64 from = ((u64)pfn) << PAGE_SHIFT;
> > -	u64 to = from + size;
> > -	u64 cursor = from;
> > -
> > -	if (!pat_enabled())
> > -		return 1;
> > -
> > -	while (cursor < to) {
> > -		if (!devmem_is_allowed(pfn))
> > -			return 0;
> > -		cursor += PAGE_SIZE;
> > -		pfn++;
> > -	}
> > -	return 1;
> > -}
> > -#endif /* CONFIG_STRICT_DEVMEM */
> > -
> >  int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
> >  				unsigned long size, pgprot_t *vma_prot)
> >  {
> >  	enum page_cache_mode pcm = _PAGE_CACHE_MODE_WB;
> >  
> > +	if (!pat_enabled())
> > +		return 1;
> > +
> 
> Shouldn't this test for pat_enabled() (perhaps only if 
> CONFIG_STRICT_DEVMEM is set) and continue with the rest of the function 
> otherwise?

No because, per above, the check is here to short-circuit the rest of
phys_mem_access_prot_allowed() when PAT is disabled.

I will add some notes to the changelog to save the next person from
needing to find the history here.

I found it interesting that Venki suggested that the duplicated
"range_is_allowed()" be cleaned up back in 2008 [4], so this is a
cleanup 17 years (almost to the day) in the making:

Commit 0124cecfc85a ("x86, PAT: disable /dev/mem mmap RAM with PAT") [4]

  reply	other threads:[~2025-04-16 21:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11  1:22 [PATCH v2 0/3] Restrict devmem for confidential VMs Dan Williams
2025-04-11  1:22 ` [PATCH v2 1/3] x86/devmem: Remove duplicate range_is_allowed() definition Dan Williams
2025-04-14 18:17   ` Naveen N Rao
2025-04-16 21:25     ` Dan Williams [this message]
2025-04-17  7:28       ` Naveen N Rao
2025-04-17 18:27         ` Dan Williams
2025-04-19  9:09           ` Naveen N Rao
2025-04-11  1:22 ` [PATCH v2 2/3] devmem: Block mmap access when read/write access is restricted Dan Williams
2025-04-11  2:32   ` Kees Cook
2025-04-11  4:59     ` Dan Williams
2025-04-11 15:38       ` Dave Hansen
2025-04-11 21:48         ` Dan Williams
2025-04-11  1:22 ` [PATCH v2 3/3] x86/devmem: Restrict /dev/mem access for potentially unaccepted memory by default Dan Williams
2025-04-14 18:22   ` Naveen N Rao
2025-04-16 21:30     ` Dan Williams
2025-04-14 10:56 ` [PATCH v2 0/3] Restrict devmem for confidential VMs Nikolay Borisov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6800205d86e73_71fe294e4@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=naveen@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.