[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93776eb2-b6d4-679a-280c-8ba558a69c34@linux.intel.com>
Date: Thu, 4 Jan 2018 21:18:02 -0800
From: Dave Hansen <dave.hansen@...ux.intel.com>
To: Yisheng Xie <xieyisheng1@...wei.com>, linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, richard.fellner@...dent.tugraz.at,
moritz.lipp@...k.tugraz.at, daniel.gruss@...k.tugraz.at,
michael.schwarz@...k.tugraz.at, luto@...nel.org,
torvalds@...ux-foundation.org, keescook@...gle.com,
hughd@...gle.com, x86@...nel.org
Subject: Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page
tables (core patch)
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.
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.
Powered by blists - more mailing lists