Date: Thu, 24 Jan 2019 11:32:59 -0500 From: Zaphod Beeblebrox <zbeeble@gmail.com> To: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Scheduled ideas: Two threads with one "stone" Message-ID: <CACpH0Mc09tjybFKpdh=yMRKxvMuHjRC4k6sen1kUo2AoLd7UHw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
W.R.T. hyperthreading, it's come to my attention that FreeBSD has had some recommendations for awhile --- namely hyperthreading is bad for secure systems. That-is-to-say this is not about recent vulnerabilities of recent Intel flavoured CPUs, but rather some thoughts on a different solution to a different problem. I was building world on my laptop when I noticed how sucky it had become. Now... I well know this is due to the fact that even a "nice -19 make -j32 buildworld" will slow the normal priority userland down by about 1/2 because the thread that is "me" on the CPU is competing with one of the threads that is saturating the CPU. My normal priority thread will get scheduled, but it competes equally for resources with threads at much lower priority. It then struck me that the fix for this problem would also address the hyperthreading side channel attack. It struck me that two simple rules would apply to scheduling hyperthreads (rather than the global "turn them off for security" ... To be scheduled on a paired hyperthread, the candidate thread should: 1. Belong to the same user 2. Be the same (or the same within a margin) effective priority My argument here for (1) is that it makes the hyperthreading side channel attack moot. The same user has many ways to access the other process... the hyperthreading attack would just be a waste of time. My argument for (2) is that it would restore the experience of responsiveness the local machine that we have on non-hyperthreading processors.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACpH0Mc09tjybFKpdh=yMRKxvMuHjRC4k6sen1kUo2AoLd7UHw>