SoylentNews is people
SoylentNews
Spotted over on Phoronix:
While free software/hardware advocates have been ecstatic about the RISC-V open-source, royalty-free processor architecture, hardware so far hasn't been as open as desired.
While this processor ISA is entirely open and living up to its merits, it turns out the RISC-V implementations so far haven't been quite as open as one would have thought. A Phoronix reader pointed out to us some remarks by developers on the main RISC-V development board out so far, the SiFive HiFive Unleashed
Ron Minnich who has run the Coreboot project for more than the past decade and spearheads the effort of getting Coreboot on new Chrome OS devices at Google, commented on the Unleashed development board this weekend:
All this said, note that the HiFive is no more open, today, than your average ARM SOC; and it is much less open than, e.g., Power. I realize there was a lot of hope in the early days that RISC-V implied "openness" but as we can see that is not so. There's blobs in HiFive.
Open instruction sets do not necessarily result in open implementations. An open implementation of RISC-V will require a commitment on the part of a company to opening it up at all levels, not just the instruction set.
The issue stems from the use of third party IP used to complete the SoC as Risc-V is an instruction set, not a physical hardware design. The actual silicon of the CPU must be designed in order to implement the instruction set as actual hardware and glue logic to tie the CPU to other hardware like memory and bus controllers. In the case, the HiFive Unleashed features a DRAM controller from Cadence which uses a proprietary binary blob to initialize the DRAM controller. This makes open firmware implementations legally difficult.
(Score: 0) by Anonymous Coward on Tuesday June 26 2018, @04:30AM
"Womp, womp."
(Score: 0, Flamebait) by MichaelDavidCrawford on Tuesday June 26 2018, @05:03AM (4 children)
You say that like it's a bad thing.
Yes I Have No Bananas. [gofundme.com]
(Score: 4, Insightful) by stormwyrm on Tuesday June 26 2018, @06:04AM (3 children)
It *is* a bad thing. It means one more thing that can't be easily audited for correctness and security independently: one more place for bugs and security loopholes to hide. It means one more thing that can't be changed easily or safely. One more thing that we can't study and learn from that anyone who wishes to to can improve on. If you don't see these as bad things, you must have a great deal more confidence and trust in the makers of proprietary systems than they deserve [gnu.org], from how they have so abused their position.
Numquam ponenda est pluralitas sine necessitate.
(Score: 5, Insightful) by ledow on Tuesday June 26 2018, @07:23AM (2 children)
A proprietary binary blob interacting with the DRAM controller and putting it into an unknown state basically completely compromises any guarantees of memory isolation whatsoever. While you're sitting there worrying about Rowhammer, and process separation, that blob is able to act upon commands to bypass any and all restrictions the DRAM controller might have, and read the entirety of memory.
"Only in theory", sure, but that's when you find out things like "3DFX drivers on Windows installed as admin and then allowed arbitrary DMA to any memory location whatsoever without permission", "This poorly-initialised chip in this model of machine allows full memory access and, thus, complete kernel compromise", "Attackers can use your firmware to gain privileged access through an undocumented opcode", "this TPM compromise came about using a third-party support chip with an insecure firmware", and so on. This is how that stuff gets into things like Intel's lights-off firmwares and things... and stays there until every chip on the market is vulnerable. Because nobody can see it, nobody can check it, nobody can verify it does what it claims, and nobody can patch it if it goes wrong (the manufacturer could put out an updated firmware, but only on their schedule).
When processors themselves are allowing compromise of all the virtual machine guarantees, memory protection guarantees, prediction branch security, etc. then the last thing you need is yet-another-chip running yet-another-blob that you have no idea what it's doing.
(Score: 1, Redundant) by MichaelDavidCrawford on Tuesday June 26 2018, @01:21PM (1 child)
BEHOLD:
https://www.google.com/search?source=hp&ei=lz0yW-XKMJmz0PEP3pKJ2A0&q=site%3Asoylentnews.org+%22you+say+that+like+it%27s+a+bad+thing%22&oq=site%3Asoylentnews.org+%22you+say+that+like+it%27s+a+bad+thing%22&gs_l=mobile-gws-wiz-hp.12...7260.7260..9534...0....95.95.1......0....1j2.......3..41.hr8XGqHGbkk%3D [google.com]
Yes I Have No Bananas. [gofundme.com]
(Score: 1) by Sabriel on Thursday June 28 2018, @03:23AM
I find it amusing that when I click your link, I get the following SSL error:
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
(Score: 3, Insightful) by maxwell demon on Tuesday June 26 2018, @05:11AM (3 children)
As opposed to non-binary blobs?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Tuesday June 26 2018, @05:13PM (1 child)
Yes, there really are only two choices here.
(Score: 2) by maxwell demon on Tuesday June 26 2018, @05:17PM
So what is a non-binary binary large object?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by Sabriel on Thursday June 28 2018, @03:51AM
Depends on what definition you're using for blob.
In the sense of "a module of code that performs a task", you could also have (for example) a proprietary pascal blob. While still legally encumbered, it would be considerably easier to audit.
(Score: 2, Disagree) by qzm on Tuesday June 26 2018, @05:23AM (2 children)
Talk about a clickbaiting article.
RISC-V is open, which means anyone is free to implement it, THAT is the point of it.
What is being complained about here has NOTHING WHAT SO EVER tyo do with the openness of RISC-V, and smells more of someone trying to create some political pressure to get what they want.
Their issue is actually with the system peripherals implemented on a SOC (system on a chip) next to the core, and THOSE are not RISC-V.
Now, that is a common problem, that GPUs, memory interfaces, external busses, etc may not be as open as the CPU next to them, but ffs, that has NOTHING to do with RISC-V being open.
It is like claiming the Linux kernel is not open because a particular distribution contains some binaries without source (not even in the kernel)..
Still, decent journalism, decent technical reporting, and critical thinking all seems to have sailed past quite some time ago, so why not.
(Score: 5, Insightful) by ledow on Tuesday June 26 2018, @07:31AM
These people are piggy-backing on an "open" project and then closing it.
This is not "RISC-V is closed". This is "these people are closing it for their own purposes / laziness", and people need to be aware of that.
If something appears in a shop with RISC-V on it, and people have been taught to associate RISC-V with "open", that's not going to end well when the binary blob contains a root-level compromise that nobody can see / fix until it's too late, is it?
Also, there's no point having an open architecture if even a handful of the actual, physical examples you can realistically buy are not open. It just defeats the entire point.
That's not to say they've done anything illegal, it just leaves a sour taste. They are taking and not giving back. And there are other DRAM controllers they could have used, and other ways they could have implemented them.
Fact is that the RISC-V "open" architecture in any OS now has to carry around a bunch of closed-source binary blobs if you want it to boot on the machines that you can buy implementing that architecture. So... what's different between that and a Raspberry Pi, or an Intel, or anything else?
If it were the graphics core, or the networking chip, or something completely secondary to the operation of the machine, you could avoid it, disable it, substitute it, etc. But it's the DRAM controller. The machine won't even turn on for more than a second without initialising that.
It might be one model, one business decision, etc. but if that creep is allowed to continue then RISC-V as a practical, implemented architecture (i.e. the bits people can actually BUY) will lose its main advantage and be no different to anything else currently on the market. That's a lot of hard work down the drain.
Combat it now, and you may yet still keep RISC-V and its implementations clean, by putting pressure on the company to licence and open that blob, or replace it with something equivalent.
(Score: 4, Informative) by Anonymous Coward on Tuesday June 26 2018, @07:53AM
The Phoronix title:
The Soylent title:
Which of these are clickbait? Which of them claims RISC-V is not open? Both refer to current hardware implementations. Please do not invent clickbait in your head, there is enough to go around.
(Score: 0, Informative) by Anonymous Coward on Tuesday June 26 2018, @08:00AM
There are a dozen forum threads related to the controllers all explaining that they can only be released once the hardware reaches gold and the sources can be handed over to audit. IBM's OpenPOWER did the same thing with their controllers.
As for the third-party bits, yeah, wasn't that obvious? I mean, it's just the cores and ISAs that were opened in the first place. You don't get the hard disk rotor controller's sources either... Seriously there's a lot of third party content in any given design (on or off SoC) that just can't be made open by any one party. It's why RISC-V is so promising: The modular design lets you bundle those blobs without having to close up the bits of your design you want to open. With OpenPOWER you have the audit section and the third-party disclosure sections that conflict with most licenses and NDAs so you end up having to use IBM's stuff unless you can do it all yourself...
Seriously all of this been discusses to death years ago whenever OpenPOWER and lowRISC were mentioned... What's with the surprised faces people?
(Score: 0) by Anonymous Coward on Tuesday June 26 2018, @05:01PM (2 children)
Since we let government officials, right down to the street cop, break the law, we are allowed to show the same contempt (Si tu fumas yo puedo fumar tambein [youtube.com]). So, let's not worry if our firmware or software, or anything else is 'legal' or not. Just do your development and distribution anonymously, which means also you will need wide area network access without an ISP. HINT HINT!.
(Score: 2) by maxwell demon on Tuesday June 26 2018, @05:24PM (1 child)
How do you download hardware over the internet?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Tuesday June 26 2018, @07:49PM
You have to produce the hardware yourself, from downloaded plans. Oh wait, no 3D printers and desktop smelters yet? Looks like somebody needs to get busy...