The kvmtool guest firmware is using the default RNG library
defined in ArmVirtPkg.dsc.inc which is BaseRngLibTimerLib.

BaseRngLibTimerLib is only present to use for test purposes on
platforms that do not have a suitable RNG source and must not be
used for production purposes.

Armv8.5 introduces random number instructions (e.g., RNDR) which
return a 64-bit random number. Although, this feature is optional,
it can be assumed that most modern platforms will implement this
support. This feature i.e. FEAT_RNG can be discovered by examining
the processor feature registers.

It is therefore desirable to use the RNDR instructions instead of
using the default BaseRngLibTimerLib which is unsafe.

The BaseRngLib in MdePkg already implements the RNG support using
RNDR. However, it is worth noting that FEAT_RNG is supported in
AArch64 state only. Therefore, switch to using the BaseRngLib
instance for AArch64 firmware builds. The AArch32 firmware builds
will continue to use BaseRngLibTimerLib.

Note: The guest firmware already supports Virtio RNG. So, should
the processor not implement FEAT_RNG, the guest firmware can fall
back to use Virtio RNG.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The BaseRngLib library constructor for AArch64 asserts if the
RNDR instruction is not supported by the CPU. This approach to
warn about the unsupported instruction may be suitable for the
host platform firmware. However, for a guest firmware the only
mechanism to discover the supported RNG interface is by probing
the processor feature registers.
The guest firmware may therefore assume that RNDR instruction
is supported and if the probe fails, fall back to an alternate
RNG source, e.g. Virtio RNG.

Therefore, replace the assert with a warning message to allow
the guest firmware to progress.

Note:
 - If RNDR instruction is not supported, the GetRandomNumberXXX
   functions will return FALSE to indicate that the random number
   generation has failed. It is expected that the calling function
   checks the status and handles this error appropriately.
 - This change should not have any side effect as the behaviour
   will be similar to that of release builds where the asserts
   would be removed.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Arm CCA Realms protect the access to memory from outside the
Realm. For Virtio to work the Realm Guest and the Host should
be able to share buffers.

Realm Aperture Management protocol (RAMP) manages the sharing
of buffers between the Realm Guest and the Host, while the
ArmCcaIoMmuDxe implements the EDKII_IOMMU_PROTOCOL which
provides the necessary hooks so that DMA accesses can be
performed by bouncing buffers using pages shared with the
host.

Therefore, enable the support for Realm Aperture Management
Protocol and ArmCcaIoMmuDxe for Kvmtool Guest firmware.

Note: The ArmCcaIoMmuDxe and RAMP check if the code is executing
in a Realm before installing the respective protocols. If the
code is not executing in a Realm the gIoMmuAbsentProtocolGuid is
installed, thereby allowing the same firmware to be used both for
normal and Realm Guest firmware.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

On Arm CCA systems the access to pages inside the Realm is protected.

However, software executing in a Realm needs to interact with the
external world. This may be done using para virtualisation of the
disk, network interfaces, etc. For this to work the buffers in the
Realm need to be shared with the Host. The sharing and management
of the Realm buffers is done by the Realm Aperture Management
Protocol, which invokes the necessary Realm Service Interfaces
to transition the buffers from Protected IPA to Unprotected IPA.

The ArmCcaIoMmu driver provides the necessary hooks so that DMA
operations can be performed by bouncing buffers using pages shared
with the Host. It uses the Realm Aperture Management protocol to
share the buffers with the Host.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The Realm Aperture Management Protocol (RAMP) is used to manage
the sharing of buffers between the Guest and Host. It configures
the memory regions as Protected EMPTY or Protected RAM by calling
RSI_IPA_STATE_SET command. The RAMP provides interfaces that device
drivers can use to open/close apertures for sharing buffers.

