Re: amd64: kernel aslr support

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 16/01/2018 à 23:54, Thomas Klausner a écrit :
> Hi!
>
> On Wed, Nov 15, 2017 at 07:40:55PM +0100, Maxime Villard wrote:
> > Le 14/11/2017 à 15:43, Maxime Villard a écrit :
> > > The size and number of these blocks is controlled by the split-by-file
> > > parameter in Makefile.amd64. Right now it is set to 2MB, which produces a
> > > kernel with ~23 allocatable (ie useful at runtime) sections, which is a third
> > > of the total number supported (BTSPACE_NSEGS = 64). I will probably reduce
> > > this parameter a bit in the future, to 1.5MB, or even 1MB.
> >
> > Actually I just did it. So now it's 1MB (better security), physically shifted
> > by the prekern (better entropy), and mapped with large pages (better
> > performance). And along the way it mostly mitigates TLB cache attacks.
> >
> > This is still wip but feel free to test, as always,
>
> I've tried out the instructions at
> http://m00nbsd.net/542a5cfd448aaf7db7adcadce74123d2.html and they
> worked fine for me. Thank you!
>
> I have a couple questions:
>
> How can I check (after booting) if the kernel is using ASLR properly?

Well, you could load a kernel module and print the address of some global
variable; it should be different upon each reboot.

Or, you can dump the location of the segments by loading a kernel module
that calls the following function (written from memory):

void DumpSegments(void)
{
	extern struct bootspace bootspace;
	size_t i;

	char names[4] = {
		[BTSEG_NONE] = "none",
		[BTSEG_TEXT] = "text",
		[BTSEG_RODATA] = "rodata",
		[BTSEG_DATA] = "data"
	};

	for (i = 0; i < BTSPACE_NSEGS; i++) {
		if (bootspace.segs[i].type == BTSEG_NONE) {
			continue;
		}
		printf("Segment %zu (%s): va=%p size=%zu\n", i,
			names[bootspace.segs[i].type],
			(void *)bootspace.segs[i].va,
			bootspace.segs[i].sz);
	}
}

It will give you the addresses of the pages containing the kernel sections.
Note however that the sections may not start exactly at the printed addresses,
they are shifted.

> Why does GENERIC_KASLR disable KDTRACE_HOOKS? Is this necessary, or
> are KDTRACE_HOOKS lowering the security somehow?

In fact, it's because KDTRACE_HOOKS wants to parse one CTF section; but with
our implementation we have several of them, and KDTRACE_HOOKS does not
handle that.

There is also GPROF (in kernel mode) that does not work with several text
sections, I'll have to blacklist/fix it too. It appears to be greatly broken,
by the way.

But basically, KASLR should work as-is for everything else.

Maxime