x86/mm/KASLR: Remap GDTs at fixed location

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE_OFFSET).

In this change, a space is reserved at the end of the memory range available for KASLR memory randomization. The space is big enough to hold the maximum number of CPUs (as defined by setup_max_cpus). Each GDT is mapped at specific offset based on the target CPU. Note that if there is not enough space available, the GDTs are not remapped.

The document was changed to mention GDT remapping for KASLR. This patch also include dump page tables support.

This patch was tested on multiple hardware configurations and for hibernation support.

void kernel_randomize_memory(void);

Quoted 17 lines · Thomas Garnier

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE_OFFSET).

In this change, a space is reserved at the end of the memory range available for KASLR memory randomization. The space is big enough to hold the maximum number of CPUs (as defined by setup_max_cpus). Each GDT is mapped at specific offset based on the target CPU. Note that if there is not enough space available, the GDTs are not remapped.

The document was changed to mention GDT remapping for KASLR. This patch also include dump page tables support.

This patch was tested on multiple hardware configurations and for hibernation support.

arch/x86/include/asm/kaslr.h extern unsigned long vmalloc_base; · line 13

Quoted 3 lines

void kernel_randomize_memory(void);

arch/x86/include/asm/kaslr.h +2 -0

+void kernel_randomize_smp(void);
+void* kaslr_get_gdt_remap(int cpu);

Yeah, no fundamental objections from me to the principle, but I get some bad vibes from the naming here: seeing that kernel_randomize_smp() actually makes things less random.

Quoted 23 lines · Ingo Molnar

Quoted 17 lines · Thomas Garnier

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE_OFFSET).

In this change, a space is reserved at the end of the memory range available for KASLR memory randomization. The space is big enough to hold the maximum number of CPUs (as defined by setup_max_cpus). Each GDT is mapped at specific offset based on the target CPU. Note that if there is not enough space available, the GDTs are not remapped.

The document was changed to mention GDT remapping for KASLR. This patch also include dump page tables support.

This patch was tested on multiple hardware configurations and for hibernation support.

Quoted 11 lines

arch/x86/include/asm/kaslr.h extern unsigned long vmalloc_base; · line 13

Quoted 3 lines

void kernel_randomize_memory(void);

arch/x86/include/asm/kaslr.h +2 -0

+void kernel_randomize_smp(void);
+void* kaslr_get_gdt_remap(int cpu);

Yeah, no fundamental objections from me to the principle, but I get some bad vibes
from the naming here: seeing that kernel_randomize_smp() actually makes things
less random.

kernel_unrandomize_smp() ...

one request.. can we make sure this unrandomization is optional?

Well, it happens only when KASLR memory randomization is enabled. Do you think it should have a separate config option?

Quoted 3 lines · Thomas Garnier

Well, it happens only when KASLR memory randomization is enabled. Do you think it should have a separate config option?

no I would want it a runtime option.... "sgdt from ring 3" is going away with UMIP (and is already possibly gone in virtual machines, see
https://lwn.net/Articles/694385/) and for those cases it would be a shame to lose the randomization

Quoted 2 lines

kernel_unrandomize_smp() ...

That seems like a better name.

Quoted 4 lines · Thomas Garnier

Quoted 2 lines

kernel_unrandomize_smp() ...

That seems like a better name.

Hardly... I'd call it something like kaslr_load_gdt() to actually say what this function is doing.

--
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Quoted 17 lines · Thomas Garnier

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE_OFFSET).

In this change, a space is reserved at the end of the memory range available for KASLR memory randomization. The space is big enough to hold the maximum number of CPUs (as defined by setup_max_cpus). Each GDT is mapped at specific offset based on the target CPU. Note that if there is not enough space available, the GDTs are not remapped.

The document was changed to mention GDT remapping for KASLR. This patch also include dump page tables support.

This patch was tested on multiple hardware configurations and for hibernation support.

arch/x86/include/asm/kaslr.h extern unsigned long vmalloc_base; · line 13

Quoted 3 lines

void kernel_randomize_memory(void);

arch/x86/include/asm/kaslr.h +2 -0

