Live data from Hacker News

Is it time for open processors?

lwn.net

91–100 of 236 posts

Re: Is it time for open processors?

#91
post #34

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 o…

> 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.

Re: Is it time for open processors?

#92
post #90
post #72

Earlier quoted context omitted.

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 a…

ARM recently mentioned working on IP that you could turn off features to increase security. Probably will eat little silicon, so could be cheap.Intel may copy. And since it's ARM, it's at least half-open. Cloud providers will be interested - slower cpu's = more money, plus selling the cloud as a more secure option to your data center. And once you have a cpu that with a hardware switch can become more secure but slow…

> And since it's ARM, it's at least half-open.

What do you mean by that?

Re: Is it time for open processors?

#93
post #87
post #72

Earlier quoted context omitted.

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 a…

Russia has the Baikal CPU based on MIPS. China has Loongson also MIPS.

Can either be purchased online by customers outside of those countries?

Re: Is it time for open processors?

#94
post #72
post #34

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 o…

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 a…

State actors and the EU are not reliable actors insofar as security that goes beyond their own needs is concerned. They will put backdoors and key escrow into the systems.

That's the real problem with an open platform, whether it's about hardware or about software. To get enough funding, support, and manpower an open secure platform initiative would have to get entangled with global players that simply do not have the ultimate privacy and security of all citizens in mind. It's primarily a political issue.

Re: Is it time for open processors?

#95

Open Processors is a very bad idea. Look at what's happening to Android. The same thing will happen with CPU's. Every OEM will fork the open design and put all of their stupidity inside it in the name of features and security. Bugs like Spectre and Meltdown will become commonplace. The entire time of kernel devs will be spent working around the various 'features' of the OEM designs. Then someone will come up with a J…

I don't understand why people feel the need to downvote comments, only because they don't agree or they don't want to hear any critical thoughts about something they like.

Anyway, your points are certainly valid. However, they are not a "will happen", but rather a "may happen". In FOSS, it took some time too, to find a working governing structure for large projects. A respected BDFL seems to help. Who knows what would be the best set-up for hardware.

But it should certainly be tried.

Re: Is it time for open processors?

#96

Earlier quoted context omitted.

For me this is an extreme view. If your security demands are that high I'm sure you will find even nowadays CPUs which are in that level of "trustworthyness" you want. One funny example: You can use a Raspberry Pi which is not affected by Meltdown or Spectre ;) https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...

I understand that security is difficult, and that one can never be completely secure. But is wanting to know what my processor is doing, or wanting it to be free of undocumented, obfuscated, proprietary code that runs at a higher priority than any software, really that extreme a view? We base so much of human progress on these little wafers of silicon, it shouldn't be extreme to want to know what they do.

>We base so much of human progress on these little wafers of silicon, it shouldn't be extreme to want to know what they do.

Well said. I'll add that security is a threshold, and that computer systems are extremely complex. Every bit of openness -and the verifiability such openness affords- brings us closer to that ideal secure system.

Re: Is it time for open processors?

#97

Earlier quoted context omitted.

Almost all code today is written in languages that run in vms(java, .net), are interpreted (python, ruby, js), or easily compile across cpu architectures. Operating systems are a different story but changing the underlying ISA is really not a huge deal IME it’s harder to port to a new os than a new ISA.

A lot of code is, but are you really going to ignore C++, Go, Rust, etc? Most games are written in C++, as are most large desktop apps.

All of them quite portable, with enough abstraction libraries available to make it a moot point, unless I really want to dive into details.

The only programming language I actually do have care about the underlying OS is C, due to its dependency on POSIX as an extension of ANSI libc.

Re: Is it time for open processors?

#99
post #92
post #90

Earlier quoted context omitted.

ARM recently mentioned working on IP that you could turn off features to increase security. Probably will eat little silicon, so could be cheap.Intel may copy. And since it's ARM, it's at least half-open. Cloud providers will be interested - slower cpu's = more money, plus selling the cloud as a more secure option to your data center. And once you have a cpu that with a hardware switch can become more secure but slow…

> And since it's ARM, it's at least half-open. What do you mean by that?

ARM did release a very detailed, machine checkable specification(that they themselves use to verify security with), to everybody:

https://news.ycombinator.com/item?id=14174533

Re: Is it time for open processors?

#100
post #72
post #34

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 o…

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 a…

It's not a worthwhile project when 99% of your vulnerabilities are in the software and nearly all of them need you to run untrusted software to be exploited.

"Browsing the web" is not likely to become a task that can satisfy high security requirements ever again. Too much cruft gets added to browsers faster than it can be thoroughly audited.

If you need absolutely no CPU bugs (including bad design decisions "working as intended"), take a well-understood, possibly older design like 680x0 or MIPS and run it on an FPGA.

Post reply on HN