All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Thierry Reding" <thierry.reding@kernel.org>
Cc: conor+dt@kernel.org, linux-s390@vger.kernel.org,
	devicetree@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	dri-devel@lists.freedesktop.org, media-ci@linuxtv.org,
	robh@kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH v6 04/12] arm64/mm: Export set_direct_map_*_noflush() APIs
Date: Fri, 04 Sep 2026 11:13:33 +0000	[thread overview]
Message-ID: <20260904111333.66EBC1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904-tegra-vpr-v6-4-79042cfa8de5@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Exporting `set_direct_map_*_noflush` APIs without exporting `can_set_direct_map` forces loadable modules to silently fail to protect memory on ARM64, breaking security guarantees.
--

commit 6a5f6422ed6de263b9c669919e175cc7d1ac6c09
Author: Thierry Reding <treding@nvidia.com>

arm64/mm: Export set_direct_map_*_noflush() APIs

Drivers that use this may want to be built as a module, so export them.

> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 132938b32eb16..9253c529f8aa5 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -262,6 +262,7 @@ int set_direct_map_invalid_noflush(struct page *page, unsigned int numpages)
>  	return update_range_prot((unsigned long)page_address(page),
>  				 PAGE_SIZE * numpages, set_mask, clear_mask);
>  }
> +EXPORT_SYMBOL(set_direct_map_invalid_noflush);

[Severity: High]
Are loadable modules going to silently fail to protect memory when using this
exported API?

If the kernel boots with a configuration where can_set_direct_map() is false
(e.g., rodata_full and debug_pagealloc are disabled), 
set_direct_map_invalid_noflush() returns 0 without modifying the page tables:

arch/arm64/mm/pageattr.c:set_direct_map_invalid_noflush() {
	...
	if (!can_set_direct_map())
		return 0;
	...
}

Because can_set_direct_map() is not exported, a module cannot check this
capability itself. The module will receive 0 (success) and mistakenly assume
the memory was successfully isolated.

For security features, this means content-protected memory remains accessible
in the kernel's linear mapping. This can break DRM guarantees by allowing the
CPU to read protected memory, or cause a kernel panic if the hardware enforces
protection but the CPU speculatively accesses the region via stale linear map
PTEs.

>  
>  int set_direct_map_default_noflush(struct page *page, unsigned int numpages)
>  {
> @@ -274,6 +275,7 @@ int set_direct_map_default_noflush(struct page *page, unsigned int numpages)
>  	return update_range_prot((unsigned long)page_address(page),
>  				 PAGE_SIZE * numpages, set_mask, clear_mask);
>  }
> +EXPORT_SYMBOL(set_direct_map_default_noflush);

[Severity: High]
Does this apply the same silent failure logic when a module attempts to
restore the mapping?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904-tegra-vpr-v6-0-79042cfa8de5@nvidia.com?part=4

  reply	other threads:[~2026-09-04 11:13 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04 10:44 [PATCH v6 00/12] dma-buf: heaps: Add support for Tegra VPR Thierry Reding
2026-09-04 10:44 ` [PATCH v6 01/12] dt-bindings: reserved-memory: Document " Thierry Reding
2026-09-04 10:59   ` sashiko-bot
2026-09-04 10:44 ` [PATCH v6 02/12] dt-bindings: display: tegra: Document memory regions Thierry Reding
2026-09-04 10:56   ` sashiko-bot
2026-09-04 10:44 ` [PATCH v6 03/12] dt-bindings: gpu: host1x: Document memory-regions for NVDEC Thierry Reding
2026-09-04 11:03   ` sashiko-bot
2026-09-09 14:13     ` Thierry Reding
2026-09-04 10:44 ` [PATCH v6 04/12] arm64/mm: Export set_direct_map_*_noflush() APIs Thierry Reding
2026-09-04 11:13   ` sashiko-bot [this message]
2026-09-10  5:51   ` Christoph Hellwig
2026-09-10  9:21     ` Thierry Reding
2026-09-04 10:44 ` [PATCH v6 05/12] bitmap: Add bitmap_allocate() function Thierry Reding
2026-09-04 11:13   ` sashiko-bot
2026-09-04 10:44 ` [PATCH v6 06/12] of: Export of_node_to_nid() Thierry Reding
2026-09-04 11:21   ` sashiko-bot
2026-09-08 14:59   ` Rob Herring
2026-09-10 10:52     ` Thierry Reding
2026-09-04 10:44 ` [PATCH v6 07/12] mm/cma: Introduce cma_alloc_at() API Thierry Reding
2026-09-04 11:22   ` sashiko-bot
2026-09-08  8:21   ` Marek Szyprowski
2026-09-04 10:44 ` [PATCH v6 08/12] dma-buf: heaps: Add debugfs support Thierry Reding
2026-09-04 11:34   ` sashiko-bot
     [not found]   ` <a77730b2-b5d6-49f9-a8ab-72eac4e241b6@amd.com>
2026-09-09 11:04     ` Christian König
2026-09-09 14:09       ` Thierry Reding
2026-09-04 10:45 ` [PATCH v6 09/12] dma-buf: heaps: Add support for Tegra VPR Thierry Reding
2026-09-04 11:38   ` sashiko-bot
2026-09-08 14:56   ` Rob Herring
2026-09-04 10:45 ` [PATCH v6 10/12] arm64: tegra: Add VPR placeholder node on Tegra234 Thierry Reding
2026-09-04 11:54   ` sashiko-bot
2026-09-04 10:45 ` [PATCH v6 11/12] arm64: tegra: Hook up VPR to host1x Thierry Reding
2026-09-04 11:49   ` sashiko-bot
2026-09-04 10:45 ` [PATCH v6 12/12] arm64: tegra: Add VPR placeholder node on Tegra264 Thierry Reding
2026-09-04 11:53   ` sashiko-bot
2026-09-04 11:41 ` [PATCH v6 00/12] dma-buf: heaps: Add support for Tegra VPR Will Deacon
2026-09-08  8:39   ` Thierry Reding
2026-09-08  8:57     ` Vincent Donnefort
2026-09-08  9:08       ` Thierry Reding
2026-09-08  9:10         ` Vincent Donnefort
2026-09-08  9:06     ` Thierry Reding

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=20260904111333.66EBC1F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=media-ci@linuxtv.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=thierry.reding@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.