On Fri, Jul 03, 2026 at 06:13:31PM +0100, Will Deacon wrote: > On Thu, Jul 02, 2026 at 06:41:23PM +0200, Thierry Reding wrote: > > On Thu, Jul 02, 2026 at 03:46:44PM +0200, Thierry Reding wrote: > > > On Thu, Jul 02, 2026 at 10:18:47AM +0100, Will Deacon wrote: > > > > On Wed, Jul 01, 2026 at 06:08:15PM +0200, Thierry Reding wrote: > > > > > From: Chun Ng <[email protected]> > > > > > > > > > > Add helpers to swap PROT_NORMAL and PROT_DEVICE_nGnRnE protection bits > > > > > on a kernel-linear-map range. > > > > > > > > That sounds like a really terrible idea. Why is this necessary and how > > > > does it interact with things like load_unaligned_zeropad()? > > > > > > This is necessary because once the memory controller has walled off the > > > new memory region the CPU must not access it under any circumstances or > > > it'll cause the CPU to lock up (I think technically it'll hit an SError > > > but in practice that just means it'll freeze, as far as I can tell). > > > > > > Probably doesn't interact well at all with load_unaligned_zeropad(). > > > > > > > I think you should unmap the memory from the linear map and memremap() > > > > it instead. > > > > > > Given that the memory can never be accessed by the CPU after the memory > > > controller locks it down, I don't think we'll even need memremap(). The > > > only thing we really need is the sg_table we hand out via the DMA BUFs > > > so that they can be used by device drivers to program their DMA engines > > > internally. > > > > > > Looking through some of the architecture code around this, shouldn't we > > > simply be using set_memory_encrypted() and set_memory_decrypted() for > > > this? While they might've been created for slightly other use-cases, > > > they seem to be doing exactly what we want (i.e. remove the page range > > > from the linear mapping and flushing it, or restoring the valid bit and > > > standard permissions, respectively). > > > > Ah... I guess we can't do it because we're not in a realm world and so > > the early checks in __set_memory_enc_dec() would return early and turn > > it into a no-op. > > > > How about if I extract a common helper and provide set_memory_p() and > > set_memory_np() in terms of those. Those are available on x86 and > > PowerPC as well, so fairly standard. I suppose at that point we're > > closer to set_memory_valid(). > > Why not just call set_direct_map_invalid_noflush() + > flush_tlb_kernel_range() for each page? We already have APIs for this. > > The big challenge I see with any linear map manipulation, however, is > that it will rely on can_set_direct_map() which likely means you need to > give up some performance and/or security to make this work. Does memory > become inaccesible dynamically at runtime? If not, the best bet would > be to describe it as a carveout in the DT and mark it as "no-map" so > we avoid mapping it in the first place.
While I got your attention a bit off-topic but still related question. AFAIK a lot in arm64 drivers ecosystem relies on that ranges defined as "/reserved-memory" in DT are linked to devices that use that memory. EFI/ACPI does not have a similar concept. Given that more and more systems are using EFI/ACPI rather than DT as their boot protocol we probably need some way to define such memory carveouts in the ACPI world. > Will -- Sincerely yours, Mike.
