On Thu, Jan 04, 2018 at 08:16:18PM +0000, Ken Moffat wrote: (forgot to Cc: blfs-support - and small change at end re microcode)
> People who follow the news will be aware that big changes have been > rushed into the linux kernel (and changes are/have been also rolled > out by microsoft, and apparently by apple). > > There are two vulnerabilities, with the shiny names of Meltdown and > Spectre. Both refer to ways of userspace finding where the kernel > has been mapped, to try to do harm. Page Table Isolation addresses > the first of these. Google claim it affects some AMD processors, > AMD deny this. > > This started out under the name of KAISER, as an apparently > theoretical hardening, but at one point (I suppose once those in the > know realised it was a real issue) Forcefully Unmap Complete Kernel > With Interrupt Trampolines was suggested before Page Table Isolation > became the preferred name. > > In particular, note that userspace in a VM can exploit this to read > data from the host or other VMs, which is why cloud providers are > updating. > > PTI has been pushed into 4.15-rc6 as a matter of urgency, and > added to 4.14.11 with backports to 4.9 and 4.4 in progress. > > Most testing, particularly by the 0-day kernel bot, has been on > Intel hardware and running this on AMD has uncovered some problems > which have been addressed in linus's tree and which will be in > 4.14.12. With 4.14.12, if PTI is selected it will not be used at > runtime on an AMD machine with the default auto option, although I > think it can be forced by specifying the 'pti' boot argument. > > If a kernel has been built with PTI, it can be disabled by > specifying 'nopti' in the command line. Once a kernel has booted, > PTI cannot be enabled or disabled until you reboot. > > If you are running with PTI enabled, dmesg will show > Kernel/User page tables isolation: enabled > > Obviously, the effect of this will vary with the workload. Figures > of 5% to 30% are being suggested. So, on my SandyBridge i3 I've > been running some build tests, first on 4.14.0 and then on 4.14.11 > with PTI. Please bear in mind that because of the length of time > these tests take, I've only run each set once. Linux is not a RTOS, > and I have noticed some variation in the past when repeating tests > to measure build times. I *guess* that a variation of plus or minus > 2% is normal. > > From these tests, the following points are perhaps worth noting: > > kernel compilation : within normal variation (ok, it was quicker on > the newer kernel, but only by 2 seconds) > > Running my script to rebuild binutils pass 1 on a completed system > to get an updated SBU : 135.083s became 135.498s so no change. > > Building rustc-1.22.1 with Python3, running the tests and doing a > DESTDIR install - 1.2% slower which I regard as within normal > variation. > > Building firefox-57.0.3 and installing it in /opt : for this I used > a variation of my normal script (first I tried pasting all the > commands, but obviously got something wrong because rust panicked). > This showed a speed reduction of 5.8% which is significant, but > random screensavers were running and maybe affected this. > > git-2.15.1 with the tests : 3.9% slower. > > openssl-1.1.0g including make test : 3.4% slower > > asymptote-2.41 : within normal variation > > QupZilla-2.2.3 : 2.4% slower > > ImageMagick-7.0.7-11 : 2.4% slower for the build, but 7.6% slower > running tests/validate. > > ffmpeg-3.4.1 (without tests) : within normal variation > > My latex-test-20160905 tests : within normal variation. > > Summary - although it has been noted that running postgresql on a > laptop was significantly affected by PTI, I think that for most BLFS > users the effect will be slight. > > The Spectre vulnerability is more general, and apparently much > harder to exploit. It is claimed to affect almost all modern > processors. Apparently, anything using a JIT compiler, e.g. > javascript, can be hacked. Steps to mitigate this in the kernel > are now being discussed, but this might require additions to gcc. > > Intel are also in the process of releasing new firmware for > processors released in the last 5 years. The current firmware is > now 20171117 but I'm not sure if that is up to date (it might be!) > > https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?v=t > Well, whatever else that does, it does NOT contain anything new for my SandyBridge (I didn't really expect any update, it is more than 5 years old), but also nothing new for my Haswell, which I had thought might get an update. There _is_ a different file for my Skylake, but it doesn't load (trying late loading, dmesg reported soemthing like 'unable to save', and using it for early loading did not load, and it was a PITA to get the earlier firmware loaded (early loading didn't happen, but I've now extracted it again to /lib/firmware and managed late loading). So, whilst the link in BLFS is out of date, I don't have a lot of confidence about the newer version and it certainly doesn't seem to fix anything re Spectre. > ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
