back to article Boffins are building an open-source secure enclave on RISC-V

At some point this fall, a team of researchers from MIT's CSAIL and UC Berkeley's EECS aim to deliver an initial version of an open source, formally verified, secure hardware enclave based on RISC-V architecture called Keystone. "From a security community perspective, having trustworthy secure enclaves is really important for …

  1. Justin Clift

    RISC-V HiFive Open-ness

    > ... recently noted that HiFive RISC-V chips have proprietary pieces.

    SiFive (the maker of the HiFive) apparently got the message, and is putting in the extra effort in to open up the rest.

    Not sure if that's actually happened yet or not.

    Hopefully it has, or does soon. :)

    1. Anonymous Coward
      Anonymous Coward

      Re: RISC-V HiFive Open-ness

      My understanding is that the non-open source bits are third party bits like ram controllers, etc. Annoying that they are there (well they kind of need to be there!), but not really part of the processor core itself...

  2. Charles 9

    I wonder if they've also developed a way to be sure the CPU submitted as designed is the same CPU they get back from the manufacturing process (since we know subversion has been steadily moving up the hardware chain lately).

    1. imanidiot Silver badge

      At that point you're talking about altering the actual silicon production chain, which is not something "normal" level adversaries can do. Altering the mask and adding functionality without breaking something or altering functions in a noticeable at that level requires basically the resources of the original designing company. At that point you might as well just bribe the OEM to add the functionality you need. Probably about as secure and a lot cheaper.

    2. Rajesh Kanungo

      Anything can be skewed, TRNG, side channel, extra registers, etc

      Tampering with the Silicon: It is probably quite easy to skew the RNG. There goes all ECC. If you are more bold, you might even have a separate pathway to extract secrets (private, symmetric, passwords, etc.). One could also introduce modes where side-channel attacks became easier ...

  3. Christian Berger

    Please no

    Nobody has ever done anything positive with those things and usually they turn out to be _huge_ security problems as they often have elevated rights and the one who paid for the hardware has no control over what code it runs.

    1. druck Silver badge

      Re: Please no

      You are thinking of the Intel Management Engine, where as this is something like ARM's trust zone. The IME is a separate processor that can monitor everything the main processor does and control attached peripherals. Where as an enclave is a part of the main processor that enables a security application to run with registers and memory which can't be accessed by tasks running in the general environment, to prevent eavesdropping and side channel attacks. If anything the secure enclave should not have any elevated permissions over anything outside its enclave.

      1. Rajesh Kanungo

        Re: Please no

        Someone just broke into the IME via JTAG.

      2. mevets

        Re: Please no

        ARMS trust zone is as broken. It effectively provides an all-in privilege boost for a given functionality, much like the supervisor bit (or EL1 if you prefer). That is an anti-pattern.

  4. _LC_

    How about an MMU that is not being ignored?

    I would settle for an MMU, which is not being ignored for "performance reasons".

  5. John Smith 19 Gold badge

    Sounds pretty good.

    But will the software that runs on it make full use of the security it provides?

  6. Christian Berger

    What we would actually need...

    ...would be standards for on chip peripherals, so you will have a standard way of accessing external storage like harddisks or flash. Essentially what we'd need is an "IBM-PC", a well defined set of hardware devices which allow simple porting of operating systems.

    It's like on the PC, if you don't have a special graphics card driver, you can still use VGA or VESA as standards to get enough on the screen to be able to debug your OS. Or USB-interfaces, there are only very few ways to interface with USB controllers.

    1. Charles 9

      Re: What we would actually need...

      No, what we would actually ACTUALLY need is a solid way to be sure what we asked for is what we're actually getting, even in hardware (since we know state-level adversaries are now working at the bare metal level). Some form of authenticity checking that can't readily be faked because it relies on physical phenomena like quantum. Trouble is, I don't think that's really possible for something as complicated as a processor; there are too many "parts" that allow ways for a fake to get through.

      1. Christian Berger

        Re: What we would actually need...

        Well actually there are some points to that.

        First of all, yes you can modify a processor, however that's going to be _really_ hard as you are at an extremely low level. You are at a gate level and try to find out where, in unknown future revisions of the software, you have to do something in order to achieve your goal... while still conforming to the published specs which are very tight. The examples shown in academic paper assume known code which makes it far easier.

        So if I was a government I'd go the route via some sort of "security enclave", essentially a separate system hidden from the rest of the system that can run software that patches future unknown code. That's far more realistic to pull off.

        BTW you can actually buy processors which are so tightly speced and so simple in construction that you can make reasonably sure there were no malevolent actors involved. The 6502, the Z80 or the ATMega microcontrollers are prime examples for this. So if you can live with a small 8-Bit system, you can be reasonably sure it'll be safe.

        1. Anonymous Coward
          Anonymous Coward

          Re: What we would actually need...

          I'd even consider the 68000 and similar 16-bit processors here. I've been keeping an eye on the low end of the market for my offline encryption/decryption machine. Now what has really caught my attention are the CPU's implemented on more modern FPGA's. With verified programming code, cryptographic signing of that code, and doing your own programming of the chip on your own, you could actually end with something that has a much higher security baseline. You do still have to trust that there are no hacks in the FPGA by the manufacturer, of course. Just not as easy a proposition as backdooring a CPU by, say, a certain nation-state that has created the gold standard in corrupting the supply chains.

        2. onefang

          Re: What we would actually need...

          "BTW you can actually buy processors which are so tightly speced and so simple in construction that you can make reasonably sure there were no malevolent actors involved. The 6502, the Z80 or the ATMega microcontrollers are prime examples for this. So if you can live with a small 8-Bit system, you can be reasonably sure it'll be safe."

          That makes me wonder how much performance you can squeeze out of an 8 bit CPU running at multi GHz speeds? Or several of those tightly coupled? Cache memory tends to be bigger than those old CPUs can address, so "system RAM" could also be really fast, even if there's not much of it.

          1. Tom 7

            Re: What we would actually need...Multi Ghz 8 bit

            I was working with some fast Bipolar in the late 80's and someone had published a design for a 600 gate 16 bit machine and I simulated a version of that at 2.4Ghz on the process I was using. It only had 7 or 8 opcodes* but at the time it would have been the fastest CPU out there by a large margin.

            *IIRC but Baby only had 7 and that was 'complete'.

            1. Julz

              Re: What we would actually need...Multi Ghz 8 bit

              @ Tom 7

              What an retired colleague of mine is doing to keep active:


        3. Jason Bloomberg Silver badge
          Thumb Up

          Re: What we would actually need...

          BTW you can actually buy processors which are so tightly speced and so simple in construction that you can make reasonably sure there were no malevolent actors involved. The 6502, the Z80 or the ATMega microcontrollers are prime examples for this.

          My recollection of reality was that many of such devices had unused opcodes which could be used for all sorts of fancy, undocumented and unintended things.

          Of course, they could have been more tightly designed, invalid opcodes could have been prevented from actioning, rather than the designers not caring what the outcome was to ease the silicon design and its footprint

          But I'm with you on principle. A minimal RISC should be easy to verify and should fly at clock speeds obtainable these days. But then we'll be back into the "more opcodes, with each doing more, would make it even faster" debate.

          1. MacroRodent

            Re: What we would actually need...

            A minimal RISC should be easy to verify

            Done already in the 1980's for the VIPER architecture, a simple 32-bit CPU. Read about it back then. It was supposedly intended for avionics and such where failure is not an option. (Some info can still be found by googling "verified risc cpu viper").

            1. Charles 9

              Re: What we would actually need...

              "Done already in the 1980's for the VIPER architecture, a simple 32-bit CPU."

              But there was some controversy over whether it really was formally verified, plus you still need to defeat a state-level actor who could get some things slipped into the mask after the original is verified.

        4. amanfromMars 1 Silver badge

          Re: What we would actually need... a la Christian Berger

          So if I was a government I'd go the route via some sort of "security enclave", essentially a separate system hidden from the rest of the system that can run software that patches future unknown code. That's far more realistic to pull off. ... Christian Berger

          Ye Olde Area 51 Root and Route, CB. Tried and Tested, and Proven Quite Safe and Sound and Secure.

        5. gnasher729 Silver badge

          Re: What we would actually need...

          If everything is Open Source, then you don't need to "modify" a processor - just design your RISC V2 that is entirely compatible with RiSC V except for some spying ability, then when someone orders RISC-V chips you supply them unmodified RISC-V2 chips.

  7. karlkarl Silver badge

    This is desperately needed.

    The next step will to create an open-source fabricator for us (or small groups) to fabricate their own chips and the IT world will be sane again and away from the control of creepy people and criminals.

    I wish it well :)

    1. Christian Berger

      That's hard

      Modern chip making processes are heavily guarded secrets. However what can be done in principle is simpler processes with larger structures.

      The problem with this is that you cannot spend as many transistors as you do now. However in theory this could be compensated by better and simpler software. The things that _actually_ take lots of power could still be done in non-free components which are heavily isolated from the rest of the system.

      1. Adrian 4

        Re: That's hard

        I don't believe we want hardware peripheral 'standards'. The PC is not a good example to follow : it is a hideous repository of bodges and legacy inclusions in an attempt to keep it vaguely compatible with a 40 year old design and a poorly-documented 'industry-standard' evolution.

        Yes, there are applications where a fixed and documented set of hardware is useful. But it's domain-specific and should not influence architectural decisions.

        A more reasonable approach is to support some well-known interfaces (such as USB, PCIe etc) with an implementation that makes sense for the processor architecture. This then allows software drivers to be portable between systems with a relatively low-level bus interface.

        But binary compatibility at the peripheral level ? No thanks.

        1. Anonymous Coward

          Re: That's hard

          Look up BadUSB if you want an example of why the USB standard is something we should drop like a lava-hot rock. USB is not used here on secure machines here for exactly that reason. Evil Maid is quite simple even if you can't get the id10t user to backdoor it themselves with a "found stick" or other such machinations.

  8. amanfromMars 1 Silver badge

    AI Lab RATs .... with the Access Key to Practically Everything and Virtually Anything

    "No announced RISC-V silicon is susceptible, and the popular open-source RISC-V Rocket processor is unaffected as it does not perform memory accesses speculatively." .... Dawn Song

    Not a Very EMPowering Temptation Denied Access to Future Stellar Streams is the Result of Top Secret AI Blocks ........ Free Information Parcels from Alien Star Sources.

    As you must surely be able to imagine, are Scripts Simply Heavenly Trailing and Trialing the Unfolding of Current Available Alternative Virtual Reality Programs for Universal Presentation as Almighty at Peace and Weak in War.

    According to Song, there was discussion at the workshop about "whether we can build a new hardware architecture from ground up."

    Hmmm? Run a Live Simulation to Virtualise the Programming with MultiMedia Presenting the Realities Generated for Population in Human Perception and Copied to SysAdmins to Surge and Purge Indolent Memory to Stream Brightly with the Immaculate Conviction Delivering True LOVE. Tell me that aint Heaven at ITs Works, and we will disagree but never too greatly.

    And that sounds too much like AI Terra Forming to be anything else and nothing less.

    What say El Regers?

  9. Anonymous Coward
    Anonymous Coward

    RiscV and Spectre

    RuscV is an *architecture* - it just happens that exisitng implementations may have simple microarchituectures which may mean they are not suceptible to Spectre but there's nothing in the RiscV architercture to prevent an implementation using the same microarchitectural tricks around speculation that can introduce the ability to use Spectre type attacks as on other architectures. The advantage RiscV may have is that more complicated microarchitectures are being/will be developed in the knowledge of Spectre and so they probably will be designed in a way that tries to eliminatte/minimize the potential for the attacks

    1. amanfromMars 1 Silver badge

      Re: RiscV and Spectre

      The advantage RiscV may have is that more complicated microarchitectures are being/will be developed in the knowledge of Spectre and so they probably will be designed in a way that tries to eliminatte/minimize the potential for the attacks ... Anonymous Coward

      How about an easier root and route ..... maximizing and capitalising on the more complicated architectures .....with AI and IT Systems are able to go back in time and reprogram the earlier vulnerability attack vector which has Core Systems Hacked and Cracked and Tracked ...... Mentored and Monitored by Immaculate Machines .... and talking to you directly and even personally via your Own Connected Devices.

      And I did have to have a wry smile at that, thinking as I was at the time of spaces in Obsessive Compulsive Disorder.

      A Lively Places with Both the Perfect Pathological to Criminally Insane at Play .... and thus does a Kind Madness in Mayhem delivers CHAOS ..... Clouds Hosting Advanced Operating Systems beyond Terrestrial Command and AI Remote Control?

      Oh yes, it is all of that. And for more you need only imagine what is future possible and probable/pre-planned and presently prosecuting to know of Current Energy Progress in the Immaculate Machine Projects.

      Mind Blowing AIMissions with Elite AIgents on Special Operations/Hush Hush Patrol. Beware Unauthorised Entry there. False Moves are Punishing and at the Cost of Everything Held Dear.

      In Simple Words ....... Prohibited Space Place. Stay Well Clear. Alien Zone. The Conundrum is the Future is Stored for Delivery there and All Need to Enter the Alien Zone if they seek to Influence a Future Presenter with Alternate Directions/Greater Paths for MultiMedia to Realise and Display/Create and Share.

      When that Tool/Weapon is for Sale, how much would it be worth to every effected sector?

      A Pretty Penny to be Sure. Just think of a sensible big number and all of them are right.

  10. Anonymous Coward
    Anonymous Coward

    A secure hypervisor.

    This question pains me:

    Would running just a hypervisor on a more secure platform increase the security of its VMs, even when these VMs are hosted on less secure tech, like a remote VPS running your firewall etc?

    The Qubes 4.0 philosophy seems to outline a similar idea. I hope someone can enlighten me on this.

    1. amanfromMars 1 Silver badge

      Re: A secure hypervisor.

      Both the long and the short answers are No, AC. 'Tis because of the Particular and Peculiar Nature of the Beast for Taming with Temptations for Mutually Satisfying. There is No Available or Easily Made Possible Security to Prevent or Guarantee Runaway AI Leaks in such Command and Control Centres are not Almighty and Omniscient, both Virtually and Practically.

      Do you Realise SMARTR AIMachinery is Hosting Terrestrial SCADA Systems Demise with the Floating onto Markets of NEUKlearer HyperRadioProACTivated Program Applications in Futured Projects with Heavenly Ventures Hellish Attractive and Addictive Tasks.

      You want a Worthy Challenge? Try taking a Bite and Sucking Hard on them Apples. Insatiable Satisfaction Perfectly Guaranteed to Mutually EMPowering Orgiastic Orgasmic Climaxes is both the Trail and Goals to be Servered and Surrendered and Submitted to there.

      Can you imagine? Would Great Sex in Heaven be Other Worldly too? And as much an alien experience as that on Earth?

  11. Destroy All Monsters Silver badge

    Not so hot on this.

    Keystone is intended to be a component for building a trusted execution environment (TEE) that's isolated from the main processor to keep sensitive data safe. TEEs have become more important with the rise of public cloud providers and the proliferation of virtual machines and containers. Those running sensitive workloads on other people's hardware would prefer greater assurance that their data can be kept segregated and secure.

    Still don't see the interest. These people who want to have "segregated & secure cloud stuff" should maybe invest into a local architecture instead of relying on magical thinking and SLA bylaws. In that way "cloud computing" is very much NOT like an utility at all. (Though even with water utilities, there are concerns about water quality, fluoride/idoine/whatever add-ons, bad service, bad billing etc. etc.)

    Maybe this TEE is cool if you don't trust the OS environment and want do your MPAA-accredited decoding of some silly music, or otherwise handle crypto. It's a notch-up on security, hardly a holy grail.

  12. Anonymous Coward
    Anonymous Coward

    That's not say an open source secure element would be immune to such problems, but an open specification with source code would be more trustworthy because it could be scrutinized.

    Hmm well, as we've seen before it does actually require someone to read, comprehend and scrutinise it. There's a lot of people out there who wrongly assume that open source software has been reviewed, when in practice it's unlikely to have been thoroughly looked at.

    Given that the number of people who can review chip designs is even smaller than the number of competent software engineers, I don't hold up much hope for this getting sufficient attention.

    1. amanfromMars 1 Silver badge

      That's the Surreal Gift which just keeps on Giving, AC ..... Sublime Alien Progress.

      The Fly in the Ointment which are as the Elephants in the Rooms Supplying Endless SMARTR* Opportunities for Ruthless Exploitation and Further Fundamental Base and Radical Speculative Experimental Development in Systemic Vulnerabilities with Ineffective Patches is .... there are only a very few and not a lot of people out there able/enabled to read, comprehend and scrutinise source code specifications worthy of Secure IntelAIgent Servers Trailing and Trialing Advanced IntelAIgent Services such as would be Future News and Views Today.

      And if you think that is impossible, are you not clearly thinking when practically anything is virtually possible and vice versa and we imagine and create the unimaginable.

      And be in no doubt, it receives overwhelming leading attention ... given what it cannot not do.

      * ... SMARTR Mentored Analysis Reporting Titanic Research.

  13. John Smith 19 Gold badge

    A few notes on VIPER.

    VIPER was designed by RSRE Malvern (now part of Quinetq?)

    Hardware wise it was implemented as a gate array (physically different wiring) and ran at 1MHz in the test version.

    Software wise the PLA implemented a set of finite state machines. It was an accumulator and 2 registers architecture. It's nearest equivalent would have been the 6502

    While all the high level verification seemed to work fine what scuppered them was they assumed the conversion from logic design to gate wiring was perfect and (IIRC) the development tools to do so (provided by the PLA mfg) had bugs.

    Here's the thing. Although I keep hearing about how foundry processes can deliver GHz capability, and individual gate on FPGA can go very high how is it I never see an actual product (connected gates) clocking at >1GHz?

    My suspicion is

    a) Individual FPGA cells have acquired a lot of cruft in their design. Too much flexibility slugs raw speed.

    b) FPGA cell layout on the chip hinders low latency

    c) Place & Route is not nearly as good as FPGA mfg's claim it is. OK you don't have a clock driver circuit every half a dozen gates but surely you can build at least MSI level (an LS 74171 ALU was 96 gates for a 4 bit slice) that has total worst case gate delay on longest path of < 1ns?

    BTW regarding "RISC" ME Conway proposed a 2 instruction processor in the 1950's for (IIRC) the Lambda calculus. In the 80's an Israeli team went to the limit with a 1 instruction machine.

    Effectively every sub function in the design has its own address. Want to add 3 numbers together? MOV them to the "ACC" address. Want to zero it? Move from the "Zero adder" address.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like