+void kernel_randomize_smp(void);
+void* kaslr_get_gdt_remap(int cpu);

Yeah, no fundamental objections from me to the principle, but I get some bad vibes from the naming here: seeing that kernel_randomize_smp() actually makes things less random.

Also, don't we want to do this unconditionally and not allow remapping failures?

The GDT is fairly small, plus making the SGDT instruction expose fewer kernel internals would be (marginally) useful on non-randomized kernels as well.

It also makes the code more common, more predictable, more debuggable and less complex overall - which is pretty valuable in terms of long term security as well.

Thanks,

Ingo

Quoted 3 lines

Thanks,

Ingo

Ingo: I saw the 5-level page table support being sent through. Do you want me to wait for it to be -next? (Given it will need to be changed too).

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE_OFFSET).

In this change, a space is reserved at the end of the memory range available for KASLR memory randomization. The space is big enough to hold the maximum number of CPUs (as defined by setup_max_cpus). Each GDT is mapped at specific offset based on the target CPU. Note that if there is not enough space available, the GDTs are not remapped.

Quoted 11 lines · Thomas Garnier

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE_OFFSET).

In this change, a space is reserved at the end of the memory range available for KASLR memory randomization. The space is big enough to hold the maximum number of CPUs (as defined by setup_max_cpus). Each GDT is mapped at specific offset based on the target CPU. Note that if there is not enough space available, the GDTs are not remapped.

Can we remap it read-only? I.e. use PAGE_KERNEL_RO instead of PAGE_KERNEL. After all, the ability to modify the GDT is instant root.

Quoted 13 lines · Andy Lutomirski

Quoted 11 lines · Thomas Garnier

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE_OFFSET).

In this change, a space is reserved at the end of the memory range available for KASLR memory randomization. The space is big enough to hold the maximum number of CPUs (as defined by setup_max_cpus). Each GDT is mapped at specific offset based on the target CPU. Note that if there is not enough space available, the GDTs are not remapped.

Quoted 3 lines

Can we remap it read-only? I.e. use PAGE_KERNEL_RO instead of PAGE_KERNEL. After all, the ability to modify the GDT is instant root.

That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet.

Quoted 14 lines · Thomas Garnier

Quoted 13 lines · Andy Lutomirski

Quoted 11 lines · Thomas Garnier

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE_OFFSET).

In this change, a space is reserved at the end of the memory range available for KASLR memory randomization. The space is big enough to hold the maximum number of CPUs (as defined by setup_max_cpus). Each GDT is mapped at specific offset based on the target CPU. Note that if there is not enough space available, the GDTs are not remapped.

Quoted 8 lines

Quoted 3 lines

Can we remap it read-only? I.e. use PAGE_KERNEL_RO instead of PAGE_KERNEL. After all, the ability to modify the GDT is instant root.

That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet.

If you want a small adventure, I think a significant KVM-related performance improvement is available. Specifically, on VMX exits, the GDT limit is hardwired to 0xffff (IIRC -- I could be remembering the actual vaue wrong). KVM does LGDT to fix it.

If we actually made the GDT have limit 0xffff (presumably by mapping the zero page a few times to pad it out without wasting memory), then we would avoid the LGDT. LGDT is incredibly slow, so this would be a big win. Want to see if you can make this work with your patch set?

That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet.

Quoted 5 lines · Thomas Garnier

That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet.

don't we write to the GDT as part of the TLS segment stuff for glibc ?

Quoted 11 lines · Arjan van de Ven

Quoted 5 lines · Thomas Garnier

That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet.

don't we write to the GDT as part of the TLS segment stuff for glibc ?

Not sure which glibc feature it is.

In this design, you can write to the GDT per-cpu variable that will remain read-write. You just need to make the remapping writeable when we load task registers (ltr) then the processor use the current GDT address. At least that the case I know, I might find more through testing.

Quoted 13 lines · Thomas Garnier

Quoted 11 lines · Arjan van de Ven

Quoted 5 lines · Thomas Garnier

That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet.

don't we write to the GDT as part of the TLS segment stuff for glibc ?

Quoted 7 lines

Not sure which glibc feature it is.

In this design, you can write to the GDT per-cpu variable that will remain read-write. You just need to make the remapping writeable when we load task registers (ltr) then the processor use the current GDT address. At least that the case I know, I might find more through testing.

Hmm. I bet that if we preset the accessed bits in all the segments then we don't need it to be writable in general. But your point about set_thread_area (TLS) is well taken. However, I strongly suspect that we could make set_thread_area unconditionally set the accessed bit and no one would ever notice.

Quoted 22 lines · Andy Lutomirski

Quoted 13 lines · Thomas Garnier

Quoted 11 lines · Arjan van de Ven

Quoted 5 lines · Thomas Garnier

That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet.

don't we write to the GDT as part of the TLS segment stuff for glibc ?

Quoted 7 lines

Not sure which glibc feature it is.

In this design, you can write to the GDT per-cpu variable that will remain read-write. You just need to make the remapping writeable when we load task registers (ltr) then the processor use the current GDT address. At least that the case I know, I might find more through testing.

Quoted 5 lines

Hmm. I bet that if we preset the accessed bits in all the segments then we don't need it to be writable in general. But your point about set_thread_area (TLS) is well taken. However, I strongly suspect that we could make set_thread_area unconditionally set the accessed bit and no one would ever notice.

Not sure I fully understood and I don't want to miss an important point. Do you mean making GDT (remapping and per-cpu) read-only and switch the writeable flag only when we write to the per-cpu entry?

Quoted 29 lines · Thomas Garnier

Quoted 22 lines · Andy Lutomirski

Quoted 13 lines · Thomas Garnier

Quoted 11 lines · Arjan van de Ven

Quoted 5 lines · Thomas Garnier

That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet.

don't we write to the GDT as part of the TLS segment stuff for glibc ?

Quoted 7 lines

Not sure which glibc feature it is.

In this design, you can write to the GDT per-cpu variable that will remain read-write. You just need to make the remapping writeable when we load task registers (ltr) then the processor use the current GDT address. At least that the case I know, I might find more through testing.

Quoted 5 lines

Hmm. I bet that if we preset the accessed bits in all the segments then we don't need it to be writable in general. But your point about set_thread_area (TLS) is well taken. However, I strongly suspect that we could make set_thread_area unconditionally set the accessed bit and no one would ever notice.

Quoted 4 lines

Not sure I fully understood and I don't want to miss an important point. Do you mean making GDT (remapping and per-cpu) read-only and switch the writeable flag only when we write to the per-cpu entry?

What I mean is: write to the GDT through normal percpu access (or whatever the normal mapping is) but load a read-only alias into the GDT register. As long as nothing ever tries to write through the GDTR alias, no page faults will be generated. So we just need to make sure that nothing ever writes to it through GDTR. AFAIK the only reason the CPU ever writes to the address in GDTR is to set an accessed bit.

--Andy

Quoted 4 lines

Quoted 3 lines

Not sure I fully understood and I don't want to miss an important point. Do you mean making GDT (remapping and per-cpu) read-only and switch the writeable flag only when we write to the per-cpu entry?

Quoted 6 lines

What I mean is: write to the GDT through normal percpu access (or whatever the normal mapping is) but load a read-only alias into the GDT register. As long as nothing ever tries to write through the GDTR alias, no page faults will be generated. So we just need to make sure that nothing ever writes to it through GDTR. AFAIK the only reason the CPU ever writes to the address in GDTR is to set an accessed bit.

A write is made when we use load_TR_desc (ltr). I didn't see any other yet.

Quoted 11 lines · Thomas Garnier

Quoted 10 lines

Quoted 3 lines

Not sure I fully understood and I don't want to miss an important point. Do you mean making GDT (remapping and per-cpu) read-only and switch the writeable flag only when we write to the per-cpu entry?

What I mean is: write to the GDT through normal percpu access (or whatever the normal mapping is) but load a read-only alias into the GDT register. As long as nothing ever tries to write through the GDTR alias, no page faults will be generated. So we just need to make sure that nothing ever writes to it through GDTR. AFAIK the only reason the CPU ever writes to the address in GDTR is to set an accessed bit.

Quoted 1 line

A write is made when we use load_TR_desc (ltr). I didn't see any other yet.

Is this write to the GDT, generated by the LTR instruction, done unconditionally by the hardware?

Thanks,

Ingo

Quoted 16 lines · Ingo Molnar

Quoted 12 lines · Thomas Garnier

Quoted 10 lines

Quoted 3 lines

Not sure I fully understood and I don't want to miss an important point. Do you mean making GDT (remapping and per-cpu) read-only and switch the writeable flag only when we write to the per-cpu entry?

What I mean is: write to the GDT through normal percpu access (or whatever the normal mapping is) but load a read-only alias into the GDT register. As long as nothing ever tries to write through the GDTR alias, no page faults will be generated. So we just need to make sure that nothing ever writes to it through GDTR. AFAIK the only reason the CPU ever writes to the address in GDTR is to set an accessed bit.

A write is made when we use load_TR_desc (ltr). I didn't see any other yet.

Quoted 3 lines

Is this write to the GDT, generated by the LTR instruction, done unconditionally by the hardware?

That was my experience. I didn't look into details. Do you think we could change something so that ltr never writes to the GDT? (just mark the TSS entry busy).

Quoted 17 lines · Thomas Garnier

Quoted 16 lines · Ingo Molnar

Quoted 12 lines · Thomas Garnier

Quoted 10 lines

Quoted 3 lines

Not sure I fully understood and I don't want to miss an important point. Do you mean making GDT (remapping and per-cpu) read-only and switch the writeable flag only when we write to the per-cpu entry?

What I mean is: write to the GDT through normal percpu access (or whatever the normal mapping is) but load a read-only alias into the GDT register. As long as nothing ever tries to write through the GDTR alias, no page faults will be generated. So we just need to make sure that nothing ever writes to it through GDTR. AFAIK the only reason the CPU ever writes to the address in GDTR is to set an accessed bit.

A write is made when we use load_TR_desc (ltr). I didn't see any other yet.

Quoted 7 lines

Quoted 3 lines

Is this write to the GDT, generated by the LTR instruction, done unconditionally by the hardware?

That was my experience. I didn't look into details. Do you think we could change something so that ltr never writes to the GDT? (just mark the TSS entry busy).

No, and I had the way this worked on 64-bit wrong. LTR requires an available TSS and changes it to busy. So here are my thoughts on how this should work:

Let's get rid of any connection between this code and KASLR. Every time KASLR makes something work differently, a kitten turns all Schrödinger on us. This is moving the GDT to the fixmap, plain and simple. For now, make it one page per CPU and don't worry about the GDT limit.

On 32-bit, we're going to have to make the fixmap GDT be read-write because making it read-only will break double-fault handling.

On 64-bit, we can use your trick of temporarily mapping the GDT read-write every time we load TR, which should happen very rarely. Alternatively, we can reload the *GDT* every time we reload TR, which should be comparably slow. This is going to regress performance in the extremely rare case where KVM exits to a process that uses ioperm() (I think), but I doubt anyone cares. Or maybe we could arrange to never reload TR when GDT points at the fixmap by having KVM set the host GDT to the direct version and letting KVM's code to reload the GDT switch to the fixmap copy.

If we need a quirk to keep the fixmap copy read-write, so be it.

None of this should depend on KASLR. IMO it should happen unconditionally.

Once all if it works, then we can build on it to allocate four pages per CPU (with the extra three pointing to the zero page) and speeding up KVM.

--Andy

Quoted 30 lines · Andy Lutomirski

Quoted 17 lines · Thomas Garnier

Quoted 16 lines · Ingo Molnar

Quoted 12 lines · Thomas Garnier

Quoted 10 lines

Quoted 3 lines

Not sure I fully understood and I don't want to miss an important point. Do you mean making GDT (remapping and per-cpu) read-only and switch the writeable flag only when we write to the per-cpu entry?

What I mean is: write to the GDT through normal percpu access (or whatever the normal mapping is) but load a read-only alias into the GDT register. As long as nothing ever tries to write through the GDTR alias, no page faults will be generated. So we just need to make sure that nothing ever writes to it through GDTR. AFAIK the only reason the CPU ever writes to the address in GDTR is to set an accessed bit.

