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: <7c3720ff-b763-44b0-9b57-a2fbff3c7f56@csgroup.eu> Date: Fri, 6 Sep 2024 11:37:34 +0200 From: Christophe Leroy <christophe.leroy@...roup.eu> To: Mike Rapoport <rppt@...nel.org>, Andrew Morton <akpm@...ux-foundation.org> Cc: Andreas Larsson <andreas@...sler.com>, Andy Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>, Borislav Petkov <bp@...en8.de>, Brian Cain <bcain@...cinc.com>, Catalin Marinas <catalin.marinas@....com>, Christoph Hellwig <hch@...radead.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Dinh Nguyen <dinguyen@...nel.org>, Geert Uytterhoeven <geert@...ux-m68k.org>, Guo Ren <guoren@...nel.org>, Helge Deller <deller@....de>, Huacai Chen <chenhuacai@...nel.org>, Ingo Molnar <mingo@...hat.com>, Johannes Berg <johannes@...solutions.net>, John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, Kent Overstreet <kent.overstreet@...ux.dev>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, Luis Chamberlain <mcgrof@...nel.org>, Mark Rutland <mark.rutland@....com>, Masami Hiramatsu <mhiramat@...nel.org>, Matt Turner <mattst88@...il.com>, Max Filippov <jcmvbkbc@...il.com>, Michael Ellerman <mpe@...erman.id.au>, Michal Simek <monstr@...str.eu>, Oleg Nesterov <oleg@...hat.com>, Palmer Dabbelt <palmer@...belt.com>, Peter Zijlstra <peterz@...radead.org>, Richard Weinberger <richard@....at>, Russell King <linux@...linux.org.uk>, Song Liu <song@...nel.org>, Stafford Horne <shorne@...il.com>, Steven Rostedt <rostedt@...dmis.org>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Thomas Gleixner <tglx@...utronix.de>, Uladzislau Rezki <urezki@...il.com>, Vineet Gupta <vgupta@...nel.org>, Will Deacon <will@...nel.org>, bpf@...r.kernel.org, linux-alpha@...r.kernel.org, linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-csky@...r.kernel.org, linux-hexagon@...r.kernel.org, linux-kernel@...r.kernel.org, linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org, linux-mm@...ck.org, linux-modules@...r.kernel.org, linux-openrisc@...r.kernel.org, linux-parisc@...r.kernel.org, linux-riscv@...ts.infradead.org, linux-sh@...r.kernel.org, linux-snps-arc@...ts.infradead.org, linux-trace-kernel@...r.kernel.org, linux-um@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org, loongarch@...ts.linux.dev, sparclinux@...r.kernel.org, x86@...nel.org Subject: Re: [PATCH v2 7/8] execmem: add support for cache of large ROX pages Le 26/08/2024 à 08:55, Mike Rapoport a écrit : > From: "Mike Rapoport (Microsoft)" <rppt@...nel.org> > > Using large pages to map text areas reduces iTLB pressure and improves > performance. > > Extend execmem_alloc() with an ability to use PMD_SIZE'ed pages with ROX > permissions as a cache for smaller allocations. Why only PMD_SIZE ? On power 8xx, PMD_SIZE is 4M and the 8xx doesn't have such a page size. When you call vmalloc() with VM_ALLOW_HUGE_VMAP you get 16k pages or 512k pages depending on the size you ask for, see function arch_vmap_pte_supported_shift() > > To populate the cache, a writable large page is allocated from vmalloc with > VM_ALLOW_HUGE_VMAP, filled with invalid instructions and then remapped as > ROX. > > Portions of that large page are handed out to execmem_alloc() callers > without any changes to the permissions. > > When the memory is freed with execmem_free() it is invalidated again so > that it won't contain stale instructions. > > The cache is enabled when an architecture sets EXECMEM_ROX_CACHE flag in > definition of an execmem_range. > Christophe
Powered by blists - more mailing lists