5 ms·

The Linux kernel developers came up with a decent solution, how can it be that they can do this and the Microsoft developers cannot?

braderhart 9y ago
Have you seen the Windows code base?
rxhernandez 9y ago
Is Windows written the exact same way as Linux? Never underestimate the amount of technical debt that can be holding a team down.
- chris_wot 9y ago
  It appears not, if such a bad bug can get through all the way to release.
  - Raymonf 9y ago
    "Linux" had a bug in which you could log into a system by pressing backspace 28 times a few years ago. And by Linux, I meant GRUB[1], and in turn, (many) Linux systems. We're comparing Linux and Windows, an operating system that contains 3.5 million files[2] (of course, not just the kernel in this case). That isn't really fair. Code is as perfect as humans can make it, and it certainly does not help that there's so much to take into account. [1] http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-by... [2] https://arstechnica.com/gadgets/2018/03/building-windows-4-million-commits-10-million-work-items/ https://arstechnica.com/gadgets/2018/03/building-windows-4-m...
    - pecg 9y ago
      This GRUB bug you are talking about, is not a kernel problem though; on a side note, I'm going to read on the links you provided as I want to see if encrypted root partitions could also be compromised, I suspect no.
    - chris_wot 9y ago
      That's not quite on par with this Windows bug, but I take your point.
- acct1771 9y ago
  Ding-ding-ding, this is the non-bs answer.
- tinus_hn 9y ago
  Is that an excuse though?
freehunter 9y ago
Because Linux is a completely different OS with completely different code and a completely different set of problems.
- chris_wot 9y ago
  That's entirely weak.
  - freehunter 9y ago
    I think the WINE people are probably looking for your help, for some reason they still seem to think there's a few differences between the two. They'll be happy to know they've been wasting their time.
    - chris_wot 9y ago
      I hate to tell you this, but the WINE people aren't doing kernel development.
      - stagbeetle 9y ago
        Chris_wot lashing out like a rabid hyena at anyone who gets near the contrarian carcass he's been picking at for a while now. May I suggest a break from whatever stimulants you may be on?
        michaelmrose 9y ago
        This is not appropriate discourse here.
        stagbeetle 9y ago
        As right you are, strange times call for stranger measures. I would post this in the relevant IRC, but he's unresponsive and seems to be neglecting his duties, once again fallen victim to shitpost mania. There's no other way to reach him as directly, and he needs to understand that his family misses him and his community understands.
cesarb 9y ago
The Linux developers had a head start in the form of the KAISER (later KPTI) patch set, development of which had AFAIK started before Meltdown was discovered and reported in private to Intel.
- gruez 9y ago
  >AFAIK started before Meltdown was discovered source?
  - Cookiesaurusbex 9y ago
    They said discovered AND reported, not just discovered. It is entirely possible someone discovered it much earlier and didn't report, but we won't ever know if evidence is never found.
  - cesarb 9y ago
    According to https://googleprojectzero.blogspot.com.br/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com.br/2018/01/reading-pr... Spectre was initially reported to Intel on 2017-06-01, and Meltdown a bit later. After a quick web search, I found https://patchwork.kernel.org/patch/9712001/ https://patchwork.kernel.org/patch/9712001/ which records the initial submission of the KAISER patch set at 2017-05-04. The repository at https://github.com/IAIK/KAISER https://github.com/IAIK/KAISER has an older version of the patch set dated 2017-02-24, indicating that work on it had started even earlier. Finally, the timeline at https://plus.google.com/+jwildeboer/posts/jj6a9JUaovP https://plus.google.com/+jwildeboer/posts/jj6a9JUaovP mentions a presentation from the authors of the patch set at the 33C3 on late 2016. Note that this page puts the submission of the KAISER patch set at 2017-06-24, but I believe that to be wrong; searching the web for "[RFC] x86_64: KAISER - do not map kernel in user mode" finds several mail archives with that message, and they all agree that the date was on May, not June. That is, even if Microsoft had been immediately warned by Intel (or by Google), the Linux kernel developers would still have had a few extra months of head start, by basing their work on the KAISER patch set. Was it luck, or a side effect of the Linux kernel being used for academic research?