A write is made when we use load_TR_desc (ltr). I didn't see any other yet.

Quoted 7 lines

Quoted 3 lines

Is this write to the GDT, generated by the LTR instruction, done unconditionally by the hardware?

That was my experience. I didn't look into details. Do you think we could change something so that ltr never writes to the GDT? (just mark the TSS entry busy).

No, and I had the way this worked on 64-bit wrong. LTR requires an available TSS and changes it to busy. So here are my thoughts on how this should work:

Quoted 5 lines

Let's get rid of any connection between this code and KASLR. Every time KASLR makes something work differently, a kitten turns all Schrödinger on us. This is moving the GDT to the fixmap, plain and simple. For now, make it one page per CPU and don't worry about the GDT limit.

I am all for this change but that's more significant.

Ingo: What do you think about that?

Quoted 14 lines

On 32-bit, we're going to have to make the fixmap GDT be read-write because making it read-only will break double-fault handling.

On 64-bit, we can use your trick of temporarily mapping the GDT read-write every time we load TR, which should happen very rarely. Alternatively, we can reload the *GDT* every time we reload TR, which should be comparably slow. This is going to regress performance in the extremely rare case where KVM exits to a process that uses ioperm() (I think), but I doubt anyone cares. Or maybe we could arrange to never reload TR when GDT points at the fixmap by having KVM set the host GDT to the direct version and letting KVM's code to reload the GDT switch to the fixmap copy.

Quoted 4 lines

If we need a quirk to keep the fixmap copy read-write, so be it.

None of this should depend on KASLR. IMO it should happen unconditionally.

I looked back at the fixmap, and I can see a way it could be done (using NR_CPUS) like the other fixmap ranges. It would limit the number of cpus to 512 (there is 2M memory left on fixmap on the default configuration). That's if we never add any other fixmap on x64. I don't know if it is an acceptable number and if the fixmap region could be increased. (128 if we do your kvm trick, of course).

Quoted 6 lines

I looked back at the fixmap, and I can see a way it could be done (using NR_CPUS) like the other fixmap ranges. It would limit the number of cpus to 512 (there is 2M memory left on fixmap on the default configuration). That's if we never add any other fixmap on x64. I don't know if it is an acceptable number and if the fixmap region could be increased. (128 if we do your kvm trick, of course).

IIRC we need 4096 CPUs.

P.S. Let's do the move to the fixmap, read/write as a separate patch. That will make bisecting much easier.

Quoted 2 lines · Andy Lutomirski

P.S. Let's do the move to the fixmap, read/write as a separate patch. That will make bisecting much easier.

Absolutely, but this has to be within the same series, as the interim fixmap-only step is less secure in some circumstances: we are moving the writable GDT from a previously randomized location to a fixed location.

Quoted 9 lines

No, and I had the way this worked on 64-bit wrong. LTR requires an available TSS and changes it to busy. So here are my thoughts on how this should work:

Let's get rid of any connection between this code and KASLR. Every time KASLR makes something work differently, a kitten turns all Schrödinger on us. This is moving the GDT to the fixmap, plain and simple. For now, make it one page per CPU and don't worry about the GDT limit.

I am all for this change but that's more significant.

Ingo: What do you think about that?

Quoted 11 lines

On 32-bit, we're going to have to make the fixmap GDT be read-write because making it read-only will break double-fault handling.

On 64-bit, we can use your trick of temporarily mapping the GDT read-write every time we load TR, which should happen very rarely. Alternatively, we can reload the *GDT* every time we reload TR, which should be comparably slow. This is going to regress performance in the extremely rare case where KVM exits to a process that uses ioperm() (I think), but I doubt anyone cares. Or maybe we could arrange to never reload TR when GDT points at the fixmap by having KVM set the host GDT to the direct version and letting KVM's code to reload the GDT switch to the fixmap copy.

Quoted 3 lines

If we need a quirk to keep the fixmap copy read-write, so be it.

None of this should depend on KASLR. IMO it should happen unconditionally.

I looked back at the fixmap, and I can see a way it could be done (using NR_CPUS) like the other fixmap ranges. It would limit the number of cpus to 512 (there is 2M memory left on fixmap on the default configuration). That's if we never add any other fixmap on x64. I don't know if it is an acceptable number and if the fixmap region could be increased. (128 if we do your kvm trick, of course).

Ingo: What do you think?

Quoted 10 lines · Thomas Garnier

Quoted 9 lines

No, and I had the way this worked on 64-bit wrong. LTR requires an available TSS and changes it to busy. So here are my thoughts on how this should work:

Let's get rid of any connection between this code and KASLR. Every time KASLR makes something work differently, a kitten turns all Schrödinger on us. This is moving the GDT to the fixmap, plain and simple. For now, make it one page per CPU and don't worry about the GDT limit.

Quoted 3 lines

I am all for this change but that's more significant.

Ingo: What do you think about that?

I agree with Andy: as I alluded to earlier as well this should be an unconditional change (tested properly, etc.) that robustifies the GDT mapping for everyone. That KASLR kernels improve too is a happy side effect!

Quoted 11 lines

Quoted 11 lines

On 32-bit, we're going to have to make the fixmap GDT be read-write because making it read-only will break double-fault handling.

On 64-bit, we can use your trick of temporarily mapping the GDT read-write every time we load TR, which should happen very rarely. Alternatively, we can reload the *GDT* every time we reload TR, which should be comparably slow. This is going to regress performance in the extremely rare case where KVM exits to a process that uses ioperm() (I think), but I doubt anyone cares. Or maybe we could arrange to never reload TR when GDT points at the fixmap by having KVM set the host GDT to the direct version and letting KVM's code to reload the GDT switch to the fixmap copy.

Please check whether the LTR write generates a page fault to a RO PTE even if the busy bit is already set. LTR is pretty slow which suggests that it's microcode, and microcode is usually not sloppy about such things: i.e. LTR would only generate an unconditional write if there's a compatibility dependency on it. But I could easily be wrong ...

Quoted 12 lines

Quoted 4 lines

If we need a quirk to keep the fixmap copy read-write, so be it.

None of this should depend on KASLR. IMO it should happen unconditionally.

I looked back at the fixmap, and I can see a way it could be done (using NR_CPUS) like the other fixmap ranges. It would limit the number of cpus to 512 (there is 2M memory left on fixmap on the default configuration). That's if we never add any other fixmap on x64. I don't know if it is an acceptable number and if the fixmap region could be increased. (128 if we do your kvm trick, of course).

Quoted 1 line

Ingo: What do you think?

I think we should scale the fixmap size flexibly with NR_CPUs on 64-bit, and we should limit CPUs on 32-bit to a reasonable value.

Quoted 10 lines · Thomas Garnier

Quoted 9 lines

No, and I had the way this worked on 64-bit wrong. LTR requires an available TSS and changes it to busy. So here are my thoughts on how this should work:

Let's get rid of any connection between this code and KASLR. Every time KASLR makes something work differently, a kitten turns all Schrödinger on us. This is moving the GDT to the fixmap, plain and simple. For now, make it one page per CPU and don't worry about the GDT limit.

Quoted 3 lines

I am all for this change but that's more significant.

Ingo: What do you think about that?

I agree with Andy: as I alluded to earlier as well this should be an unconditional change (tested properly, etc.) that robustifies the GDT mapping for everyone. That KASLR kernels improve too is a happy side effect!

Quoted 11 lines

Quoted 11 lines

On 32-bit, we're going to have to make the fixmap GDT be read-write because making it read-only will break double-fault handling.

On 64-bit, we can use your trick of temporarily mapping the GDT read-write every time we load TR, which should happen very rarely. Alternatively, we can reload the *GDT* every time we reload TR, which should be comparably slow. This is going to regress performance in the extremely rare case where KVM exits to a process that uses ioperm() (I think), but I doubt anyone cares. Or maybe we could arrange to never reload TR when GDT points at the fixmap by having KVM set the host GDT to the direct version and letting KVM's code to reload the GDT switch to the fixmap copy.

