|
Message-ID: <202008031043.FE182E9@keescook> Date: Mon, 3 Aug 2020 10:45:35 -0700 From: Kees Cook <keescook@...omium.org> To: Evgenii Shatokhin <eshatokhin@...tuozzo.com> Cc: Kristen Carlson Accardi <kristen@...ux.intel.com>, Miroslav Benes <mbenes@...e.cz>, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, arjan@...ux.intel.com, x86@...nel.org, linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com, rick.p.edgecombe@...el.com, live-patching@...r.kernel.org, Joe Lawrence <joe.lawrence@...hat.com>, Josh Poimboeuf <jpoimboe@...hat.com>, Jessica Yu <jeyu@...nel.org> Subject: Re: [PATCH v4 00/10] Function Granular KASLR On Mon, Aug 03, 2020 at 02:39:32PM +0300, Evgenii Shatokhin wrote: > There are at least 2 places where high-order memory allocations might happen > during module loading. Such allocations may fail if memory is fragmented, > while physically contiguous memory areas are not really needed there. I > suggest to switch to kvmalloc/kvfree there. While this does seem to be the right solution for the extant problem, I do want to take a moment and ask if the function sections need to be exposed at all? What tools use this information, and do they just want to see the bounds of the code region? (i.e. the start/end of all the .text* sections) Perhaps .text.* could be excluded from the sysfs section list? -- Kees Cook
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.