
<html><br />On Friday, January 5, 2018 19:26 CET, Larry Finger <Larry.Finger@lwfinger.net> wrote:<br /> <blockquote type="cite" cite="ad7c94cb-6a9b-25dd-1f2c-bc41785f7463@lwfinger.net">More information concerning the Linux implementation for mitigation of Meltdown<br />is available. The info below is copied from https://lkml.org/lkml/2018/1/4/775.<br /><br />Sorting through the jargon, your mileage will vary depending on what features<br />are found on your CPU.<br /><br />A new kernel parameter is available called "pti" for Page Table Isolation. User<br />and kernel space will use separate page tables to prevent any user process from<br />using the side-channel approach. There will be a small performance hit and some<br />memory increases. The feature can be turned off at build or run time, and will<br />automatically be turned off for AMD processors.<br /><br />The details of increased memory usage are as follows:<br /><br />a. Each process now needs an order-1 page directory (PGD) instead of order-0.<br />(Consumes 4k per process).<br /><br />b. The 'cpu_entry_area' structure must be 2MB in size and 2MB aligned so that it<br />can be mapped by setting a single Page Mid Directory (PMD) entry. This consumes<br />nearly 2MB of RAM once the kernel is decompressed, but no space in the kernel<br />image itself.<br /><br />The details of CPU usage:<br /><br />a. CR3 manipulation to switch between the page table copies<br />must be done at interrupt, syscall, and exception entry<br />and exit (it can be skipped when the kernel is interrupted,<br />though.) Moves to CR3 are on the order of a hundred<br />cycles, and are required every at entry and every at exit.<br />b. A "trampoline" must be used for SYSCALL entry. This<br />trampoline depends on a smaller set of resources than the<br />non-PTI SYSCALL entry code, so requires mapping fewer<br />things into the userspace page tables. The downside is<br />that stacks must be switched at entry time.<br />c. Global pages are disabled for all kernel structures not<br />mapped in both to kernel and userspace page tables. This<br />feature of the MMU allows different processes to share TLB<br />entries mapping the kernel. Losing the feature means more<br />TLB misses after a context switch. The actual loss of<br />performance is very small, however, never exceeding 1%.<br />d. Process Context IDentifiers (PCID) is a CPU feature that<br />allows us to skip flushing the entire TLB when switching page<br />tables. This makes switching the page tables (at context<br />switch, or kernel entry/exit) cheaper. But, on systems with<br />PCID support, the context switch code must flush both the user<br />and kernel entries out of the TLB. The user PCID TLB flush is<br />deferred until the exit to userspace, minimizing the cost.<br />e. The userspace page tables must be populated for each new<br />process. Even without PTI, the shared kernel mappings<br />are created by copying top-level (PGD) entries into each<br />new process. But, with PTI, there are now *two* kernel<br />mappings: one in the kernel page tables that maps everything<br />and one for the entry/exit structures. At fork(), we need to<br />copy both.<br />f. In addition to the fork()-time copying, there must also<br />be an update to the userspace PGD any time a set_pgd() is done<br />on a PGD used to map userspace. This ensures that the kernel<br />and userspace copies always map the same userspace<br />memory.<br />g. On systems without PCID support, each CR3 write flushes<br />the entire TLB. That means that each syscall, interrupt<br />or exception flushes the TLB.<br /><br />Larry<br /><br />_______________________________________________<br />mythtv-users mailing list<br />mythtv-users@mythtv.org<br />http://lists.mythtv.org/mailman/listinfo/mythtv-users<br />http://wiki.mythtv.org/Mailing_List_etiquette<br />MythTV Forums: https://forum.mythtv.org</blockquote>Hi again,<br /><br />In layman's terms, does this mean that we can, by using the boot-time kernel parameter "pti=disable" disable all the additional security (and potential system-overhead) in systems which we do not think are vulnerable?<br /><br /><br />Some of us are running mythtv on a minimum of hardware and would rather not take the hit.<br /><br />BR.<br /><br />--Marius--<br /><br /><br /> </html>