8 ms·

The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were

by B-Con 9y ago

The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore or sweep under the rug if it's inconvenient to business.

dspillett 9y ago
> Open isn't a magic bullet. > more about quality of auditing. Exactly. Being open makes things easier to audit, and to an extent encourages better due diligence (as embarrassments due to silly mistakes or, worse, attempted cover-ups, are more public!), but it doesn't enforce this in any way nor does it guarantee quality or completeness.
- freedomben 9y ago
  Fortunately as we saw from the OpenSSL debacle a while back, often deep corporate pockets (like Google) will step up and audit/patch these projects. Being open is obviously a pre-requisite for that to happen.
- mar77i 9y ago
  The point here should be about responsibility. When I screw up something that I picked up from "out in the open", eg. my server deployments, it more technically makes it my own fault. I am therefore more inclined to study an open circuit design because if it fails on me, I'm only left with myself to blame. ...and if I in fact identify any shortcomings, I can help others not to get hit by them, which makes the concept of openness "safer" in a way that is the sum of collective knowledge.
  - mar77i 9y ago
    I just noticed my argument has analogies to Eric S. Raymond's argument about the cathedral and the bazaar. I'd actually love to see a bazaar on the cpu side of things, be it just for the sake of what community efforts can achieve as opposed to the current mostly proprietary ecosystem.
IshKebab 9y ago
No the vulnerabilities could not have been found by reading the manual. The researchers had to reverse engineer how branch predictor aliasing works for example. I recommend reading the Google project zero blog post on them - they're easy to follow.
- B-Con 9y ago
  https://www.bloomberg.com/news/articles/2018-01-17/how-a-22-year-old-discovered-the-worst-chip-flaws-in-history https://www.bloomberg.com/news/articles/2018-01-17/how-a-22-...
