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
| ||
|
Message-ID: <62e57a05-cbcf-4727-bca2-af93b4c87ab2@amd.com> Date: Wed, 20 Sep 2017 11:16:10 -0500 From: Brijesh Singh <brijesh.singh@....com> To: Borislav Petkov <bp@...e.de> Cc: brijesh.singh@....com, linux-kernel@...r.kernel.org, x86@...nel.org, kvm@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>, Tom Lendacky <thomas.lendacky@....com>, Arnd Bergmann <arnd@...db.de>, Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>, linux-arch@...r.kernel.org Subject: Re: [Part1 PATCH v4 15/17] percpu: introduce DEFINE_PER_CPU_UNENCRYPTED On 09/20/2017 02:34 AM, Borislav Petkov wrote: > On Tue, Sep 19, 2017 at 08:50:20AM -0500, Brijesh Singh wrote: >> "..shared_aligned" section does not start and end with page-size alignment. > > Nowhere in the code there's a comment saying: "This percpu section really must > be page-size aligned because <reasons>." You need to be more verbose > with requirements like that. > I will add that comment. > Also, you're ending up needing a whole page per-CPU for those variables. > And now with the alignment before and after, you have worst-case two > pages fragmentation of percpu memory and percpu memory is a rather > limited resource AFAIR. > > If only there were a alloc_percpu_page()... > >> Since the C-bit works on PAGE_SIZE alignment hence the "..unencrypted" section > > Btw, call that section "..decrypted" and everywhere do > s/unencrypted/decrypted/g. > Will do >> starts and ends with page-size alignment. The closest I can find is >> "..page_aligned" but again it does not end with page-size alignment. >> >> Additionally, since we clear the C-bit from unencrypted section hence we >> should avoid overloading the existing section -- we don't want to expose more >> than we wish. > > Add that to the comment too. > Will do
Powered by blists - more mailing lists