1. 55

  2. 16

    In June 2018, in responding to issues around the KRACK embargo, Theo said “ps. Disable Intel Hyper-Threading where not needed, until we all know more.” At the time I mentioned we had made the decision to opportunistically disable hyperthreading on some of our physical hosts. This past weekend, just before L1FT / XSA-273 was publicly disclosed we finished that work: we’ve disabled hyperthreading on all of our production systems. I didn’t participate in the L1FT predisclosure as Xen announced XSA-273 without an embargo period, the same day Intel disclosed the issue. The Xen project itself was given advance notice, but not in a manner that permitted use of their own security process:

    Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure.

    As it pertains to XSA-273, disabling hyperthreading is necessary but not sufficient. One also needs updated microcode (not all of which was available prior to yesterday) as well as changes to Xen. Not all of these changes have not been made yet, though commits related to XSA-273 were published simultaneously with the disclosure. We’ll be patching our own systems over the next few weeks.

    1. 12

      Kind of an aside, but I’m pleased by the lack of vitriol in this.

      1. 13

        Almost all of Theo’s communications are straightforward and polite. It’s just that people cherry-picked and publicized the few occasions where he really let loose, so he got an undeserved reputation for being vitriolic.

        1. 2

          Pleasantly surprised, even.

        2. 6

          “A patch should arrive soon to flush the L1 cache before vmenter”

          The default in separation kernels from early 2000’s was partitioning and/or flushing caches since shared resources could be covert channels. There’s now covert channels being found in the shared resources. The patch will flush L1 cache. Why not flush them all just in case more attacks are found? Are there not instructions to do that for L2 or L3?

          1. 4

            We don’t know about attacks involving the other caches. Flushing all of them would significantly harm performance.

            1. 4

              That’s what I was thinking. It means they’re doing what maximizes performance instead of minimizes security risks. Then, fixing the problems as they show up. That’s exactly what Intel is doing with the additional benefit of cost reduction.

              So, the fixes are great. Just hypocritical to me that Theo called them out before about not doing enough mitigation for potential, side channels to boost performance or reduce development/runtime costs when they’re doing the same thing for same reasons w.r.t. other shared resources. Anyone wondering where the rest will come from to get started on preventative mitigations can check this out. Also, ditch Intel for simpler architectures where possible. Submitted my list here to help. Reduces attack and research space to identify remaining problems.

              1. 2

                ditch Intel for simpler architectures where possible

                That is, where you’re paranoid enough to prioritize simplicity and security over performance. Generally performance is very important. Trying to do any actual work (say, compiling code) on Cortex-A53s makes you really appreciate the performance hacks CPU designers are doing :)

                I wonder if a good solution is to keep all the aggressive speculation, but avoid sharing any resources between mutually untrusted code. Imagine a machine with a ton of little cores (like this one) plus an OS where applications can completely reserve cores so that nothing else runs on that core – so e.g. a web browser could reserve one core per origin. And in that situation, cache should be flushed, data in RAM should be arranged to maximize space between these untrusted processes, etc. But trusted processes should be able to use the non-reserved resources normally, with maximum performance.

                1. 2

                  Yeah, I use Intel/AMD CPU’s for that reason. I also claim to run an intentionally insecure setup. Im at least honest. ;)

                  Far as your idea, Clive Robinson on Schneier’s blog always pushed something like that called Prison architecture. They’d be a pile of little CPU’s (more like MCU’s) running individual functions and modules of the system. They’d have behavioral profiles plus be designed where that was possible to begin with. Like Cell’s helper units, they’re restricted to run what they’re told with some master CPU’s and hypervisor controlling them. It would inspect them agsinst the profile like a warden inspecting prison cells. Plus be metered.

                  Those are details I remember most. I was into security/separation kernels heavily at the time. We debated the two concepts a lot. Blog readers liked that topic the most that I remember.

          2. 5

            We asked repeatedly, but Intel provided no advance notice. We did not even receive replies to our requests for dialogue.

            bad intel