Messages in this thread | | | Date | Thu, 6 Feb 2020 15:52:53 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH 08/11] x86: Add support for finer grained KASLR |
| |
On Thu, Feb 06, 2020 at 04:06:17AM -0800, Kees Cook wrote: > On Thu, Feb 06, 2020 at 11:38:30AM +0100, Peter Zijlstra wrote: > > On Wed, Feb 05, 2020 at 02:39:47PM -0800, Kristen Carlson Accardi wrote: > > > +static long __start___ex_table_addr; > > > +static long __stop___ex_table_addr; > > > +static long _stext; > > > +static long _etext; > > > +static long _sinittext; > > > +static long _einittext; > > > > Should you not also adjust __jump_table, __mcount_loc, > > __kprobe_blacklist and possibly others that include text addresses? > > These don't appear to be sorted at build time.
The ORC tables are though:
57fa18994285 ("scripts/sorttable: Implement build-time ORC unwind table sorting")
> AIUI, the problem with > ex_table and kallsyms is that they're preprocessed at build time and > opaque to the linker's relocation generation.
I was under the impression these tables no longer had relocation data; that since they're part of the main kernel, the final link stage could completely resolve them.
That said, I now see we actually have .rela__extable .rela.orc_unwind_ip etc.
> For example, looking at __jump_table, it gets sorted at runtime: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/jump_label.c#n474
For now, yes. Depends a bit on how hard people are pushing on getting jump_labels working earlier and ealier in boot.
> As you're likely aware, we have a number of "special" > sections like this, currently collected manually, see *_TEXT: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/vmlinux.lds.S#n128
Right.
> I think we can actually add (most of) these to fg-kaslr's awareness (at > which point their order will be shuffled respective to other sections, > but with their content order unchanged), but it'll require a bit of > linker work. I'll mention this series's dependency on the linker's > orphaned section handling in another thread...
I have some patches pending where we rely on link script order. That's data sections though, so I suppose that's safe for the moment.
| |