linux-kernel - Re: [PATCH v6 12/18] arm64/mm: Wire up PTE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 16 Feb 2024 11:54:00 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Catalin Marinas <catalin.marinas@....com>,
 Ryan Roberts <ryan.roberts@....com>
Cc: Will Deacon <will@...nel.org>, Ard Biesheuvel <ardb@...nel.org>,
 Marc Zyngier <maz@...nel.org>, James Morse <james.morse@....com>,
 Andrey Ryabinin <ryabinin.a.a@...il.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Matthew Wilcox <willy@...radead.org>, Mark Rutland <mark.rutland@....com>,
 David Hildenbrand <david@...hat.com>,
 Kefeng Wang <wangkefeng.wang@...wei.com>, Zi Yan <ziy@...dia.com>,
 Barry Song <21cnbao@...il.com>, Alistair Popple <apopple@...dia.com>,
 Yang Shi <shy828301@...il.com>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
 linux-arm-kernel@...ts.infradead.org, x86@...nel.org,
 linuxppc-dev@...ts.ozlabs.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 12/18] arm64/mm: Wire up PTE_CONT for user mappings

On 2/16/24 08:56, Catalin Marinas wrote:
..
>> The problem is that the contpte_* symbols are called from the ptep_* inline
>> functions. So where those inlines are called from modules, we need to make sure
>> the contpte_* symbols are available.
>>
>> John Hubbard originally reported this problem against v1 and I enumerated all
>> the drivers that call into the ptep_* inlines here:
>> https://lore.kernel.org/linux-arm-kernel/b994ff89-1a1f-26ca-9479-b08c77f94be8@arm.com/#t
>>
>> So they definitely need to be exported. Perhaps we can tighten it to

Yes. Let's keep the in-tree modules working.

>> EXPORT_SYMBOL_GPL(), but I was being cautious as I didn't want to break anything
>> out-of-tree. I'm not sure what the normal policy is? arm64 seems to use ~equal
>> amounts of both.

EXPORT_SYMBOL_GPL() seems appropriate and low risk. As Catalin says below,
these really are deeply core mm routines, and any module operating at this
level is not going to be able to survive on EXPORT_SYMBOL alone, IMHO.

Now, if only I could find an out of tree module to test that claim on... :)

> I don't think we are consistent here. For example set_pte_at() can't be
> called from non-GPL modules because of __sync_icache_dcache. OTOH, such
> driver is probably doing something dodgy. Same with
> apply_to_page_range(), it's GPL-only (called from i915).
> 
> Let's see if others have any view over the next week or so, otherwise
> I'd go for _GPL and relax it later if someone has a good use-case (can
> be a patch on top adding _GPL).

I think going directly to _GPL for these is fine, actually.

thanks,
-- 
John Hubbard
NVIDIA