nl 9y ago
The Linux kernel developers hate their solution, and they only used it because they can't think of a better one. It causes enormous increases in complexity and kills performance in many cases. They revived previous work on this as part of the KAISER work in November 2017, and still had major bugs with it in February 2018 (ie, 4 months later). That's pretty similar to the 6 month timeline mentioned here. https://lwn.net/Articles/738975/ https://lwn.net/Articles/738975/ https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/ https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...
- amluto 9y ago
  Linux kernel developer here. I don’t know know how MS’s Meltdown solution differs from Linux’s, let alone whether I should hate it. MS (I think) uses IBRS to help with Spectre, and IBRS is not so great. Retpolines have a more fun name at the very least :)
  - sewer_bird 9y ago
    I think he means Linux kernel developers hate (their own) solution for Meltdown.
    - caf 9y ago
      The essential element of the solution for Meltdown is the same in every x86-64 OS: unmapping the kernel when in usermode. This is widely hated because it makes kernel entries and exits much slower, and blows away the TLB if your hardware doesn't have PCID support.
      - nl 9y ago
        Yes, this. It sucks, but what else can one do?
cesarb 9y ago
Another relevant factor I just thought of: the Windows kernel has more constraints, due to binary-only drivers which have to keep working. The Linux kernel could fix any incompatible driver at the same time, since they're all in the same git tree (out-of-tree drivers are not expected to be compatible with newer kernels).
- lmilcin 9y ago
  I agree. The philosophy is different. Linux is focused on having the right thing working, at the cost of compatibility (sometimes). Windows is (or at least was) focused on extreme compatibility and the actual features of operating system seem to be slapped onto the features of the previous version of the OS. This seemed to work well for Windows audience in the past, also for Linux audience, due to the fact that they have different uses and audiences. People seem to have segregated into those users that just want stuff working and those that want powerful operating system that allows them to do whatever they want. At least that was until sometime the Windows 10 came...

braderhart 9y ago

Have you seen the Windows code base?

rxhernandez 9y ago

Is Windows written the exact same way as Linux? Never underestimate the amount of technical debt that can be holding a team down.

chris_wot 9y ago
It appears not, if such a bad bug can get through all the way to release.
- Raymonf 9y ago
  "Linux" had a bug in which you could log into a system by pressing backspace 28 times a few years ago. And by Linux, I meant GRUB[1], and in turn, (many) Linux systems. We're comparing Linux and Windows, an operating system that contains 3.5 million files[2] (of course, not just the kernel in this case). That isn't really fair. Code is as perfect as humans can make it, and it certainly does not help that there's so much to take into account. [1] http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-by... [2] https://arstechnica.com/gadgets/2018/03/building-windows-4-million-commits-10-million-work-items/ https://arstechnica.com/gadgets/2018/03/building-windows-4-m...
  - pecg 9y ago
    This GRUB bug you are talking about, is not a kernel problem though; on a side note, I'm going to read on the links you provided as I want to see if encrypted root partitions could also be compromised, I suspect no.
  - chris_wot 9y ago
    That's not quite on par with this Windows bug, but I take your point.
acct1771 9y ago
Ding-ding-ding, this is the non-bs answer.
tinus_hn 9y ago
Is that an excuse though?

freehunter 9y ago

Because Linux is a completely different OS with completely different code and a completely different set of problems.

chris_wot 9y ago
That's entirely weak.
- freehunter 9y ago
  I think the WINE people are probably looking for your help, for some reason they still seem to think there's a few differences between the two. They'll be happy to know they've been wasting their time.
  - chris_wot 9y ago
    I hate to tell you this, but the WINE people aren't doing kernel development.
    - stagbeetle 9y ago
      Chris_wot lashing out like a rabid hyena at anyone who gets near the contrarian carcass he's been picking at for a while now. May I suggest a break from whatever stimulants you may be on?
      - michaelmrose 9y ago
        This is not appropriate discourse here.
        stagbeetle 9y ago
        As right you are, strange times call for stranger measures. I would post this in the relevant IRC, but he's unresponsive and seems to be neglecting his duties, once again fallen victim to shitpost mania. There's no other way to reach him as directly, and he needs to understand that his family misses him and his community understands.

