If you’re on the bleeding edge of DragonFly and already updated for Meltdown fixes, there’s a few more commits you’ll want to get.
Matthew Dillon wrote a summary of the current status, noting there’s not much you can do for Spectre beyond new hardware. There is an update to the “defensive browser setup” plan for DragonFly (using –site-per-process) that can help at least with Javascript versions of Spectre.
Update: step-by-step microcode fixes from Intel if you really want to trash your performance.
Honest question: unless youre hosting your server on a shared VM environment (eg AWS, Azure, etc) – should we even care about apply the spectre / meltdown patch?
If I either host all my server on my own hardware or I host on baremetal, seems like I should really worry about apply these patches
Yes. Because all it takes is a bit of rogue javascript via a browser to be compromised
I understand the issues with JavaScript on the desktop, why would anyone be running rogue JavaScript or any other untrusted code on a server?
Even so, would it be possible to allow trusted user-space processes to enjoy fast system calls and only enable meltdown mitigation for processes running untrusted code?
Anonymous: These mitigations are controlled by sysctls, so they can be disabled in any situation where you don’t feel they are necessary.
Matthew Dillon posted another summary with specific sysctls mentioned; I’ll post on it later today when I have time to write it up.
The sysctls are great.
Is it possible to turn isolated_user_pmap off, launch your trusted database and file server applications and then turn it back on? Will the trusted applications continue to enjoy fast system calls in this scenario?
Since a newly purchased Xeon scale server is unlikely to be replaced soon, having a per process way of enabling or disabling the privacy mitigation for untrusted or trusted code could help tremendously with performance.
Anonymous, I think those sysctls work in the way you have described.