Re: page table isolation alternative mechanism
On Wed, 3 Jan 2018 14:22:37 -0500 Albert Cahalanwrote: > We got into the current situation for performance reasons, avoiding the costly > reload of CR3 that a hardware task switch would cause. It seems we'll be > loading CR3 now anyway, so it might be time to reconsider hardware > task switches. > > The recent patches leave kernel entry/exit code mapped. Hardware task switches > wouldn't need that. All they need is a single entry in a reduced-size > IDT, for the > doublefault, and a minimal GDT, and a TSS. Taking the fault switches CR3. That > then gets you a proper IDT and GDT because those are virtually mapped. > Not a single byte of kernel code would need to be mapped while user code runs. I can see how that works for 32bit assuming you don't set up the fast syscall/ret stuff but for 64bit I don't see how you'd make it work easily because a syscall isn't an interrupt or trap any more so it can't be a task or any other kind of gate. Alan
Re: page table isolation alternative mechanism
On Wed, 3 Jan 2018 14:22:37 -0500 Albert Cahalan wrote: > We got into the current situation for performance reasons, avoiding the costly > reload of CR3 that a hardware task switch would cause. It seems we'll be > loading CR3 now anyway, so it might be time to reconsider hardware > task switches. > > The recent patches leave kernel entry/exit code mapped. Hardware task switches > wouldn't need that. All they need is a single entry in a reduced-size > IDT, for the > doublefault, and a minimal GDT, and a TSS. Taking the fault switches CR3. That > then gets you a proper IDT and GDT because those are virtually mapped. > Not a single byte of kernel code would need to be mapped while user code runs. I can see how that works for 32bit assuming you don't set up the fast syscall/ret stuff but for 64bit I don't see how you'd make it work easily because a syscall isn't an interrupt or trap any more so it can't be a task or any other kind of gate. Alan
page table isolation alternative mechanism
We got into the current situation for performance reasons, avoiding the costly reload of CR3 that a hardware task switch would cause. It seems we'll be loading CR3 now anyway, so it might be time to reconsider hardware task switches. The recent patches leave kernel entry/exit code mapped. Hardware task switches wouldn't need that. All they need is a single entry in a reduced-size IDT, for the doublefault, and a minimal GDT, and a TSS. Taking the fault switches CR3. That then gets you a proper IDT and GDT because those are virtually mapped. Not a single byte of kernel code would need to be mapped while user code runs.
page table isolation alternative mechanism
We got into the current situation for performance reasons, avoiding the costly reload of CR3 that a hardware task switch would cause. It seems we'll be loading CR3 now anyway, so it might be time to reconsider hardware task switches. The recent patches leave kernel entry/exit code mapped. Hardware task switches wouldn't need that. All they need is a single entry in a reduced-size IDT, for the doublefault, and a minimal GDT, and a TSS. Taking the fault switches CR3. That then gets you a proper IDT and GDT because those are virtually mapped. Not a single byte of kernel code would need to be mapped while user code runs.