Please check whether the LTR write generates a page fault to a RO PTE even if the busy bit is already set. LTR is pretty slow which suggests that it's microcode, and microcode is usually not sloppy about such things: i.e. LTR would only generate an unconditional write if there's a compatibility dependency on it. But I could easily be wrong ...

Quoted 4 lines

Quoted 3 lines

If we need a quirk to keep the fixmap copy read-write, so be it.

None of this should depend on KASLR. IMO it should happen unconditionally.

Quoted 8 lines

I looked back at the fixmap, and I can see a way it could be done (using NR_CPUS) like the other fixmap ranges. It would limit the number of cpus to 512 (there is 2M memory left on fixmap on the default configuration). That's if we never add any other fixmap on x64. I don't know if it is an acceptable number and if the fixmap region could be increased. (128 if we do your kvm trick, of course).

Ingo: What do you think?

I think we should scale the fixmap size flexibly with NR_CPUs on 64-bit, and we should limit CPUs on 32-bit to a reasonable value.

I.e. let's just do it, if we run into problems it's all solvable AFAICS.

Thanks,

Ingo

Coming back on that after a bit more testing. The LTR instruction check if the busy bit is already set, if already set then it will just issue a #GP given a bad selector:

[    0.000000] general protection fault: 0040 [#1] SMP
...
[    0.000000] RIP: 0010:native_load_tr_desc+0x9/0x10
...
[    0.000000] Call Trace:
[    0.000000]  cpu_init+0x2d0/0x3c0
[    0.000000]  trap_init+0x2a2/0x312
[    0.000000]  start_kernel+0x1fb/0x43b
[    0.000000]  ? set_init_arg+0x55/0x55
[    0.000000]  ? early_idt_handler_array+0x120/0x120
[    0.000000]  x86_64_start_reservations+0x2a/0x2c
[    0.000000]  x86_64_start_kernel+0x13d/0x14c
[    0.000000]  start_cpu+0x14/0x14

I assume that's in this part of the pseudo-code:

if(!IsWithinDescriptorTableLimit(Source.Offset) || Source.Type != TypeGlobal) Exception(GP(SegmentSelector)); SegmentDescriptor = ReadSegmentDescriptor(); if(!IsForAnAvailableTSS(SegmentDescriptor)) Exception(GP(SegmentSelector)); <---- That's where I got the GP TSSSegmentDescriptor.Busy = 1; <------------------------------------------------------------------ That's the pagefault I get otherwise
//Locked read-modify-write operation on the entire descriptor when setting busy flag
TaskRegister.SegmentSelector = Source; TaskRegister.SegmentDescriptor.TSSSegmentDescriptor;

I assume the best option would be to make the remap read-write for the LTR instruction. What do you think?

Quoted 33 lines · Thomas Garnier

Coming back on that after a bit more testing. The LTR instruction check if the busy bit is already set, if already set then it will just issue a #GP given a bad selector:

[    0.000000] general protection fault: 0040 [#1] SMP
...
[    0.000000] RIP: 0010:native_load_tr_desc+0x9/0x10
...
[    0.000000] Call Trace:
[    0.000000]  cpu_init+0x2d0/0x3c0
[    0.000000]  trap_init+0x2a2/0x312
[    0.000000]  start_kernel+0x1fb/0x43b
[    0.000000]  ? set_init_arg+0x55/0x55
[    0.000000]  ? early_idt_handler_array+0x120/0x120
[    0.000000]  x86_64_start_reservations+0x2a/0x2c
[    0.000000]  x86_64_start_kernel+0x13d/0x14c
[    0.000000]  start_cpu+0x14/0x14

I assume that's in this part of the pseudo-code:

if(!IsWithinDescriptorTableLimit(Source.Offset) || Source.Type != TypeGlobal) Exception(GP(SegmentSelector)); SegmentDescriptor = ReadSegmentDescriptor(); if(!IsForAnAvailableTSS(SegmentDescriptor)) Exception(GP(SegmentSelector)); <---- That's where I got the GP TSSSegmentDescriptor.Busy = 1; <------------------------------------------------------------------ That's the pagefault I get otherwise
//Locked read-modify-write operation on the entire descriptor when setting busy flag
TaskRegister.SegmentSelector = Source; TaskRegister.SegmentDescriptor.TSSSegmentDescriptor;

Quoted 2 lines

I assume the best option would be to make the remap read-write for the LTR instruction. What do you think?

So if LTR does not modify the GDT if the busy bit is already set, why don't we set the busy bit in the descriptor (via the linear mapping rw alias).

Then the remapped GDT can stay read-only all the time and LTR won't fault.

Am I missing something here?

Thanks,

Ingo

Hmm. I bet that if we preset the accessed bits in all the segments then we don't need it to be writable in general.

Quoted 3 lines · Andy Lutomirski

Hmm. I bet that if we preset the accessed bits in all the segments then we don't need it to be writable in general.

I'm not sure that this is architecturally safe.

IIRC, we do mark the IDT read-only - but that one we started doing due to the f00f bug, so we knew it was ok. I'm not sure you can do the same with the GDT/LDT.

Linus

Quoted 3 lines · Andy Lutomirski

Hmm. I bet that if we preset the accessed bits in all the segments then we don't need it to be writable in general.

I'm not sure that this is architecturally safe.

Quoted 7 lines · Linus Torvalds

Quoted 3 lines · Andy Lutomirski

Hmm. I bet that if we preset the accessed bits in all the segments then we don't need it to be writable in general.

I'm not sure that this is architecturally safe.

Hmm. Last time I looked, I couldn't find *anything* in the SDM explaining what happened if a GDT access resulted in a page fault. I did discover that Xen intentionally (!) lazily populates and maps LDT pages. An attempt to access a not-present page results in #PF with the error cod e indicating kernel access even if the access came from user mode.

SDM volume 3 7.2.2 says "Pages corresponding to the previous task’s TSS, the current task’s TSS, and the descriptor table entries for each all should be marked as read/write." But I don't see how a CPU implementation could possibly care what the page table for the TSS descriptor table entries says after LTR is done because the CPU isn't even supposed to *read* that memory.

OTOH a valid implementation could easily require that the page table says that the page is writable merely to load a segment, especially in weird cases (IRET?). That being said, this is all quite easy to test.

Also, Thomas, why are you creating a new memory region? I don't see any benefit to randomizing the GDT address. How about just putting it in the fixmap? This would be NR_CPUS * 4 pages if do my limit=0xffff idea. I'm not sure if the fixmap code knows how to handle this much space.

Quoted 28 lines · Andy Lutomirski

Quoted 7 lines · Linus Torvalds

Quoted 3 lines · Andy Lutomirski

Hmm. I bet that if we preset the accessed bits in all the segments then we don't need it to be writable in general.

I'm not sure that this is architecturally safe.

Hmm. Last time I looked, I couldn't find *anything* in the SDM explaining what happened if a GDT access resulted in a page fault. I did discover that Xen intentionally (!) lazily populates and maps LDT pages. An attempt to access a not-present page results in #PF with the error cod e indicating kernel access even if the access came from user mode.

SDM volume 3 7.2.2 says "Pages corresponding to the previous task’s TSS, the current task’s TSS, and the descriptor table entries for each all should be marked as read/write." But I don't see how a CPU implementation could possibly care what the page table for the TSS descriptor table entries says after LTR is done because the CPU isn't even supposed to *read* that memory.

OTOH a valid implementation could easily require that the page table says that the page is writable merely to load a segment, especially in weird cases (IRET?). That being said, this is all quite easy to test.

Quoted 5 lines

Also, Thomas, why are you creating a new memory region? I don't see any benefit to randomizing the GDT address. How about just putting it in the fixmap? This would be NR_CPUS * 4 pages if do my limit=0xffff idea. I'm not sure if the fixmap code knows how to handle this much space.

When I looked at the fixmap, you had to define the space you need ahead of time and I am not sure there was enough space as you said.

Quoted 2 lines

When I looked at the fixmap, you had to define the space you need ahead of time and I am not sure there was enough space as you said.

Can you try it and see if anything goes wrong? Even if something does go wrong, I think we should fix *that* rather than making the memory layout more complicated.

Quoted 3 lines · Thomas Garnier

That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet.

don't we write to the GDT as part of the TLS segment stuff for glibc ?