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: Mon, 9 Oct 2017 18:13:37 +0100 From: Will Deacon <will.deacon@....com> To: Mark Rutland <mark.rutland@....com> Cc: Pavel Tatashin <pasha.tatashin@...cle.com>, catalin.marinas@....com, linux-kernel@...r.kernel.org, sparclinux@...r.kernel.org, linux-mm@...ck.org, linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, x86@...nel.org, kasan-dev@...glegroups.com, borntraeger@...ibm.com, heiko.carstens@...ibm.com, davem@...emloft.net, willy@...radead.org, mhocko@...nel.org, ard.biesheuvel@...aro.org, sam@...nborg.org, mgorman@...hsingularity.net, steven.sistare@...cle.com, daniel.m.jordan@...cle.com, bob.picco@...cle.com Subject: Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function On Tue, Oct 03, 2017 at 03:48:46PM +0100, Mark Rutland wrote: > On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote: > > During early boot, kasan uses vmemmap_populate() to establish its shadow > > memory. But, that interface is intended for struct pages use. > > > > Because of the current project, vmemmap won't be zeroed during allocation, > > but kasan expects that memory to be zeroed. We are adding a new > > kasan_map_populate() function to resolve this difference. > > Thanks for putting this together. > > I've given this a spin on arm64, and can confirm that it works. > > Given that this involes redundant walking of page tables, I still think > it'd be preferable to have some common *_populate() helper that took a > gfp argument, but I guess it's not the end of the world. > > I'll leave it to Will and Catalin to say whether they're happy with the > page table walking and the new p{u,m}d_large() helpers added to arm64. To be honest, it just looks completely backwards to me; we're walking the page tables we created earlier on so that we can figure out what needs to be zeroed for KASAN. We already had that information before, hence my preference to allow propagation of GFP_FLAGs to vmemmap_alloc_block when it's needed. I know that's not popular for some reason, but is walking the page tables really better? Will
Powered by blists - more mailing lists