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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 18 Dec 2020 11:20:45 -0800 From: Dan Williams <dan.j.williams@...el.com> To: Thomas Gleixner <tglx@...utronix.de> Cc: "Weiny, Ira" <ira.weiny@...el.com>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Fenghua Yu <fenghua.yu@...el.com>, X86 ML <x86@...nel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>, Linux Doc Mailing List <linux-doc@...r.kernel.org>, linux-nvdimm <linux-nvdimm@...ts.01.org>, Linux MM <linux-mm@...ck.org>, linux-kselftest@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org> Subject: Re: [PATCH V3 04/10] x86/pks: Preserve the PKRS MSR on context switch On Fri, Dec 18, 2020 at 5:58 AM Thomas Gleixner <tglx@...utronix.de> wrote: [..] > 5) The DAX case which you made "work" with dev_access_enable() and > dev_access_disable(), i.e. with yet another lazy approach of > avoiding to change a handful of usage sites. > > The use cases are strictly context local which means the global > magic is not used at all. Why does it exist in the first place? > > Aside of that this global thing would never work at all because the > refcounting is per thread and not global. > > So that DAX use case is just a matter of: > > grant/revoke_access(DEV_PKS_KEY, READ/WRITE) > > which is effective for the current execution context and really > wants to be a distinct READ/WRITE protection and not the magic > global thing which just has on/off. All usage sites know whether > they want to read or write. I was tracking and nodding until this point. Yes, kill the global / kmap() support, but if grant/revoke_access is not integrated behind kmap_{local,atomic}() then it's not a "handful" of sites that need to be instrumented it's 100s. Are you suggesting that "relaxed" mode enforcement is a way to distribute the work of teaching driver writers that they need to incorporate explicit grant/revoke-read/write in addition to kmap? The entire reason PTE_DEVMAP exists was to allow get_user_pages() for PMEM and not require every downstream-GUP code path to specifically consider whether it was talking to PMEM or RAM pages, and certainly not whether they were reading or writing to it.
Powered by blists - more mailing lists