lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3a092361-58b8-9c99-01e6-a0bab01ac6b0@linux.intel.com>
Date:   Mon, 18 Dec 2017 17:13:35 -0800
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org
Cc:     x86@...nel.org, moritz.lipp@...k.tugraz.at,
        daniel.gruss@...k.tugraz.at, michael.schwarz@...k.tugraz.at,
        richard.fellner@...dent.tugraz.at, luto@...nel.org,
        torvalds@...ux-foundation.org, keescook@...gle.com,
        hughd@...gle.com
Subject: Re: [PATCH] x86/doc: add PTI description


>> +copy of the page tables which are used only when running userspace
>> +applications.  When the kernel is entered via syscalls, interrupts or
>> +exceptions, page tables are switched to the full "kernel" copy.  When
>> +the system switches back to user mode, the user copy is used again.
> 
> Uh, can userspace on one CPU attempt to observe kernelspace on the processor
> that is running kernel code?  I haven't read any of the published papers,
> so maybe I'm out in the woods here...

The paper basically shows how unprivileged userspace can figure out
where the kernel is located in memory, despite that location being random.

It's not observing another process or the kernel *running*.  It's just
finding where it *is*.

>> +When PTI is enabled, the kernel manages two sets of page
>> +tables.  The first copy is very similar to what would be present
>> +for a kernel without PTI.  This includes a complete mapping of
>> +userspace that the kernel can use for things like copy_to_user().
>> +
>> +The userspace copy is used when running userspace and mirrors the
>> +mapping of userspace present in the kernel copy.  It maps a only
>> +the kernel data needed to enter and exit the kernel.  This data
>> +is entirely contained in the 'struct cpu_entry_area' structure
>> +which is placed in the fixmap and thus each CPU's copy of the
>> +area has a compile-time-fixed virtual address.
> 
> Is that last sentence supposed to be a good thing?  Doesn't sound it
> to me...

It's a good thing, generally.  It makes it easy for a CPU to locate
*its* data.

>> +  g. On systems without PCID support, each CR3 write flushes
>> +     the entire TLB.  That means that each syscall, interrupt
>> +     or exception flushes the TLB.
> 
> Does this imply that PTI is best suited to CPUs that have PCID?

Yes, the performance properties are much less onerous on systems with PCID.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