[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
