Being free (or open) source have nothing to do with security: Linux/BSD still have 0day rootkits, yet all source is available, modern JS software have all tracking in the world, yet all source is available (VSCode telemetry). Even RISC-V, being fully open, most likely will be susceptible to spectre attack.

Instead of false promises we need to develop better engineering: verification, computational math, etc. And also laws - no free/open license in the world will stop companies from tracking, but fine as big as 4% of total revenue (EU GDPR) will make them oblige.

It seems like in the case of Meltdown and Spectre, FOSS may have /everything/ to do with security. FOSS with the addendum that you don't execute arbitrary javascript, anyway.

In a world where personal computers only ran code the user could safely trust, these exploits would only be full attack vectors when applied to multi-tenant computing environments.

I'm not arguing that FOSS systems are inherently more secure than closed systems, but when it comes to exploits that require arbitrary code execution to be effective, Stallman really was/is right. Between a NoScript browser extension and a system whose source code is entirely available to you, you've basically got Meltdown/Spectre immunity.

As much as I would love to believe that I personally can sanely inspect all the code I run - I can't. One day I run apt-get install git and I have to trust all code that is being pulled to my machine (and there is a lot of code there) simply because my lifespan is probably shorter then time required to audit all the code in git dependencies (ssl, crt, kernel, etc). So given I can't possibly audit everything, then I need to trust, and if I need to trust, then being FOSS might make me feel a bit more sure about safety of the code, but in reality it might not even make such a difference - apt-get pulls-in binaries, who knows what/how/where this binaries are made ... trust chain is simply not there.

I personally trust FOSS software more not to do dumb things (like, hopefully my password manager doesn't report all my passwords to NSA), but simply being FOSS doesn't make it any more secure :)

> who knows what/how/where this binaries are made

Reproducible builds (https://reproducible-builds.org/) is an initiative to fix that part of the problem. With reproducible builds, a third party with the same source code and compiler will get an identical binary, so we can have independent entities certifying that the code you download with apt-get was built from the corresponding source code.

RISC V is certainly not vulnerable to Spectere as all the the real-world chips are in-order execution, meaning post-branch instruction never happen until after the branch is decided.

Out of order variants are still in the design stage, so they may come up with a way to isolate or invalidate speculation effects on branch misprediction.

OSS makes vulnerabilities easier to discover, but if the project isn't well known they may still easily go unnoticed.

> Being free (or open) source have nothing to do with security

My Windows 10 machine got the Meltdown patch yesterday, in an out-of-band, undelayable update. Then it restarted itself during the night and this morning it's secure. My Ubuntu laptop is still unpatched and I'm not sure when the 4.15 upgrade will come to 16.04.

Ubuntu is probably going to be updated before January, 9th (https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...)

This problem was discoverable for the last 20 years. Of all the confidential tech that goes into a CPU, this wasn't it.

So the question becomes, why didn't anyone discover it?

Because it's difficult. Sure, it's obvious in hindsight, but it's a flaw in a small part of a very large and complex system.

What happened to all the theorem proving software that are supposed to absolutely guarantee correctness of code. I guess they are only as accurate as the assumptions input into them?

In this case the CPU does function exactly as designed. Any correctness prover would agree.

It does show the problem of all theorem provers: they are only as good as the specification.

The code conforms to the specification. It's not buggy.

The specification does not conform to the user's expectations or documentation. It's flawed.

Theorem provers can only prove that the code conforms to the specification, not to the user's expectations or documentation. They can be very helpful, but they aren't magic and can't interpret non-formal specifications.

Too good to be shared perhaps? I don't like this conspiracy theory way of thinking, but post-Snowden it's difficult to draw a line.

Ironically enough, RMS could probably be using the most side-channel-leaking CPU on his computer and it wouldn't matter... because he is the sole user and runs only his carefully-chosen free software on it.

His thoughts on cloud computing, however, are very much worth listening to.

Bugs happen. I wouldn't even beyond emacs to not still have a remotely exploitable security issue. Not to mention Firefox.

He is quite unusual in his habits, but considering that he is probably a more high-value target than the majority of us, I'd say his approach has served him well.

https://stallman.org/stallman-computing.html

Scroll down to the point titled "I am careful in how I use the Internet."

How is Stallman more high-value than a software developer working in a tech company? I'd say the opposite is true.

I don't think that was the point of the parent comment. Obviously Stallman's system is not perfectly secure, but it may well be immune to exploits that require arbitrary code execution like Meltdown and Spectre.

To be absolutely safe, you just need a processor that is simple enough not to use any of these performance enhancing techniques (ie out-of-order execution, speculation, branch prediction, caching.) Of course it might be much slower than you are used to but if security is your primary concern it makes sense.

Only caching use a problem. Indirect branch prediction can be "flattened" at a cost by checking TLB in context switch, presuming the kernel sets it up nicely per process. The other techniques are fine. As usual, secure code needs to be written with timing attacks in mind and they don't change much there.

What specifically has Stallman said that relates to this particular issue?

Apart from usual 'open source' and 'who controls the software' dogma, I find his endless gnawing about libreboot and Intel ME very related to general closed-box-that-we-trust problems. Trouble is now I think he wasn't paranoid enough.

That’s a different issue. An important one, I agree, but kind of orthogonal to the introduction of a hardware bug, which could equally happen in an open architecture.

His "origin story" for free software relates to a printer, and being unable to see the code (I think the driver rather than the firmware). His whole point is that software can be changed, and if only a vendor can touch the software for hardware you've purchased then you're entirely beholden to them.

Of course on some occasions the software isn't going to be able to compensate, but Stallman's ideas about why free software is important are grounded in some very practical realities.

Having the source for anything in the cpu here won't help when the architecture design itself is at issue. If you have to respin new silicon, all the software in the world won't help you.

Ever see a wire on pcb boards going from one end of the board to another? Thats the hardware equivalent of a: "we can't fix this properly, but we can hack a fix on until we can fix it right in the next revision" hack.

We're talking about microcode here - this isn't a question of hardware.

If AMD can fix something like this, Stallman would say the end user should be able to as well. He has a point, and the number of useless IoT devices we're already seeing is testament to that fact.

These CVE's have been exploitable for a long time. This is the first open discovery of this golden key to every single computer, everywhere .. but there has been ample time for this to have been catastrophic.

If Intel were open about yes, even the microcode, maybe we would've seen this issue sooner - more openly. What we have is paltry in comparison to the way it would be if, in a Stallman universe, software was 100% open, always.

That's just not true. Having access to the microcode isn't going to help you here, there won't be a line of code you can point to and say 'this is a bug!' Rather, it's the assumptions that all chip-makers have chosen that were wrong, and those choices have been out in the open and known about for all this time. No-one was demanding that speculative execution should be hardened against timing attacks because no-one had discovered that timing attacks were even possible.

Without wanting to side track the the conversation too much, I'm guessing I'm right in my assumption that implementing x86 cores on an FPGA (so we can add wire traces to the cpu after the fact) is still way to slow and expensive to even be close to a reality?

Correct, FPGA simulation of a 3.0Ghz processor means you'd be waiting on the order of weeks to boot into linux.

I work for a company that works with Intel on new things. Lets just say the FPGA's they use are... really expensive, and despite being capable of simulating a design fast, are still very slow.

By expensive I found out $20 million per FPGA simulator was on the low end. And I think that would simulate at the rate of about 10mhz for the amount of transistors/internal setup present.

Fpgas are cool, but a poor choice for fixing this issue.

You could probably do it for up to an 80386 with some $400ish dollar FPGA's.

Weeks! - Thank you, I knewit was slower, but that's such an order of magnitude slower I don't even know how to calculate it :)

