6 ms·

My 2 unasked for pennies - the kernel is already too bloated with support. These are hacks and should not be mainlined. Let them fix their hardware and give a

by axaxs 9y ago

My 2 unasked for pennies - the kernel is already too bloated with support. These are hacks and should not be mainlined. Let them fix their hardware and give arduous instructions to patch...they deserve it. Don't further pollute the kernel. Imagine if a tiny hardware vendor tried the same...ubiquity is not an excuse.

oneweekwonder 9y ago
> My 2 unasked for pennies - the kernel is already too bloated with support. Is this not the ultimate fate for any monolithic kernel? Because by design you need to add everything to the kernel. While these patches might apply to micro kernels as well. I wonder if there is kernels that abstract the cpu into a device driver to even keep microcode bloat out of your kernel? As a side thought; If you abstract your cpu like this; will it allow you to hot-swap your os between devices and architectures?
- axaxs 9y ago
  It is. I'm very much against mono kernels, but it is what we have. Let Intel side patch like grsec.
Someone 9y ago
”Let them fix their hardware” That could (and, I guess, would) mean a much, much, larger performance hit than a combined microcode/kernel fix would give. I doubt people would be happy about that. Given that we don’t want to give up all speculated instruction execution, it will be difficult to find the spot where we get safety at minimal performance impact.
- gaius 9y ago
  Right, but why should OS devs and vendors scramble to save Intel’s share price? The right outcome here is for the devs to do nothing and the world switch to another CPU vendor on the next hardware refresh cycle.
  - mhandley 9y ago
    Which CPU vendor would you switch to? Although Meltdown is (mostly) an Intel bug, all the main CPU vendors, including AMD and ARM, are affected by Spectre, which is what this particular discussion is about.
    - gaius 9y ago
      Agreed, but it almost doesn’t matter: what matters is sending the signal that shenanigans will be punished by the market. If devs do anything it should be learning to write software that doesn’t depend on speculative execution for performance
      - mhandley 9y ago
        The problem is that spectulative execution is fundamental to performance in systems that have conditionals. With memory latencies being ~100ns, and a 3GHz core, you waste 300 cycles every time you need to load the conditional from RAM, and maybe 50 cycles if you need to load it from L3 cache. Branch prediction is generally pretty accurate, so avoiding that penalty is crucial if you want to go fast. Now, maybe it is possible to reduce use of indirect branches . C++ for example, is pretty gratuitous in that respect. But in the end, most software is going to perform a lot slower without speculative execution. I don't think that's a price worth paying. What will happen is the CPU vendors will fix meltdown (which should never have happened) and Spectre 2. Sharing the branch history buffer between contexts is something that fundamentally can be avoided, in the same way we can tag TLB entries with the PCID on recent hardware. In the long run, the real issue is Spectre 1. Using software to contain untrusted software in the same address space is fundamentally hard with speculative execution. After all the fuss has died down, that's where we'll see innovative software techniques. It's already starting to happen, if you look at the webkit changes (scroll down to Branchless Security Checks): https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/ https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-...
      - coldtea 9y ago
        >Agreed, but it almost doesn’t matter: what matters is sending the signal that shenanigans will be punished by the market. No, what it matters is understanding the issue. And the issue has no "shenanigans". All vendors suffer from Spectre (and some non-Intel models from Meltdown too), but more importantly, none of these was done "on purpose" which is the definition of a shenanigan. >If devs do anything it should be learning to write software that doesn’t depend on speculative execution for performance Whatever.
imtringued 9y ago
Are you willing to wait half a decade for the fix?
lucozade 9y ago
> These are hacks and should not be mainlined Of course they should. Linux needs to work on hardware that exists not just on hardware that may, one day, exist. > Don't further pollute the kernel. One of the primary jobs of kernels, drivers and compilers is to abstract some of the underlying hardware complexity away. Kernels, drivers and compilers have always dealt with bugs and limitations in hardware. Things like retpoline and CPU barriers aren't especially unusual. Emergency fixing such a pervasive issue is unusual though, hence the attention. > ubiquity is not an excuse No, but it's a really, really good reason If I were inclined to facetiousness (which I'm not), I would point out that there is a large number of other kernels out there that aren't especially performant and don't work well on most hardware. If you really object to this, you can always use one of those.

