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: Tue, 6 Sep 2022 22:14:10 -0700 From: Marc Orr <marcorr@...gle.com> To: "Kalra, Ashish" <Ashish.Kalra@....com> Cc: "Roth, Michael" <Michael.Roth@....com>, Jarkko Sakkinen <jarkko@...nel.org>, Borislav Petkov <bp@...en8.de>, x86 <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, kvm list <kvm@...r.kernel.org>, "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>, Linux Memory Management List <linux-mm@...ck.org>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>, "Lendacky, Thomas" <Thomas.Lendacky@....com>, "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, Sean Christopherson <seanjc@...gle.com>, Vitaly Kuznetsov <vkuznets@...hat.com>, Jim Mattson <jmattson@...gle.com>, Andy Lutomirski <luto@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>, Peter Zijlstra <peterz@...radead.org>, Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, David Rientjes <rientjes@...gle.com>, Dov Murik <dovmurik@...ux.ibm.com>, Tobin Feldman-Fitzthum <tobin@....com>, Vlastimil Babka <vbabka@...e.cz>, "Kirill A . Shutemov" <kirill@...temov.name>, Andi Kleen <ak@...ux.intel.com>, Tony Luck <tony.luck@...el.com>, Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@...ux.intel.com>, Alper Gun <alpergun@...gle.com>, "Dr . David Alan Gilbert" <dgilbert@...hat.com> Subject: Re: [PATCH Part2 v6 09/49] x86/fault: Add support to handle the RMP fault for user address > >> >But I believe Jarkko's version calculates the correct mask (below), incorporating all 18 offset bits into the 1G page. > >> >>> hex(262144 -1) > >> >'0x3ffff' > >> > >> We can get this simply by doing (page_per_hpage(level)-1), but as I mentioned above this is not what we need. > > >If we actually want the 4K page, I think we would want to use the 0x3ffff mask as Marc suggested to get to the specific 4K RMP entry, which I don't think the current code is trying to do. But maybe that *should* be what we should be doing. > > Ok, I agree to get to the specific 4K RMP entry. Thanks, Michael, for a thorough and complete reply! I have to admit, there was some nuance I missed in my earlier reply. But after reading through what you wrote, I agree, always going to the 4k-entry to get the "assigned" bit and also leveraging the implementation of snp_lookup_rmpentry() to lookup the size bit in the 2M-aligned entry seems like an elegant way to code this up. Assuming this suggestion becomes the consensus, we might consider a comment in the source code to capture this discussion. Otherwise, I think I'll forget all of this the next time I'm reading this code :-). Something like: /* * The guest-assigned bit is always propagated to the paddr's respective 4k RMP * entry -- regardless of the actual RMP page size. In contrast, the RMP page * size, handled in snp_lookup_rmpentry(), is indicated by the 2M-aligned RMP * entry. */
Powered by blists - more mailing lists