Re: [PATCH] x86: Use entire page for the per-cpu GDT only if paravirt-enabled

From: Ingo Molnar
Date: Mon Sep 28 2015 - 03:59:01 EST



* Denys Vlasenko <dvlasenk@xxxxxxxxxx> wrote:

> On 09/26/2015 09:50 PM, H. Peter Anvin wrote:
> > NAK. We really should map the GDT read-only on all 64 bit systems,
> > since we can't hide the address from SLDT. Same with the IDT.
>
> Sorry, I don't understand your point.

So the problem is that right now the SGDT instruction (which is unprivileged)
leaks the real address of the kernel image:

fomalhaut:~> ./sgdt
SGDT: ffff88303fd89000 / 007f

that 'ffff88303fd89000' is a kernel address.

fomalhaut:~> cat sgdt.c
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
struct gdt_desc {
unsigned short limit;
unsigned long addr;
} __attribute__((packed)) gdt_desc = { -1, -1 };

asm volatile("sgdt %0": "=m" (gdt_desc));

printf("SGDT: %016lx / %04x\n", gdt_desc.addr, gdt_desc.limit);

return 0;
}

Your observation in the changelog and your patch:

> >> It is page-sized because of paravirt. [...]

... conflicts with the intention to mark (remap) the primary GDT address read-only
on native kernels as well.

So what we should do instead is to use the page alignment properly and remap the
GDT to a read-only location, and load that one.

This would have a couple of advantages:

- This would give kernel address randomization more teeth on x86.

- An additional advantage would be that rootkits overwriting the GDT would have
a bit more work to do.

- A third advantage would be that for NUMA systems we could 'mirror' the GDT into
node-local memory and load those. This makes GDT load cache-misses a bit less
expensive.

The IDT is already remapped:

fomalhaut:~> ./sidt
Sidt: ffffffffff57b000 / 0fff
fomalhaut:~> cat sidt.c
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
struct idt_desc {
unsigned short limit;
unsigned long addr;
} __attribute__((packed)) idt_desc = { -1, -1 };

asm volatile("sidt %0": "=m" (idt_desc));

printf("Sidt: %016lx / %04x\n", idt_desc.addr, idt_desc.limit);

return 0;
}

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/