anfilt 9y ago
They had to partly reverse engineer the branch predictor. It was not fully documented...
simias 9y ago
I'd pay good money for an open and simpler platform to run my security-critical tasks that don't require top performance. Auditing a modern high-end CPU is probably a huge task even if you have access to the HDL because of how complex they are. A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web, send emails and do 99% of my daily tasks except maybe compile C++ or Rust code. The problem of course is that it's probably a very niche market at the moment. Most people probably don't really understand what's at stake and might not even care either way. As such I don't expect that people could manufacture open CPUs and sell them at a reasonable price. So you'd end up with overpriced, under-powered CPUs which won't drive adoption. I can't imagine such a project being successful if it's not backed by a big company or a government. I kind of wish the European Union would try its hand at it, after all computing is absolutely critical these days (and it's only going to get more critical as time passes) yet we're completely dependent on american and chinese companies to provide us with CPUs. If the EU thought that Galileo was worthwhile to have our own positioning system certainly it also makes sense to have our own CPUs for critical tasks?
- bringtheaction 9y ago
  > A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web I used a couple of Single Board Computers as my main computers for a while a couple of years back and it was really quite painful. Especially web browsing.
  - meuk 9y ago
    The web (by that I mean most browsers and most web pages) is designed for hi-end devices. Text-based browsing also ought to be possible, but often doesn't work well in practice because it's not a common use case, and so it's not something that developers consider in the design process.
  - simias 9y ago
    Yeah I actually considered that while writing my original comment, it's true that even on a low-end smartphone nowadays browsing certain websites is extremely frustrating. That being said is it really reasonable that the modern web requires multi GHz CPUs, GB of RAM and allowing a turing-complete scripting language everywhere to be able to browse most websites? Is it reasonable that the web is so complex now that effectively nobody but a few giant companies can invest the time and resource to write and maintain the millions of lines of code of a modern browser?
sebastian 9y ago
> Open isn't a magic bullet. But closeness makes it extremely difficult to find actual backdoors left on purpose. Open processors would be a first step in the right direction.
- ask098 9y ago
  remember, hacker will always find the backdoors first if we open source!
nerdponx 9y ago
As I understand it, according to an article that was posted here a day or two ago, Meltdown was in fact discovered by a young Google engineer poring over the x86 manual.
- RandomCSGeek 9y ago
  Yes. A 22 y/o guy.
  - freedomben 9y ago
    That's incredible. It makes me feel like I haven't done anything with my life :-D
- baybal2 9y ago
  No, only those 3 particular exploit methods. P3 branch predictor peculiarities were known before, but were refuted as unexploitable.
- B-Con 9y ago
  Right. But how long did that take? The problem had been around for years.
mandelbulb 9y ago
>Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. How about, discovering it? That's one of the points of openness, not somehow being inherently better in a way. At least we have a spec manual in this case. Also, audits should be peer-reviewed, that's difficult without openness.
- bastawhiz 9y ago
  Heartbleed was in OpenSSL for years before it was discovered. It was readily auditable with plenty of docs and specs and yet nobody noticed.
saas_co_de 9y ago
> You could've found them by reading the manual Pretty much. Everything you needed to figure this out was public. Just publishing stuff doesn't help much in areas this complex and specialized where there are a very small number of people who can really understand what is published. There is also a major difference between reading a spec and discovering an exploit through an adversarial process. Nobody who had complete access to confidential data (at Intel or anywhere else) figured this out. People on the outside working with an adversarial process did. The adversarial process is driven by testing not documentation. There is no reason to think that the people who figured it out would have been aided by having more internal documentation.
- int0x80 9y ago
  I'm sorry but the implementation of the speculative execution or the branch predictors was not available at all. Could you tell for example that AMD wasn't vulnerable to meltdown but Intel was by looking at any docs? Not really.
- jhasse 9y ago
  > There is no reason to think that the people who figured it out would have been aided by having more internal documentation. Why not?
ask098 9y ago
network stack open source for years, but most of attacks are from the internet
baybal2 9y ago
>As I understand, these latest CPU vulnerabilities were in the spec themselves. And yes, 20 years ago Intel was called out for that. In a narrow circle of electronic engineers specialising in CPU designs, this quirk was a know source of worries.
int0x80 9y ago
I really don't think that the speculative execution _implementation_ was in any spec whatsoever. The fact that it did the protection domain check later in the process was not documented by Intel at all for example. Having said that, the implementation was (obviously) available for Intel engineers and they didn't spot the problem in 10+ years. Bugs will happen, especially this kind of bugs that people generally haven't had in mind in the past.
- em3rgent0rdr 9y ago
  Was is a unintentional bug, or was a deliberate design tradeoff favoring performance over security?
  - int0x80 9y ago
    I'm assuming the former, but I could be wrong.
    - em3rgent0rdr 9y ago
      The risk of speculative updates to branch predictor and page tables was known to the research community for a while. Even if it was initially an unintentional bug, they had plenty of time to take precautions against it by prohibiting speculative updates.
ken 9y ago
I think there's a huge difference between "take an existing system design, and declare it open" and "design a system in the open". This article isn't suggesting Intel make x86 open to all, for example. You get a completely different design when something is designed behind closed doors as a black-box product, versus designed in the open. Linux and Windows have drastically different designs, based on how they grew up. Early Mozilla releases were open-source, but still "bore the scars of many rapid cycles of closed-source development" [https://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite https://en.wikipedia.org/wiki/History_of_Mozilla_Application...]. From the recent news, it seems that StarOffice is finally becoming somewhat hackable for us mere mortals (who don't speak German). It's the process, more than the license. An open license enables an open process. "Magic bullet" implies you've got something evil (x86, with bugs!) and want to magically transform it (x86, with no bugs?), but nobody is proposing that. It sounds more like they want to put Conway's Law to work for us (e.g., RISC-V).
- Aloha 9y ago
  > I think there's a huge difference between "take an existing system design, and declare it open" and "design a system in the open". This article isn't suggesting Intel make x86 open to all, for example. You get a completely different design when something is designed behind closed doors as a black-box product, versus designed in the open. I don't - I believe there are an insufficient number subject matter experts conversant enough in processor design to provide the depth of auditing needed. I'm not saying openness is good or bad (its usually good) just that its not a panacea here.
- freedomben 9y ago
  Is this the StarOffice you were referring to? https://en.wikipedia.org/wiki/StarOffice https://en.wikipedia.org/wiki/StarOffice Is that still being hacked on? I thought most of the OO people moved to Libre Office
totemizer 9y ago
"open isn't a magic bullet" yeah, but closed is a harmful pattern. Open isn't about everything magically getting better, but when you do close development of something that potentially influences billions of people, it's an invitation for disaster. We do not want open because we like open, we want open because we are afraid of closed. and just to be clear, the least whatever you are doing in a closed format affects people the least i want it to be open.

by B-Con 9y ago

dspillett 9y ago

> Open isn't a magic bullet. > more about quality of auditing. Exactly. Being open makes things easier to audit, and to an extent encourages better due diligence (as embarrassments due to silly mistakes or, worse, attempted cover-ups, are more public!), but it doesn't enforce this in any way nor does it guarantee quality or completeness.

freedomben 9y ago
Fortunately as we saw from the OpenSSL debacle a while back, often deep corporate pockets (like Google) will step up and audit/patch these projects. Being open is obviously a pre-requisite for that to happen.
mar77i 9y ago
The point here should be about responsibility. When I screw up something that I picked up from "out in the open", eg. my server deployments, it more technically makes it my own fault. I am therefore more inclined to study an open circuit design because if it fails on me, I'm only left with myself to blame. ...and if I in fact identify any shortcomings, I can help others not to get hit by them, which makes the concept of openness "safer" in a way that is the sum of collective knowledge.
- mar77i 9y ago
  I just noticed my argument has analogies to Eric S. Raymond's argument about the cathedral and the bazaar. I'd actually love to see a bazaar on the cpu side of things, be it just for the sake of what community efforts can achieve as opposed to the current mostly proprietary ecosystem.

IshKebab 9y ago

No the vulnerabilities could not have been found by reading the manual. The researchers had to reverse engineer how branch predictor aliasing works for example. I recommend reading the Google project zero blog post on them - they're easy to follow.

B-Con 9y ago
https://www.bloomberg.com/news/articles/2018-01-17/how-a-22-year-old-discovered-the-worst-chip-flaws-in-history https://www.bloomberg.com/news/articles/2018-01-17/how-a-22-...

anfilt 9y ago

They had to partly reverse engineer the branch predictor. It was not fully documented...

simias 9y ago

I'd pay good money for an open and simpler platform to run my security-critical tasks that don't require top performance. Auditing a modern high-end CPU is probably a huge task even if you have access to the HDL because of how complex they are. A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web, send emails and do 99% of my daily tasks except maybe compile C++ or Rust code. The problem of course is that it's probably a very niche market at the moment. Most people probably don't really understand what's at stake and might not even care either way. As such I don't expect that people could manufacture open CPUs and sell them at a reasonable price. So you'd end up with overpriced, under-powered CPUs which won't drive adoption. I can't imagine such a project being successful if it's not backed by a big company or a government. I kind of wish the European Union would try its hand at it, after all computing is absolutely critical these days (and it's only going to get more critical as time passes) yet we're completely dependent on american and chinese companies to provide us with CPUs. If the EU thought that Galileo was worthwhile to have our own positioning system certainly it also makes sense to have our own CPUs for critical tasks?

bringtheaction 9y ago
> A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web I used a couple of Single Board Computers as my main computers for a while a couple of years back and it was really quite painful. Especially web browsing.
- meuk 9y ago
  The web (by that I mean most browsers and most web pages) is designed for hi-end devices. Text-based browsing also ought to be possible, but often doesn't work well in practice because it's not a common use case, and so it's not something that developers consider in the design process.
- simias 9y ago
  Yeah I actually considered that while writing my original comment, it's true that even on a low-end smartphone nowadays browsing certain websites is extremely frustrating. That being said is it really reasonable that the modern web requires multi GHz CPUs, GB of RAM and allowing a turing-complete scripting language everywhere to be able to browse most websites? Is it reasonable that the web is so complex now that effectively nobody but a few giant companies can invest the time and resource to write and maintain the millions of lines of code of a modern browser?

sebastian 9y ago

> Open isn't a magic bullet. But closeness makes it extremely difficult to find actual backdoors left on purpose. Open processors would be a first step in the right direction.

ask098 9y ago
remember, hacker will always find the backdoors first if we open source!

nerdponx 9y ago

As I understand it, according to an article that was posted here a day or two ago, Meltdown was in fact discovered by a young Google engineer poring over the x86 manual.

RandomCSGeek 9y ago
Yes. A 22 y/o guy.
- freedomben 9y ago
  That's incredible. It makes me feel like I haven't done anything with my life :-D
baybal2 9y ago
No, only those 3 particular exploit methods. P3 branch predictor peculiarities were known before, but were refuted as unexploitable.
B-Con 9y ago
Right. But how long did that take? The problem had been around for years.

mandelbulb 9y ago

>Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us. How about, discovering it? That's one of the points of openness, not somehow being inherently better in a way. At least we have a spec manual in this case. Also, audits should be peer-reviewed, that's difficult without openness.

bastawhiz 9y ago
Heartbleed was in OpenSSL for years before it was discovered. It was readily auditable with plenty of docs and specs and yet nobody noticed.

saas_co_de 9y ago

> You could've found them by reading the manual Pretty much. Everything you needed to figure this out was public. Just publishing stuff doesn't help much in areas this complex and specialized where there are a very small number of people who can really understand what is published. There is also a major difference between reading a spec and discovering an exploit through an adversarial process. Nobody who had complete access to confidential data (at Intel or anywhere else) figured this out. People on the outside working with an adversarial process did. The adversarial process is driven by testing not documentation. There is no reason to think that the people who figured it out would have been aided by having more internal documentation.

int0x80 9y ago
I'm sorry but the implementation of the speculative execution or the branch predictors was not available at all. Could you tell for example that AMD wasn't vulnerable to meltdown but Intel was by looking at any docs? Not really.
jhasse 9y ago
> There is no reason to think that the people who figured it out would have been aided by having more internal documentation. Why not?

ask098 9y ago

network stack open source for years, but most of attacks are from the internet

baybal2 9y ago

>As I understand, these latest CPU vulnerabilities were in the spec themselves. And yes, 20 years ago Intel was called out for that. In a narrow circle of electronic engineers specialising in CPU designs, this quirk was a know source of worries.

int0x80 9y ago

I really don't think that the speculative execution _implementation_ was in any spec whatsoever. The fact that it did the protection domain check later in the process was not documented by Intel at all for example. Having said that, the implementation was (obviously) available for Intel engineers and they didn't spot the problem in 10+ years. Bugs will happen, especially this kind of bugs that people generally haven't had in mind in the past.

em3rgent0rdr 9y ago
Was is a unintentional bug, or was a deliberate design tradeoff favoring performance over security?
- int0x80 9y ago
  I'm assuming the former, but I could be wrong.
  - em3rgent0rdr 9y ago
    The risk of speculative updates to branch predictor and page tables was known to the research community for a while. Even if it was initially an unintentional bug, they had plenty of time to take precautions against it by prohibiting speculative updates.

ken 9y ago

I think there's a huge difference between "take an existing system design, and declare it open" and "design a system in the open". This article isn't suggesting Intel make x86 open to all, for example. You get a completely different design when something is designed behind closed doors as a black-box product, versus designed in the open. Linux and Windows have drastically different designs, based on how they grew up. Early Mozilla releases were open-source, but still "bore the scars of many rapid cycles of closed-source development" [https://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite https://en.wikipedia.org/wiki/History_of_Mozilla_Application...]. From the recent news, it seems that StarOffice is finally becoming somewhat hackable for us mere mortals (who don't speak German). It's the process, more than the license. An open license enables an open process. "Magic bullet" implies you've got something evil (x86, with bugs!) and want to magically transform it (x86, with no bugs?), but nobody is proposing that. It sounds more like they want to put Conway's Law to work for us (e.g., RISC-V).

Aloha 9y ago
> I think there's a huge difference between "take an existing system design, and declare it open" and "design a system in the open". This article isn't suggesting Intel make x86 open to all, for example. You get a completely different design when something is designed behind closed doors as a black-box product, versus designed in the open. I don't - I believe there are an insufficient number subject matter experts conversant enough in processor design to provide the depth of auditing needed. I'm not saying openness is good or bad (its usually good) just that its not a panacea here.
freedomben 9y ago
Is this the StarOffice you were referring to? https://en.wikipedia.org/wiki/StarOffice https://en.wikipedia.org/wiki/StarOffice Is that still being hacked on? I thought most of the OO people moved to Libre Office

totemizer 9y ago

"open isn't a magic bullet" yeah, but closed is a harmful pattern. Open isn't about everything magically getting better, but when you do close development of something that potentially influences billions of people, it's an invitation for disaster. We do not want open because we like open, we want open because we are afraid of closed. and just to be clear, the least whatever you are doing in a closed format affects people the least i want it to be open.