Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday June 26 2018, @03:49AM   Printer-friendly
from the not-there-yet dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0, Flamebait) by MichaelDavidCrawford on Tuesday June 26 2018, @05:03AM (4 children)

    by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Tuesday June 26 2018, @05:03AM (#698606) Homepage Journal

    You say that like it's a bad thing.

    --
    Yes I Have No Bananas. [gofundme.com]
    Starting Score:    1  point
    Moderation   -2  
       Flamebait=2, Total=2
    Extra 'Flamebait' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   0  
  • (Score: 4, Insightful) by stormwyrm on Tuesday June 26 2018, @06:04AM (3 children)

    by stormwyrm (717) on Tuesday June 26 2018, @06:04AM (#698611) Journal

    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)

      by ledow (5567) on Tuesday June 26 2018, @07:23AM (#698631) Homepage

      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.