by axaxs 9y ago

oneweekwonder 9y ago

> My 2 unasked for pennies - the kernel is already too bloated with support. Is this not the ultimate fate for any monolithic kernel? Because by design you need to add everything to the kernel. While these patches might apply to micro kernels as well. I wonder if there is kernels that abstract the cpu into a device driver to even keep microcode bloat out of your kernel? As a side thought; If you abstract your cpu like this; will it allow you to hot-swap your os between devices and architectures?

axaxs 9y ago
It is. I'm very much against mono kernels, but it is what we have. Let Intel side patch like grsec.

Someone 9y ago

”Let them fix their hardware” That could (and, I guess, would) mean a much, much, larger performance hit than a combined microcode/kernel fix would give. I doubt people would be happy about that. Given that we don’t want to give up all speculated instruction execution, it will be difficult to find the spot where we get safety at minimal performance impact.

gaius 9y ago
Right, but why should OS devs and vendors scramble to save Intel’s share price? The right outcome here is for the devs to do nothing and the world switch to another CPU vendor on the next hardware refresh cycle.
- mhandley 9y ago
  Which CPU vendor would you switch to? Although Meltdown is (mostly) an Intel bug, all the main CPU vendors, including AMD and ARM, are affected by Spectre, which is what this particular discussion is about.
  - gaius 9y ago
    Agreed, but it almost doesn’t matter: what matters is sending the signal that shenanigans will be punished by the market. If devs do anything it should be learning to write software that doesn’t depend on speculative execution for performance
    - mhandley 9y ago
      The problem is that spectulative execution is fundamental to performance in systems that have conditionals. With memory latencies being ~100ns, and a 3GHz core, you waste 300 cycles every time you need to load the conditional from RAM, and maybe 50 cycles if you need to load it from L3 cache. Branch prediction is generally pretty accurate, so avoiding that penalty is crucial if you want to go fast. Now, maybe it is possible to reduce use of indirect branches . C++ for example, is pretty gratuitous in that respect. But in the end, most software is going to perform a lot slower without speculative execution. I don't think that's a price worth paying. What will happen is the CPU vendors will fix meltdown (which should never have happened) and Spectre 2. Sharing the branch history buffer between contexts is something that fundamentally can be avoided, in the same way we can tag TLB entries with the PCID on recent hardware. In the long run, the real issue is Spectre 1. Using software to contain untrusted software in the same address space is fundamentally hard with speculative execution. After all the fuss has died down, that's where we'll see innovative software techniques. It's already starting to happen, if you look at the webkit changes (scroll down to Branchless Security Checks): https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/ https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-...
    - coldtea 9y ago
      >Agreed, but it almost doesn’t matter: what matters is sending the signal that shenanigans will be punished by the market. No, what it matters is understanding the issue. And the issue has no "shenanigans". All vendors suffer from Spectre (and some non-Intel models from Meltdown too), but more importantly, none of these was done "on purpose" which is the definition of a shenanigan. >If devs do anything it should be learning to write software that doesn’t depend on speculative execution for performance Whatever.

imtringued 9y ago

Are you willing to wait half a decade for the fix?

lucozade 9y ago

> These are hacks and should not be mainlined Of course they should. Linux needs to work on hardware that exists not just on hardware that may, one day, exist. > Don't further pollute the kernel. One of the primary jobs of kernels, drivers and compilers is to abstract some of the underlying hardware complexity away. Kernels, drivers and compilers have always dealt with bugs and limitations in hardware. Things like retpoline and CPU barriers aren't especially unusual. Emergency fixing such a pervasive issue is unusual though, hence the attention. > ubiquity is not an excuse No, but it's a really, really good reason If I were inclined to facetiousness (which I'm not), I would point out that there is a large number of other kernels out there that aren't especially performant and don't work well on most hardware. If you really object to this, you can always use one of those.