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: Thu, 29 Oct 2020 09:15:47 +0100 From: David Hildenbrand <david@...hat.com> To: Mike Rapoport <rppt@...nel.org>, Andrew Morton <akpm@...ux-foundation.org> Cc: Albert Ou <aou@...s.berkeley.edu>, Andy Lutomirski <luto@...nel.org>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Borislav Petkov <bp@...en8.de>, Catalin Marinas <catalin.marinas@....com>, Christian Borntraeger <borntraeger@...ibm.com>, Christoph Lameter <cl@...ux.com>, "David S. Miller" <davem@...emloft.net>, Dave Hansen <dave.hansen@...ux.intel.com>, David Rientjes <rientjes@...gle.com>, "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, "H. Peter Anvin" <hpa@...or.com>, Heiko Carstens <hca@...ux.ibm.com>, Ingo Molnar <mingo@...hat.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, "Kirill A. Shutemov" <kirill@...temov.name>, Len Brown <len.brown@...el.com>, Michael Ellerman <mpe@...erman.id.au>, Mike Rapoport <rppt@...ux.ibm.com>, Palmer Dabbelt <palmer@...belt.com>, Paul Mackerras <paulus@...ba.org>, Paul Walmsley <paul.walmsley@...ive.com>, Pavel Machek <pavel@....cz>, Pekka Enberg <penberg@...nel.org>, Peter Zijlstra <peterz@...radead.org>, "Rafael J. Wysocki" <rjw@...ysocki.net>, Thomas Gleixner <tglx@...utronix.de>, Vasily Gorbik <gor@...ux.ibm.com>, Will Deacon <will@...nel.org>, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-pm@...r.kernel.org, linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, sparclinux@...r.kernel.org, x86@...nel.org Subject: Re: [PATCH 0/4] arch, mm: improve robustness of direct map manipulation On 25.10.20 11:15, Mike Rapoport wrote: > From: Mike Rapoport <rppt@...ux.ibm.com> > > Hi, > > During recent discussion about KVM protected memory, David raised a concern > about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC scope [1]. > > Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is > possible that __kernel_map_pages() would fail, but since this function is > void, the failure will go unnoticed. > > Moreover, there's lack of consistency of __kernel_map_pages() semantics > across architectures as some guard this function with > #ifdef DEBUG_PAGEALLOC, some refuse to update the direct map if page > allocation debugging is disabled at run time and some allow modifying the > direct map regardless of DEBUG_PAGEALLOC settings. > > This set straightens this out by restoring dependency of > __kernel_map_pages() on DEBUG_PAGEALLOC and updating the call sites > accordingly. > So, I was primarily wondering if we really have to touch direct mappings in hibernation code, or if we can avoid doing that. I was wondering if we cannot simply do something like kmap() when trying to access a !mapped page. Similar to reading old-os memory after kexec when in kdump. Just a thought. -- Thanks, David / dhildenb
Powered by blists - more mailing lists