Processor bring up is fun to learn about, then you learn you don't want to know how that sausage is made any longer. >.<

Yeah, for something like a modern x86 core, you'd need something like this.

https://www.cadence.com/content/cadence-www/global/en_US/hom...

It'll cost you ~$1M and run at a few MHz.

What initially reminded me of him is the way he uses internet. That seems more and more appealing from this perspective.

For RMS, one does not simply browse a Web page. He has wget fetch the page and then email it to himself, where he looks at it in Emacs.

Given that Spectre is trivially exploitable from motherfucking JavaScript, this bit of craziness turns out to have concealed much wisdom.

So I sent those quotes to Richard Stallman: - https://news.ycombinator.com/item?id=16081602 (this thread's original message) - https://news.ycombinator.com/item?id=16081712 (the parent) - https://news.ycombinator.com/item?id=16081700 ("Stallman is the hero we don’t deserve")

With some encouraging sentences to keep on making the world a better place.

He felt honored. He asked me to post this for him.

"Now that you recognize these problems are real, how about joining in the work to fix them? See gnu.org/help for a list of many different kinds of work that we need (programming is just one of many), then pick one and help!"

I guess along the lines that closed source "security" is an oxymoron.

That’s true to some extent, but it’s not like open source software is free from security issues. Open source might make it easier to find and fix issues, but it can’t avoid them entirely.

Open source is necessary but not sufficient for security. Secure systems are a strict subset of open systems.

IIRC, first generation Intel Atom CPUs are safe from Spectre due to their nature of being an in-order execution design. Those are the most modern/powerful in-order chips I can think of and now I regret selling the old Dell netbook I had in college.

I still have my old MSI Wind U100 from 2010-ish. I was lately wondering what to do with it. It’s already running Mint, so I guess I’ll make it my main machine. :-)

Stallman is the hero we don’t deserve.

Stallman's argument is a good one against the Intel ME issues, but I don't think it apples to Meltdown.

This is a specific side-channel attack in a super complicated system. Even if we had OSS x86/64 processors, this more similar to the protocol issues found in openssl.

Came here to say the same thing.

Richard Stallman was right and I wish we would learn to listen but I doubt that will happen.

A guy living in a cardboard box in an alley rambling on is just as likely to hit upon a semblance of relevance from time to time. Doesn't make them any less of a nutjob or any more worth listening to.

That's not really relevant though. rms is not "some nutjob living in a cardboard box" and his thoughts have proven to be extremely prescient and insightful over and over again. He's definitely "worth listening to" even if you don't agree with him on every single point.

That was a barrel, actually.

Bastard had the nerve to tell Alexander to "stand a little out of my sun."

Total nutjob. No respect for wealth and power whatsoever.

I agree, in principle, but when the nutjob in question correctly predicts a dozen things in a row with no misses, you have to wonder if you might be missing something important.