Today SiFive is unveiling their platform security architecture called Shield. As with the rest of their offerings, this one is completely open, something SemiAccurate approves of.
Shield isn’t just a block that does security, it is a system based on a silicon root of trust, manufacturing, hardware IP blocks, software libraries, and crypto engines. There are a lot of moving pieces in Shield, lets take a look at a few of them in detail.
Although it is a little hard to read, the slide below shows a lot about what Shield covers. Existing bits like the PMP/PMA (Platform Memory Protection/Platform Memory Access) define what the cores should be able to see and access on the memory front, but those are limited to the cores themselves knowing what is going on. The Cache Attack Protections are hardening against Spectre/Meltdown type attacks and they cover a different attack vector.
Threat models for Shield
As the nice overlapping colors show, Shield is meant to cover the entire SoC. When you want to make sure an accelerator is secure or a compromised process can’t read anything beyond what it has permissions for, how do you do it? If the first two methods of security, PMP/PMA and the Cache Attack Protections do their jobs, there shouldn’t be a need for anything more but, well, this is the real world and hackers are quite clever. These first two don’t cover the scenario where an accelerator or non-CPU resource is compromised either.
That is where the Scalable Domain Security bits come in. They effectively limit what a process can see and do to only what it is supposed to see and do. How does this work? In an overly simplistic way, it tags any packets going onto the bus with a World ID that specifies what process or core that packet belongs to. SiFive calls this WorldGuard. There are two main methods of doing this, each illustrated in a diagram below for a single core or multi-core SoC.
WorldGuard in multi-core scenarios
In the first scenario there is a WID or World ID generated for each core. Memory, peripherals, accelerators, and anything that can DMA are notified with the permissions each core, at least in this case, has. When a packet hits one of those blocks, the WID is checked against what the packet is trying to do. If the WID has rights, everything goes through just fine.
If the packet is trying to mess with an area or device is isn’t supposed to, the SoC detonates and sprays molten hot shards of razor-like shrapnel at the offending user. Just kidding, it just throws a flag and can likely be dealt with in several ways. The important parts are that the transaction does not go forward and some higher authority is notified so action can be taken.
WorldGuard in single core scenarios
That is all fine and dandy for multi-core SoCs but what about a single core device? WIDs based on cores are not all that useful when the options are 1 and 1. That is where the Process ID (PID) based tagging comes in. In essence the hardware will tag a packet based on PID and WID to generate the tags that are then processed like the multi-core tags. In short Shield can generate a WID tag based on origin block, time slices on a core, or both. Once the packet is tagged, the same mechanisms for authorization and notification happen in this mode as well.
In theory any block that recognizes the WID tags can be secured with this scheme. On the SoC itself it is unlikely that anyone implementing Shield will not add the functionality to all relevant blocks so everything on the device should participate correctly. There is no reason this scheme can’t also be extended to external devices via DMA or across networks as well but we won’t consider those scenarios for now.
The WIDs themselves are pretty interesting for something that isn’t much more than a bitmap. WIDs can overlap and a device, block, process can have multiple WIDs. This will allow you to share memory or devices easily and pass messages in a secure or at least private manner. For example you can set up a memory block that is world readable but writable by only a few WIDs, then make others that are private and accessible to only two tasks. The complexity levels and extent of the tagging capabilities seem to be up to the SoC implementer, the good news is the pieces are there and seem to be flexible enough to cover most scenarios.
All of this is mostly useless if the supply chain is attacked and the boards are compromised before they get in to the end user’s hands. SiFive has taken steps to secure the supply chain and has internal and external audit capabilities. Keys can be provisioned at manufacturing time in a secure way as well. In short SiFive appears to be doing all the right things to make sure the devices end up in the right people’s hands in an uncompromised way.
On top of this, SiFive has FOSS crypto libraries and random number generators which should allow external comms to be correctly secured. Linux and FreeRTOS are layered on top of that plus a whole load of software to do the talking with external devices, think TLS and OpenSSL here.
If all goes well, Shield should keep things secure from the point they are made to long after they are deployed. Some of the pieces are available now with major chunks like WorldGuard and some of the hardware protections coming next year. There are even roadmap entries for post quantum cryptography in 2021 so as usual with anything security related, this is only the beginning.S|A
Latest posts by Charlie Demerjian (see all)
- Raja Koduri and Dr. Randhir Thakur out at Intel - Mar 21, 2023
- What does Intel’s Emerald Rapids bring to the fight - Mar 21, 2023
- A new ARM code name for a new market pops up - Mar 20, 2023
- A big ARM server project shut down in silence - Mar 14, 2023
- A bit more on AMD’s Genoa memory issues - Mar 13, 2023