The RAMP also keeps track of the apertures that have been opened
and closes them on ExitBootServices. It also registers for reset
notification and closes all open apertures before the platform
resets the system.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Add ArmCcaDxe for early DXE phase initialisation like setting
up the monitor call conduit for Realm code

The Realm code should use SMC as the conduit for monitor calls.
Therefore, set the PcdMonitorConduitHvc to FALSE if the code is
running in a Realm.

Note: ArmCcaDxe is configured as an APRIORI DXE so that the DXE
dispatcher can schedule this to be loaded at the very beginning
of the Dxe phase. The DevicePathDxe.inf and Pcd.inf modules have
also been included to satisfy the required dependencies.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Add ArmCcaInitialize () to perform Arm CCA specific initialisation
like:
 - Reading the Realm Config by calling the RSI interface.
 - Storing the IPA width of the Realm in PcdArmCcaEarlyIpaWidth.
 - Configuring the MMIO regions to update the page tables to set
   the protection attribute as Unprotected IPA.

Note: ArmCcaInitialize () is implemented in ArmCcaInitPeiLib for
which a Null implementation is provided. Therefore, this change
should not break existing platforms that do not implement the
Arm CCA.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

When a VMM creates a Realm, a small amount of DRAM (which contains
the firmware image) and the initial content is configured as Protected
RAM. The remaining System Memory is in the Protected Empty state. The
firmware must then initialise the remaining System Memory as Protected
RAM before it can be accessed.

Therefore, call the ArmCcaConfigureSystemMemory () in the early Pei
phase so that the System Memory is configured as Protected RAM.

Note: ArmCcaConfigureSystemMemory () is implemented in ArmCcaInitPeiLib
for which a Null implementation is provided. Therefore, this change
should not have an impact for non-Arm CCA enabled systems.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The following libraries have been introduced for Arm CCA:
 * ArmCcaInitPeiLib - provides functions for ARM CCA
                      initialisations in early PEI phase.
 * ArmCcaLib        - provides the necessary helper functions
                      for Arm CCA
 * ArmCcaRsiLib     - implements functions to call the Realm
                      Service Interface.

Therefore, add these libraries in the Kvmtool guest firmware
workspace as part of enabling support for Arm CCA.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The patch at "6c8a08bd ArmVirtPkg/PrePi: Ensure timely
 execution of library constructors" moved the processing of
library constructors before the MMU is initialised.

This resulted in the BaseDebugLibSerialPort library constructor
BaseDebugLibSerialPortConstructor () which initialises the serial
port, being invoked before the MMU is enabled.

However, the Realm Code requires the protection attribute of
the MMIO regions to be configured as unprotected (shared with
the host), which requires the MMU to be enabled. Otherwise,
accesses to the MMIO region result in a synchronous external
abort being reflected to the Realm by the RMM.

Therefore, link the Null version of DebugLib in PrePi stage.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The IPA space of a Realm is divided into two halves:
  - Protected IPA space and
  - Unprotected IPA space.

Software in a Realm should treat the most significant bit of an
IPA as a protection attribute.

The Unprotected IPA space is used for sharing memory and for performing
MMIO accesses with the Host.

An Unprotected IPA is an address in the upper half of a Realm's
IPA space. The most significant bit of an Unprotected IPA is 1.

The page tables for the MMIO regions must be updated to set the most
significant bit of the IPA space.

Therefore, implement ArmCcaConfigureMmio () which configures the MMIO
regions as Unprotected IPA by setting the protection attribute in the
page tables for the MMIO regions.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

To support Arm CCA, a hook function ArmCcaConfigureMmio () has
been added to the ArmVirtMemInfoLib library.

Since, Arm CCA has not been enabled for the Xen guest firmware,
update the XenVirtMemInfoLib library to add a NULL implementation
for ArmCcaConfigureMmio () that returns RETURN_UNSUPPORTED.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

To support Arm CCA, a hook function ArmCcaConfigureMmio () has
been added to the ArmVirtMemInfoLib library.

