40

Because of the current Intel CPU security hole issue, there is a patch expected which slows down the system performance.

How can I make sure that this patch will not be installed on my Ubuntu system?

  • 49
    You can increase your system performance even further by disabling various other security mechanisms. No, that's not a recommendation. – scai Jan 3 '18 at 15:28
  • 11
    If performance matters to you, I recommend building the recent kernel release candidate yourself and testing the performance loss on your workload. You may well find the overhead is negligible or tolerable. – Jeffrey Bosboom Jan 4 '18 at 1:46
  • 5
    I can't overstate just how terrible of an idea this is. – Alexander Jan 5 '18 at 4:22
  • 12
    I am going to dissent . Personally I would not advise disabling security features, but, for users who notice a performance hit disabling pti may be a reasonable option considering how difficult it may be to leverage an attack against this particular security hole and the value of the target computer / data. The question is how to disable this option not should I disable this option. – Panther Jan 8 '18 at 16:13
  • 2
    I agree, PTI is a security feature that can have a non-negligible cost. Its up to OP to decide if it is right for them and outside the scope of this question. – Jake Jan 11 '18 at 20:37
54

The patch (aka "Page table isolation") will be part of a normal kernel update (which you'll get when you update your system). However, keeping the kernel up to date is highly recommended, as it also gets a lot of other security fixes. So I would not recommend just using an outdated kernel without the fix.

However, you can effectively disable the patch by adding pti=off (kernel patch adding this option, with more info) to your kernel command line (howto). Note that doing this will result in a less secure system.

There's more info and performance tests with PTI enabled and disabled on the PostgreSQL mailing list - TLDR is that it has a between 10 and 30% performance impact (For ProstgreSQL, that is - other things such as games will probably see less of an impact).

Note that this will only affect Intel processors, as AMD is apparently unaffected (reddit), so this will foreseeably be disabled by default on AMD.

  • 2
    "... this will foreseeable be disabled by default on AMD." Does that mean that there will be an extra kernel version for Ubuntu operating systems running on machines with an AMD CPU provided by Canonical ? :) – cl-netbox Jan 3 '18 at 15:32
  • 16
    No, the kernel detects (on bootup) weather it's running on an AMD CPU, and disables the fix if it is. @cl-netbox – JonasCz Jan 3 '18 at 15:36
  • 1
    According to theregister.co.uk/2018/01/04/intel_amd_arm_cpu_vulnerability AMD chips are affected by at least one variety of Spectre attacks (branch target injection), so they'll be getting a probably-performance-affecting kernel update this week, too, even though they're not subject to Meltdown proper. – Dave Sherohman Jan 4 '18 at 13:32
  • 1
    Apparently this feature is in x64 architecture, but not in i386/IA-32.because of this, the patch doesn't affect 32bit linux either(security/Kconfig requires X86_64 to enable PAGE_TABLE_ISOLATION). that brings another question though. what about x64 machines with a 32bit linux installed, can these be affected? If so, what about old x64 machines which are limited by bios to only run 32bit instructions(like old atom-based netbooks)? are they sitting ducks? – thePiGrepper Jan 4 '18 at 21:16
  • 2
    Until I learned for certain there was a JavaScript based attack I was planning on using this. – Joshua Jan 5 '18 at 4:21
35

Update: The issue has been given a pair of monikers: Meltdown and Spectre. I've updated the answer with the new information.

It'll be a kernel patch initially. It'll show up as a higher version. It'll be installed because you have linux-image-generic installed. That's what that package is for. So you could remove linux-image-generic. It's a horrible, disastrous idea, that'll expose you to all sorts of nasties but you could do it. There may also be CPU microcode that follows in linux-firmware for an in-CPU fix. That's really on Intel.

The method you follow to un-fix this is irrelevant. You're asking to bypass something where you know neither the true impact of the bug, nor the performance cost of fixing it.

  • The bug is nasty. The reported CVEs are cross process memory reading. Any process being able to read the memory of any other process. Input, passwords, the whole lot. This likely has implications on sandboxes too. It's very early days and I expect people to push this further, both in impact and access.

  • The performance hit likely isn't as big as you're worried about. The numbers people are throwing around focus on the theoretical subsystem performance, or worst case. A poorly cached database is what's going to get hit hardest. Gaming, and day-to-day stuff likely isn't going to measurably change.

Even now we can see what the actual bug is, it's way too early to say what the impact is. While free read access to RAM is bad, there are worse things out there. I'd also test to see how much the fix actually impacts you (with the things you do).

Don't start pre-loading your GRUB config with flags, or removing Kernel meta packages just yet.

  • 7
    All you need to do is add pti=off to the kernel command line (in GRUB) to disable the patch. – JonasCz Jan 3 '18 at 14:34
  • 3
    @JonasCz that comment - if true, I don't know - sounds like it would be worth a separate answer, especially if you can back it up with a reference. – Byte Commander Jan 3 '18 at 14:43
  • IMHO nopti is a better choice – Panther Jan 8 '18 at 13:52
  • 3
    @Oli I agree with that advice and have given such myself elsewhere. With that said, the question is how to disable this new security feature if desired, and, IMO, nopti is the option to do so. – Panther Jan 8 '18 at 15:08
  • 1
    Yeah it has slowed some of my system activities down 99% when using virtual machines. Copying files from host to virtual machine used to take 2-3 seconds now it takes over a minute. – rboy Jan 9 '18 at 16:57
13

Although I do not recommend this, it is possible to disable PTI

with the nopti kernel command-line parameter

according to Phoronix.

To do this, append nopti to the string next to the line that starts with GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and then running

sudo update-grub

followed by a restart.

More about kernel boot parameters to disable performance-relevant security features, see: Spectre&Meltdown MitigationControls in Ubuntu Wiki

4

Add the following to the end of your kernel argument in grub:-

spectre_v2=off nopti pti=off

Kernel parameters are described at: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/MitigationControls

3

Simplest way: uncheck in kernel configuration

->Security options

[ ] Remove the kernel mapping in user mode

then compile the new kernel

  • 1
    Welcome to Ask Ubuntu! In its current form your answer is not as good as it could be. Could you review How to Write a Good Answer, and Style guide for questions and answers. - From Review – J. Starnes Jan 4 '18 at 5:01
  • 2
    Sadly J. Starnes is right. You don't compile your own kernel anymore except as an extreme last resort. – Joshua Jan 5 '18 at 4:23
  • That is a rather trivial change to the kernel options, but, IMO nopti is probably a better / easier choice fo rmost. – Panther Jan 8 '18 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.