Uncategorized

ARM pulls RISC-V web site?

Re: https://firmwaresecurity.com/2018/07/10/arm-basics-com-arm-architecture-understand-the-facts/

and https://firmwaresecurity.com/2018/07/09/arm-on-risc-v-five-things-to-consider-before-designing-a-system-on-chip/

it appears ARM pulled the site. I can’t see this site anymore:

https://www.riscv-basics.com/

But the Wayback Machine appears to have made a snapshot:

https://web.archive.org/web/20180710134510/https://riscv-basics.com/

https://www.theregister.co.uk/2018/07/10/arm_riscv_website/

Standard
Uncategorized

ARM on RISC-V: Five Things to Consider before Designing a System-on-Chip

https://www.riscv-basics.com/

PS:

http://arm-basics.de/

Standard
Uncategorized

SiFive: DDR controller configuration register values unleashed!

Re: https://firmwaresecurity.com/2018/06/25/risc-v-implementations-filled-with-blobs/

https://forums.sifive.com/t/ddr-controller-configuration-register-values-for-hifive-unleashed/1334/8

Comment from SiFive:

SiFive is committed to supporting the open-source community. We are pleased to report that after discussions with our IP partners, we are now able to make available all the source code required to initialize the HiFive Unleashed board. The board’s boot sequence is described in the manual. The assembly code in the initial reset ROM is listed in the manual Chapter 6.1 “Reset Vector”. The firmware in the ZSBL mask ROM is directly readable by software on the chip, and we will be making the full source code available shortly. The source code for FSBL including the DDR initialization will also be available shortly. We can attest there is no other firmware run by the system during boot.

Standard
Uncategorized

coreboot for HiFive Unleashed

Re: https://firmwaresecurity.com/2018/06/25/risc-v-implementations-filled-with-blobs/

https://github.com/hardenedlinux/firmware-anatomy/tree/master/bin_blobs/hifive_unleashed

Standard
Uncategorized

RISC-V: Secure Boot and Remote Attestation in the Sanctum Processor

Cryptology ePrint Archive: Report 2018/427

Secure Boot and Remote Attestation in the Sanctum Processor

During the secure boot process for a trusted execution environment, the processor must provide a chain of certificates to the remote client demonstrating that their secure container was established as specified. This certificate chain is rooted at the hardware manufacturer who is responsible for constructing chips according to the correct specification and provisioning them with key material. We consider a semi-honest manufacturer who is assumed to construct chips correctly, but may attempt to obtain knowledge of client private keys during the process. Using the RISC-V Rocket chip architecture as a base, we design, document, and implement an attested execution processor that does not require secure non-volatile memory, nor a private key explicitly assigned by the manufacturer. Instead, the processor derives its cryptographic identity from manufacturing variation measured by a Physical Unclonable Function (PUF). Software executed by a bootloader built into the processor transforms the PUF output into an elliptic curve key pair. The (re)generated private key is used to sign trusted portions of the boot image, and is immediately destroyed. The platform can therefore provide attestations about its state to remote clients. Reliability and security of PUF keys are ensured through the use of a trapdoor computational fuzzy extractor.

We present detailed evaluation results for secure boot and attestation by a client of a Rocket chip implementation on a Xilinx Zynq 7000 FPGA.

https://eprint.iacr.org/2018/427

https://eprint.iacr.org/2018/427.pdf

Standard
Uncategorized

On the Path to a Secure Boot Solution for RISC-V

On the Path to a Secure Boot Solution for RISC-V
By SecureRF | April 26, 2018 | 0

As the RISC-V ISA gains in popularity and more industries proceed with plans to build and deploy systems based on RISC-V technologies, the security requirements of those systems will grow. One avenue that hackers have used to exploit systems has been to modify the firmware and cause it to misbehave. For example, one of the recent vehicle hacks involved corrupting firmware in order to jump from an infotainment center to the CAN-BUS. The solution to this style of attack is a secure boot, and with minimal additions to the ISA, RISC-V can provide secure boot hooks directly. Secure boot is a self-hosted root of trust that uses a digital signature and a known, trusted, public key to protect the firmware before it loads. The RISC-V system validates the signature over the firmware using the trusted public key and will run the code only if the signature verifies correctly. If the firmware has been modified in any way, the signature validation will fail. Once this initial trusted load completes, subsequent loads can use the same process to chain the trust to additional loads.[…]

https://www.securerf.com/path-secure-boot-solution-risc-v/

Standard