cesarb 9y ago

The Linux developers had a head start in the form of the KAISER (later KPTI) patch set, development of which had AFAIK started before Meltdown was discovered and reported in private to Intel.

gruez 9y ago
>AFAIK started before Meltdown was discovered source?
- Cookiesaurusbex 9y ago
  They said discovered AND reported, not just discovered. It is entirely possible someone discovered it much earlier and didn't report, but we won't ever know if evidence is never found.
- cesarb 9y ago
  According to https://googleprojectzero.blogspot.com.br/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com.br/2018/01/reading-pr... Spectre was initially reported to Intel on 2017-06-01, and Meltdown a bit later. After a quick web search, I found https://patchwork.kernel.org/patch/9712001/ https://patchwork.kernel.org/patch/9712001/ which records the initial submission of the KAISER patch set at 2017-05-04. The repository at https://github.com/IAIK/KAISER https://github.com/IAIK/KAISER has an older version of the patch set dated 2017-02-24, indicating that work on it had started even earlier. Finally, the timeline at https://plus.google.com/+jwildeboer/posts/jj6a9JUaovP https://plus.google.com/+jwildeboer/posts/jj6a9JUaovP mentions a presentation from the authors of the patch set at the 33C3 on late 2016. Note that this page puts the submission of the KAISER patch set at 2017-06-24, but I believe that to be wrong; searching the web for "[RFC] x86_64: KAISER - do not map kernel in user mode" finds several mail archives with that message, and they all agree that the date was on May, not June. That is, even if Microsoft had been immediately warned by Intel (or by Google), the Linux kernel developers would still have had a few extra months of head start, by basing their work on the KAISER patch set. Was it luck, or a side effect of the Linux kernel being used for academic research?

nl 9y ago

The Linux kernel developers hate their solution, and they only used it because they can't think of a better one. It causes enormous increases in complexity and kills performance in many cases. They revived previous work on this as part of the KAISER work in November 2017, and still had major bugs with it in February 2018 (ie, 4 months later). That's pretty similar to the 6 month timeline mentioned here. https://lwn.net/Articles/738975/ https://lwn.net/Articles/738975/ https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/ https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...

amluto 9y ago
Linux kernel developer here. I don’t know know how MS’s Meltdown solution differs from Linux’s, let alone whether I should hate it. MS (I think) uses IBRS to help with Spectre, and IBRS is not so great. Retpolines have a more fun name at the very least :)
- sewer_bird 9y ago
  I think he means Linux kernel developers hate (their own) solution for Meltdown.
  - caf 9y ago
    The essential element of the solution for Meltdown is the same in every x86-64 OS: unmapping the kernel when in usermode. This is widely hated because it makes kernel entries and exits much slower, and blows away the TLB if your hardware doesn't have PCID support.
    - nl 9y ago
      Yes, this. It sucks, but what else can one do?

cesarb 9y ago

Another relevant factor I just thought of: the Windows kernel has more constraints, due to binary-only drivers which have to keep working. The Linux kernel could fix any incompatible driver at the same time, since they're all in the same git tree (out-of-tree drivers are not expected to be compatible with newer kernels).

lmilcin 9y ago
I agree. The philosophy is different. Linux is focused on having the right thing working, at the cost of compatibility (sometimes). Windows is (or at least was) focused on extreme compatibility and the actual features of operating system seem to be slapped onto the features of the previous version of the OS. This seemed to work well for Windows audience in the past, also for Linux audience, due to the fact that they have different uses and audiences. People seem to have segregated into those users that just want stuff working and those that want powerful operating system that allows them to do whatever they want. At least that was until sometime the Windows 10 came...