Messages in this thread | | | Subject | Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch) | From | Yisheng Xie <> | Date | Fri, 5 Jan 2018 14:16:38 +0800 |
| |
Hi Dave,
On 2018/1/5 13:18, Dave Hansen wrote: > On 01/04/2018 08:16 PM, Yisheng Xie wrote: >>> === Page Table Poisoning === >>> >>> KAISER has two copies of the page tables: one for the kernel and >>> one for when running in userspace. >> >> So, we have 2 page table, thinking about this case: >> If _ONE_ process includes _TWO_ threads, one run in user space, the other >> run in kernel, they can run in one core with Hyper-Threading, right? > > Yes. > >> So both userspace and kernel space is valid, right? And for one core >> with Hyper-Threading, they may share TLB, so the timing problem >> described in the paper may still exist? > > No. The TLB is managed per logical CPU (hyperthread), as is the CR3 > register that points to the page tables. Two threads running the same > process might use the same CR3 _value_, but that does not mean they > share TLB entries.
Get it, and thanks for your explain.
BTW, we have just reported a bug caused by kaiser[1], which looks like caused by SMEP. Could you please help to have a look?
[1] https://lkml.org/lkml/2018/1/5/3
Thanks Yisheng
> > One thread *can* be in the kernel with the kernel page tables while the > other is in userspace with the user page tables active. They will even > use a different PCID/ASID for the same page tables normally. > >> Can this case still be protected by KAISER? > > Yes. > > . >
| |