Since, Arm CCA has not been enabled for the Qemu guest firmware,
update the QemuVirtMemInfoLib library to add a NULL implementation
for ArmCcaConfigureMmio () that returns RETURN_UNSUPPORTED.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

To support Arm CCA, a hook function ArmCcaConfigureMmio () has
been added to the ArmVirtMemInfoLib library.

Since, Arm CCA has not been enabled for the Cloud Hypervisor guest
firmware, update the CloudHvVirtMemInfoLib library to add a NULL
implementation for ArmCcaConfigureMmio () that returns
RETURN_UNSUPPORTED.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The IPA space of a Realm is divided into two halves:
  - Protected IPA space and
  - Unprotected IPA space.

Software in a Realm should treat the most significant bit of an
IPA as a protection attribute.

The Unprotected IPA space is used for sharing memory and for performing
MMIO accesses with the Host.

An Unprotected IPA is an address in the upper half of a Realm's
IPA space. The most significant bit of an Unprotected IPA is 1.

Therefore, the page tables for the MMIO regions must be updated to set
the most significant bit of the IPA space.

To facilitate this define ArmCcaConfigureMmio () that can be called
during the early firmware startup.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Add a Null instance of ArmCcaLib so that guest firmware that does
not support Arm CCA can link to this Null version of the library.

Also include it in ArmVirt.dsc.inc so that it is linked for the
non-Arm CCA firmware builds.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Introduce ArmCcaLib library that implements helper
functions to:
- probe if the code is executing in a Realm context
- configure the protection attribute in page tables
  for the memory regions shared with the host
- get the IPA width of the Realm which was stored in
  the GUID HOB gArmCcaIpaWidthGuid.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Add a NULL instance of ArmCcaInitPeiLib library that guest firmware
for VMMs that do not implement Arm CCA Realms can use.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Add ArmCcaInitPeiLib library that performs the Arm CCA specific
initialisation in the PEI phase like:
 - Configuring the system memory as Protected RAM.
 - Reading the Realm Config and storing the IPA width in
   a GUID HOB i.e., gArmCcaIpaWidthGuid for subsequent use.
 - Calling ArmCcaConfigureMmio () to configure the MMIO regions
   by setting the Unprotected IPA attribute in the page tables.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The IPA width of a Realm is read from the Realm Config by invoking
the RSI call RSI_REALM_CONFIG to read the Realm Config. The IPA width
is then stored in a GUID HOB gArmCcaIpaWidthGuid for subsequent use.

This GUID HOB is also useful to pass the IPA width of the Realm to the
DXE phase.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The Section A4.5 Host call, RMM Specification, version A-bet0
describes the programming model for Realm communication with
the Host and specifies the following:
  DYDJWT - A Host call is a call made by the Realm to the Host, by
           execution of the RSI_HOST_CALL command.
  IXNFKZ - A Host call can be used by a Realm to make a hypercall.
  DYDJWT - A Host call is a call made by the Realm to the Host, by
           execution of the RSI_HOST_CALL command.

Therefore, introduce definition of HOST_CALL_ARGS structure that
represents the arguments to the RSI_HOST_CALL command as defined
in Section B4.3.3 RSI_HOST_CALL command.

Also update the ArmCcaRsiLib library to add a new interface
RsiHostCall () to make a Host call.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The Section A2.1.3 Realm attributes, RMM Specification, version A-bet0
introduces the concept of REMs as described below:
  DGRFCS - A Realm Extensible Measurement (REM) is a measurement value
           which can be extended during the lifetime of a Realm.
  IFMPYL - Attributes of a Realm include an array of measurement values.
           The first entry in this array is a RIM. The remaining entries
           in this array are REMs.

The Realm Service Interface commands defined in section
B4.3.7 RSI_MEASUREMENT_READ and B4.3.6 RSI_MEASUREMENT_EXTEND
specify the interfaces to read and extend measurements to REMs.

Therefore, update ArmCcaRsiLib to add interfaces to get and extend REMs.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

A CCA attestation token is a collection of claims about the state of a
Realm and of the CCA platform on which the Realm is running.
A CCA attestation token consists of two parts:
  * Realm token - Contains attributes of the Realm, including:
    # Realm Initial Measurement
    # Realm Extensible Measurements
  * CCA platform token - Contains attributes of the CCA platform
    on which the Realm is running, including:
    # CCA platform identity
    # CCA platform life cycle state
    # CCA platform software component measurements

The CCA attestation token is used by a verification service to validate
these claims.

The Realm Service Interface defines the following interfaces to retrieve
an attestation token from the Realm Management Monitor (RMM).
  - RSI_ATTESTATION_TOKEN_INIT
  - RSI_ATTESTATION_TOKEN_CONTINUE

Therefore, update the ArmCcaRsiLib to add an interface to get an
attestation token from the RMM.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The IPA space of a Realm is divided into two halves: Protected IPA space
and Unprotected IPA space. Software in a Realm should treat the most
significant bit of an IPA as a protection attribute. A Protected IPA is
an address in the lower half of a Realm's IPA space. An Unprotected IPA
is an address in the upper half of a Realm's IPA space.

A Protected IPA has an associated Realm IPA state (RIPAS). The RIPAS
values are:
 * EMPTY  - Unused address
 * RAM    - Private code or data owned by the Realm.

Software in the Realm needs to share memory with the host to communicate
with the outside world, e.g. network, disk image, etc.

To share memory, the software in the Realm first transitions the RIPAS
of memory region it wants to share with the host from RAM to EMPTY. The
Realm software can then access the shared memory region using the
Unprotected IPA address.

The RMM specification defines the following Realm Service Interfaces for
managing the IPA state:
 * RSI_IPA_STATE_GET
 * RSI_IPA_STATE_SET

Therefore, update the ArmCcaRsiLib to add interfaces to get and set the
IPA state of Realm memory pages.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The Realm Management Monitor (RMM) is a software component which
forms part of a system which implements the Arm Confidential Compute
Architecture (CCA) and is responsible for management of Realms.
The RMM specification defines a Realm Service Interface (RSI) that
the Guest can use to request services from the RMM.

Therefore, add a library that implements the RSI interfaces to:
  - query the RSI version
  - get the Realm configuration.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The monitor call conduit is fixed for a platform firmware in
most scenarios. For a normal virtual machine guest firmware,
the default conduit is HVC. However, for Arm CCA the Realm
code must use SMC as the conduit.

To have a common code base for Guest/Virtual firmware to be used
by both normal VMs and Realm VMs, make PcdMonitorConduitHvc as a
dynamic PCD. This allows the firmware to detect if it is running
in a Realm and it can configure the PcdMonitorConduitHvc as FALSE
(i.e. to use SMC as the conduit when running in a Realm).

Also update the ArmVirtPkg/ArmVirtKvmTool.dsc workspace to move
the PcdMonitorConduitHvc in the PcdsDynamic section to prevent
the build from breaking.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

The Realm Service Interface (RSI) commands use registers between
X1-X10 as parameters and between X0-X8 as return values for SMC
calls.

According to the SMCCC Section 2.6 SMC32/HVC32 argument passing
  When an SMC32/HVC32 call is made from AArch32:
   - Arguments are passed in registers R1-R7.
   - Results are returned in R0-R7.
  When an SMC32/HVC32 call is made from AArch64:
   - Arguments are passed in registers W1-W7.
   - Results are returned in W0-W7.

According to SMCCC Section 2.7 SMC64/HVC64 argument passing
  When an SMC64/HVC64 call is made from AArch64:
   - Arguments are passed in registers X1-X17.
   - Results are returned in X0-X17.

This means SMC calls can take up to 7/17 arguments and return up
to 7/17 return values.

However, for the current use-case(s):
  - SMC32/HVC32 calls made from AArch32/AArch64 require up to 7
    arguments and 4 return values.
  - SMC64/HVC64 calls made from AArch64 require up to 10 arguments
    and 9 return values.

Therefore, for SMC32/HVC32 calls made from AArch32/AArch64 there is
no update required. However, for AMC64/HVC64 calls made from AArch64,
extend the ArmCallSmc () to use registers X1-X11 as parameters and
return values for SMC call.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Arm CCA requires the software in a Realm to treat the most
significant bit of an IPA as a protection attribute. To
enable/disable sharing of memory regions with the host, the
protection attribute needs to be set/cleared accordingly.

Instead of implementing the functionality to Set/Clear the
protection attribute in ArmMmuLib, defer this to an Arm CCA
specific library so that additional dependencies for
ArmMmuLib can be avoided.

Therefore, export the SetMemoryRegionAttribute () in
ArmMmuLib so that the Realm software can configure the
protection attribute.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Add helper function to check if the Realm Management
Extension (RME) is implemented by the hardware.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Although Kvmtool supports a CFI flash interface, it is currently
implemented using file backed support on the Host. This scenario
requires the VMM to be within the trust boundary.

In Confidential Compute Architecture the VMM is outside the trust
boundary. For such architectures Emulated Runtime variable storage
is desirable.

Therefore, make Emulated Runtime variable storage as the default
option and add a build flag ENABLE_CFI_FLASH to configure the
firmware build to use the CFI Flash as the Variable storage.

Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>

Add a .git-blame-ignore-revs file containing the hashes of every
uncrustify format commit as retrieved in:
	git log --oneline --no-abbrev-commit  | grep "uncrustify"

This file can be used by tools (such as GitHub[1]) to ignore
certain revisions when git blame-ing a file.

It can also be trivially usable locally by doing something akin
to:
	git config blame.ignoreRevsFile .git-blame-ignore-revs

It may also be desirable in the future to add more commits to it.

Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>

[1]: https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/

To help people format patches with the correct options, add an alias
named 'fp' to SetupGit.py that runs format-patch with '-M --stat=1000
--stat-graph-width=20'.

Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>

New code should use the C99 macro __func__ instead of the pre-Standard
macro __FUNCTION__. Update PatchCheck.py to reject patches with the
latter.

Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>

Fix GCC build error on AARCH64 system.

Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>

Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Peter Grehan <grehan@freebsd.org>
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>

Added entries for UEFI Config Tables not present in current
Dmem output.

Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Sam Kaynor <Sam.Kaynor@arm.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>

Add a new library, JedecJep106Lib which provides a service to return the
JEDEC JEP106 manufacturer string given the code and continuation bytes
values.

Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>

Nothing to do here for virtio 1.0 devices

Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>

Copied values from OVMF, these are sufficient for a debug build.

Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>

MemoryType information assists GCD with defragmenting the memory map.
When the DXE core starts, GCD adds memory descriptors for the resource
descriptors HOBs. This allocates heap space which can be reused later
as the bins by memory type. It seems memory allocation prefers low
ranges.

It seems "below 4G" is an artifact of this heap reuse. However, the
memory type information determines the DXE core's
`MinimalMemorySizeNeeded`, determining which system memory descriptor
HOB may be used by DXE. Furthermore, it's important that the memory
type information be correct, for an S4 memory map.

Therefore, follow other bootloaders, such as [MinPlatform][1], and do
this unconditionally. As of [edk2-stable202011][2], it was.

[1]: https://github.com/tianocore/edk2-platforms/blob/b6f96743891be51541184bf61dd2970c008e2c43/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.c#L164-L201
[2]: https://github.com/tianocore/edk2/blob/edk2-stable202011/UefiPayloadPkg/BlSupportPei/BlSupportPei.c#L462-L466



Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>