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
| ||
|
Date: Wed, 10 Aug 2022 22:00:57 +0000 From: "Kalra, Ashish" <Ashish.Kalra@....com> To: Borislav Petkov <bp@...en8.de> CC: "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>, "tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "jroedel@...e.de" <jroedel@...e.de>, "Lendacky, Thomas" <Thomas.Lendacky@....com>, "hpa@...or.com" <hpa@...or.com>, "ardb@...nel.org" <ardb@...nel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>, "seanjc@...gle.com" <seanjc@...gle.com>, "vkuznets@...hat.com" <vkuznets@...hat.com>, "jmattson@...gle.com" <jmattson@...gle.com>, "luto@...nel.org" <luto@...nel.org>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "slp@...hat.com" <slp@...hat.com>, "pgonda@...gle.com" <pgonda@...gle.com>, "peterz@...radead.org" <peterz@...radead.org>, "srinivas.pandruvada@...ux.intel.com" <srinivas.pandruvada@...ux.intel.com>, "rientjes@...gle.com" <rientjes@...gle.com>, "dovmurik@...ux.ibm.com" <dovmurik@...ux.ibm.com>, "tobin@....com" <tobin@....com>, "Roth, Michael" <Michael.Roth@....com>, "vbabka@...e.cz" <vbabka@...e.cz>, "kirill@...temov.name" <kirill@...temov.name>, "ak@...ux.intel.com" <ak@...ux.intel.com>, "tony.luck@...el.com" <tony.luck@...el.com>, "marcorr@...gle.com" <marcorr@...gle.com>, "sathyanarayanan.kuppuswamy@...ux.intel.com" <sathyanarayanan.kuppuswamy@...ux.intel.com>, "alpergun@...gle.com" <alpergun@...gle.com>, "dgilbert@...hat.com" <dgilbert@...hat.com>, "jarkko@...nel.org" <jarkko@...nel.org> Subject: RE: [PATCH Part2 v6 09/49] x86/fault: Add support to handle the RMP fault for user address [AMD Official Use Only - General] Hello Boris, >> >You need to elaborate more here: a RMP fault can happen and then the >> >page can get unmapped? What is the exact scenario here? >> >> Yes, if the page gets unmapped while the RMP fault was being handled, >> will add more explanation here. >So what's the logic here to return 1, i.e., retry? >Why should a fault for a page that gets unmapped be retried? The fault in that case should be ignored, IMO. It'll have the same effect to return from do_user_addr_fault() there, without splitting but you need to have a separate return value >definition so that it is clear what needs to happen. And that return value should be != 0 so that the current check still works. if (!pte || !pte_present(*pte)) return 1; This is more like a sanity check and returning 1 will cause the fault handler to return and ignore the fault for current #PF case. If the page got unmapped, the fault will not happen again and there will be no retry, so the fault in this case is being ignored. The other case where 1 is returned is RMP table lookup failure, in that case the faulting process is being terminated, that resolves the fault. >> Actually, the above computes an index into the RMP table. >What index in the RMP table? >> It is basically an index into the 4K page within the hugepage mapped >> in the RMP table or in other words an index into the RMP table entry >> for 4K page(s) corresponding to a hugepage. >So pte_index(address) and for 1G pages, pmd_index(address). >So no reinventing the wheel if we already have helpers for that. Yes that makes sense and pte_index(address) is exactly what is required for 2M hugepages. Will use pte_index() for 2M pages and pmd_index() for 1G pages. >> It is mainly a wrapper around__split_huge_pmd() for SNP use case where >> the host hugepage is split to be in sync with the RMP table. >I see what it is. And I'm saying this looks wrong. You're enforcing page splitting to be a valid thing to do only for SEV machines. Why? >Why is > if (!IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT)) > return VM_FAULT_SIGBUS; >there at all? >This is generic code you're touching - not arch/x86/. Ok, so you are suggesting that we remove this check and simply keep this function wrapping around __split_huge_pmd(). This becomes a generic utility function. Thanks, Ashish
Powered by blists - more mailing lists