12

Assume the following:

  • macOS (but not sure that matters that much)

  • workstation, mostly gets new executables from the app store or open source repos through macports homebrew

  • fair bit of loading JS, Python and Ruby scripts, again from repos. (the Python and JS repos are NOT very well vetted but neither are they very good candidates for low-level hacks from this vuln as far as I understand)

  • assuming also online Javascript can't be leveraged to exploit this.

  • 6 yr old CPU, so assuming on the higher end of the KPTI workaround loss of 30% and no vendor warranty.

I totally get that being able to bypass the ASLR and the like is bad news. And maybe a privilege escalation if a rogue program is capable of escalating itself.

But...

If I am careful downloading programs from mostly trusted sources

Can I avoid taking that 30% hit, by not patching, at not too great a risk? If I have a rogue malware running on my system, that's already most of the security gone, regardless of this particular vuln.

Things would look very different from the POV of a cloud service provider who by definition runs all sorts of unknown programs. Or to someone running arbitrary code in VMs and relying on their protection.

I also realize that, once the OS vendor patches this, then I will have to patch Meltdown anyway to access future vendor patches, so reasoning on the basis of solely Meltdown is short-sighted.

Which means I suspect the answer will be No, you'll have to patch sooner or later.

7
  • 6
    "6 yr old CPU, so assuming on the higher end of the KPTI workaround loss of 30% and no vendor warranty" - is your load really that heavy on system calls that you will reach this estimated maximum of performance loss? While you might get a large loss with application stressing I/O or network you will not get really a loss on applications which primarily do computing or use the GPU. Jan 4, 2018 at 9:03
  • 5
    "assuming also online Javascript can't be leveraged to exploit this." why do you assume that?
    – n00b
    Jan 4, 2018 at 14:21
  • @n00b - this is a developing story here, we don't know all that much. the 30% hit is uncertain as well. JS is normally pretty sandboxed by the browser and not all that capable at low level memory stuff. plus, I run NoScript with very little white listing. I am not saying JS isn't dangerous for Meltdown, but my question flies out the window if it turns out to be - browser JS is the very definition of code you know nothing about. which would still leave my with npm to worry about too. Jan 4, 2018 at 21:50
  • On a Workstation, even the 30% worst case scenario is not actually meaningful; workstations are overpowered either way. I'm voting to close this question as opinion based, yet I go for a strong "security is more important than performance".
    – Tobi Nary
    Jan 5, 2018 at 9:50
  • The 30% number is from a test specifically designed to exercise the worst-case scenario: a program making numerous small accesses to a fast solid-state drive. Unless you're running a heavily-loaded database on your workstation, you're not going to hit this level.
    – Mark
    Jan 9, 2018 at 4:48

1 Answer 1

2

No, you'll have to patch sooner or later.

More seriously, for a workstation-style machine, Meltdown is mostly a concern in the case of malware or existing compromise. (In that it will allow reading kernel memory and consequent privilege escalation.) The media have made a lot of noise about Meltdown (somewhat rightly so: for hosting companies, virtual machine hosting, etc., it's quite a big deal) but your average user is unlikely to be affected by meltdown on their workstation.

That being said -- you're unlikely to see a 30% hit. Most benchmarks of typical workloads show more like a few percentage. As you point out, you'll either have to never get any more updates or eventually accept the performance hit. (Unless OS X adds a flag like the Linux kernel has to turn KPTI off.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .