server_platform_requirements.adoc

Server Platform Hardware Requirements

RISC-V Harts

A RISC-V server platform includes a RISC-V application processor and may include one or more service processors. These service processors may provide services such as security and power management to software executing on the application processors, and they may themselves implement the RISC-V ISA. The requirements in this section apply solely to harts in the application processors of the SoC.

ID#	Requirement
RVA_010	The RISC-V application processor harts in the SoC MUST support the RVA23 ISA profile cite:[RVA23].
RVA_020	The RISC-V application processor harts in the SoC MUST support the following extensions: Sv48 Svadu Sdtrig Sdext Zkr Ssccfg Sscsrind Ssstrict Ssaia
Many of these mandated extensions are optional in the RVA23 ISA profile. This requirement is placed here as a placeholder. These mandates may be moved into a new ISA profile specification.
RVA_021	The RISC-V application processor harts in the SoC MUST support the Ssctr extension with a CTR depth value of 32. Additional CTR depth values MAY be supported.
Mandating implementation of CTR depth of 32 provides a common CTR depth across implementations for purposes of VM migration. Ssctr is under construction.
RVA_022	The RISC-V application processor harts MUST raise an illegal-instruction exception when attempting to execute unimplemented opcodes or access unimplemented CSRs.
RVA_030	The ISA extensions and associated CSR field widths implemented by any of the RISC-V application processor harts in the SoC MUST be identical.
The RVA23 profile supports a set of optional extensions. The set of optional extensions implemented by the harts must be identical. Where the extension supports optionality in the form of field widths (e.g., ASIDLEN, VLEN, allowed vstart values, physical address width, debug triggers, cache-block size, etc.), the implementation of these must also be identical. Having an identical ISA on all harts allows system software to migrate tasks among the harts without constraints.
RVA_040	The RISC-V application processor harts in the SoC MAY support different power and performance characteristics but MUST be otherwise indistinguishable from each other from a software execution viewpoint.
All harts in the SoC being indistinguishable from a software execution viewpoint allows system software to migrate tasks among the harts without constraints.
RVA_050	The RISC-V application processor hart MUST support: Single stepping using the step bit in dcsr Debug scratch register 0 (dscratch0)
RVA_060	The RISC-V application processor hart MUST support: At least 4 instruction address match triggers. At least 4 load/store address match triggers. At least one icount trigger to support single stepping. At least one interrupt trigger. At least one exception trigger. Trigger filtering using hcontext. Trigger filtering using all VMID encodings supported by the hart. Trigger filtering using scontext. Trigger filtering using all ASID encodings supported by the hart.
RVA_070	The RISC-V application processor MUST support at least 6 hardware performance counters defined by the Zihpm extension in addition to the three counters defined by Zicntr extension.

RISC-V SoC

ID#	Requirement
HSOC_010	The RISC-V SoC MUST comply with the Server SoC specification cite:[ServerSoC].
The Server SoC specification is still under construction. This specification should be updated once the specification versioning info is finalized.
HSOC_020	All peripherals that are intended for assignment to a VM or a user space device driver MUST be PCIe devices or be compliant to rules for SoC-integrated PCIe devices (cite:[ServerSoC], Section 2.4).

Peripherals

ID#	Requirement
HPER_010	For remote-access and system engineering purposes, a fully 16550-compatible cite:[NS16550] UART MUST be implemented.
This is a stronger requirement than the Server SoC MNG_030 requirement cite:[ServerSoC]. This specification does not provide guidance around how the UART is physically exposed, i.e. via RS232 signalling, USB, a BMC or other mechanism.
HPER_020	The implemented UART MUST support: Interrupt-driven operation using a wired interrupt. Flow control. 115200 baud operation.
HPER_030	If a USB controller is implemented, it MUST comply with XHCI 1.2 or later cite:[XHCI].
HPER_040	Implemented XHCI controllers MUST support: 64-bit addressing (AC64 = '1'). A 4K PAGESIZE.
HPER_050	If a SATA controller is implemented, it MUST comply with AHCI 1.3.1 or later cite:[AHCI].
HPER_060	Implemented AHCI controllers MUST support: 64-bit addressing (S64A = '1').
HPER_070	A battery-backed RTC or analogous timekeeping mechanism MUST be implemented.
HPER_080	A Trusted Platform Module (TPM) MUST be implemented and adhere to the TPM 2.0 Library specification cite:[TPM20].
HPER_090	MUST include a hardware RNG.

Server Platform Firmware Requirements

ID#	Requirement
FIRM_010	The RISC-V SoC MUST comply with the BRS-I recipe described in the Boot and Runtime Service specification cite:[BRS].
The Boot and Runtime Services specification is still under construction. This specification should be updated once the specification versioning info is finalized.
FIRM_020	MUST include configuration infrastructure, supporting relevant HII protocols (cite:[UEFI] Section 2.6.2)
FIRM_030	SHOULD include the ability to boot from disk (block) device, supporting relevant protocols (cite:[UEFI] Section 2.6.2)
FIRM_040	SHOULD include the ability to perform a TFTP-based boot from a network device and to validate a boot image received through a network device, supporting relevant protocols (cite:[UEFI] Section 2.6.2).
FIRM_050	SHOULD support UEFI general purpose network applications, including IPv4, IPv6, DNS, TLS, IPSec and VLAN features, supporting relevant protocols (cite:[UEFI] Section 2.6.2).
FIRM_060	MUST support option ROMs from devices not permanently attached to the platform, including the ability to authenticate these option ROMs (cite:[UEFI] Section 2.6.2).
FIRM_070	SHOULD support 64-bit Intel architecture (aka x64, aka AMD64) UEFI option ROM drivers for improved compatiblity with third-party IHV ecosystem.
FIRM_080	SHOULD support the ability to perform a HTTP-based boot from a network device, including support for HTTPS and DNS, supporting relevant HII protocols (cite:[UEFI] Section 2.6.2).
FIRM_090	MUST support the installation of Load Option Variables (Boot#, or Driver, or SysPrep#) consistent with cite:[UEFI] Section 2.6.2.
FIRM_100	MUST support the ability to register for notifications when a call to ResetSystem is called, consistent with cite:[UEFI] Section 2.6.2.

Server Platform Security Requirements

Security requirements straddle hardware and firmware.

TBD: it is expected the high-level root of trust / boot flow requirements will come from the platform security spec.

ID#	Requirement
SEC_010	MUST implement UEFI Secure Boot and Driver Signing (cite:[UEFI] Section 32)
SEC_011	It MUST be possible for a physically present user to disable Secure Boot enforcement, thus allowing unsigned code to be executed.
SEC_012	It MUST be possible for a physically present user to fully manage the contents of all Secure Boot key stores (PK, KEK, db and dbx). This includes the ability to delete all factory-provided keys, enrolling their own custom keys, and resetting all key stores to their factory state.
SEC_020	MUST back the UEFI Authenticated Variables implementation with a mechanism that cannot be accessed or tampered by an unauthorized software or hardware agent.
SEC_030	MUST implement in-band firmare updates as per cite:[BRS].
SEC_040	Firmware update payloads MUST be digitally signed.
SEC_050	Firmware update signatures MUST be validated before being applied.
SEC_060	It MUST not be possible to bypass secure boot, authentication or digital signature failures.