Merge tag 'char-misc-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

Pull char/misc driver updates from Greg KH:
 "Here is the big set of char, misc, and other assorted driver subsystem
  patches for 5.10-rc1.

  There's a lot of different things in here, all over the drivers/
  directory. Some summaries:

   - soundwire driver updates

   - habanalabs driver updates

   - extcon driver updates

   - nitro_enclaves new driver

   - fsl-mc driver and core updates

   - mhi core and bus updates

   - nvmem driver updates

   - eeprom driver updates

   - binder driver updates and fixes

   - vbox minor bugfixes

   - fsi driver updates

   - w1 driver updates

   - coresight driver updates

   - interconnect driver updates

   - misc driver updates

   - other minor driver updates

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'char-misc-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (396 commits)
  binder: fix UAF when releasing todo list
  docs: w1: w1_therm: Fix broken xref, mistakes, clarify text
  misc: Kconfig: fix a HISI_HIKEY_USB dependency
  LSM: Fix type of id parameter in kernel_post_load_data prototype
  misc: Kconfig: add a new dependency for HISI_HIKEY_USB
  firmware_loader: fix a kernel-doc markup
  w1: w1_therm: make w1_poll_completion static
  binder: simplify the return expression of binder_mmap
  test_firmware: Test partial read support
  firmware: Add request_partial_firmware_into_buf()
  firmware: Store opt_flags in fw_priv
  fs/kernel_file_read: Add "offset" arg for partial reads
  IMA: Add support for file reads without contents
  LSM: Add "contents" flag to kernel_read_file hook
  module: Call security_kernel_post_load_data()
  firmware_loader: Use security_post_load_data()
  LSM: Introduce kernel_post_load_data() hook
  fs/kernel_read_file: Add file_size output argument
  fs/kernel_read_file: Switch buffer size arg to size_t
  fs/kernel_read_file: Remove redundant size argument
  ...
This commit is contained in:
Linus Torvalds
2020-10-15 10:01:51 -07:00
297 changed files with 24461 additions and 10014 deletions
+21
View File
@@ -0,0 +1,21 @@
What: /sys/bus/mhi/devices/.../serialnumber
Date: Sept 2020
KernelVersion: 5.10
Contact: Bhaumik Bhatt <bbhatt@codeaurora.org>
Description: The file holds the serial number of the client device obtained
using a BHI (Boot Host Interface) register read after at least
one attempt to power up the device has been done. If read
without having the device power on at least once, the file will
read all 0's.
Users: Any userspace application or clients interested in device info.
What: /sys/bus/mhi/devices/.../oem_pk_hash
Date: Sept 2020
KernelVersion: 5.10
Contact: Bhaumik Bhatt <bbhatt@codeaurora.org>
Description: The file holds the OEM PK Hash value of the endpoint device
obtained using a BHI (Boot Host Interface) register read after
at least one attempt to power up the device has been done. If
read without having the device power on at least once, the file
will read all 0's.
Users: Any userspace application or clients interested in device info.
+15
View File
@@ -0,0 +1,15 @@
What: /sys/bus/dfl/devices/dfl_dev.X/type
Date: Aug 2020
KernelVersion: 5.10
Contact: Xu Yilun <yilun.xu@intel.com>
Description: Read-only. It returns type of DFL FIU of the device. Now DFL
supports 2 FIU types, 0 for FME, 1 for PORT.
Format: 0x%x
What: /sys/bus/dfl/devices/dfl_dev.X/feature_id
Date: Aug 2020
KernelVersion: 5.10
Contact: Xu Yilun <yilun.xu@intel.com>
Description: Read-only. It returns feature identifier local to its DFL FIU
type.
Format: 0x%x
+8
View File
@@ -36,3 +36,11 @@ Contact: linux-fsi@lists.ozlabs.org
Description:
Provides a means of reading/writing a 32 bit value from/to a
specified FSI bus address.
What: /sys/bus/platform/devices/../cfam_reset
Date: Sept 2020
KernelVersion: 5.10
Contact: linux-fsi@lists.ozlabs.org
Description:
Provides a means of resetting the cfam that is attached to the
FSI device.
+7
View File
@@ -41,6 +41,13 @@ Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client fixed address, if any
Format: %d
What: /sys/bus/mei/devices/.../vtag
Date: Nov 2020
KernelVersion: 5.9
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client vtag support status
Format: %d
What: /sys/bus/mei/devices/.../max_len
Date: Nov 2019
KernelVersion: 5.5
@@ -1,3 +1,21 @@
What: /sys/bus/soundwire/devices/sdw:.../status
/sys/bus/soundwire/devices/sdw:.../device_number
Date: September 2020
Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Bard Liao <yung-chuan.liao@linux.intel.com>
Vinod Koul <vkoul@kernel.org>
Description: SoundWire Slave status
These properties report the Slave status, e.g. if it
is UNATTACHED or not, and in the latter case show the
device_number. This status information is useful to
detect devices exposed by platform firmware but not
physically present on the bus, and conversely devices
not exposed in platform firmware but enumerated.
What: /sys/bus/soundwire/devices/sdw:.../dev-properties/mipi_revision
/sys/bus/soundwire/devices/sdw:.../dev-properties/wake_capable
/sys/bus/soundwire/devices/sdw:.../dev-properties/test_mode_capable
@@ -2,13 +2,17 @@ What: /sys/class/habanalabs/hl<n>/armcp_kernel_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Description: Version of the Linux kernel running on the device's CPU
Description: Version of the Linux kernel running on the device's CPU.
Will be DEPRECATED in Linux kernel version 5.10, and be
replaced with cpucp_kernel_ver
What: /sys/class/habanalabs/hl<n>/armcp_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Description: Version of the application running on the device's CPU
Will be DEPRECATED in Linux kernel version 5.10, and be
replaced with cpucp_ver
What: /sys/class/habanalabs/hl<n>/clk_max_freq_mhz
Date: Jun 2019
@@ -33,6 +37,18 @@ KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Description: Version of the Device's CPLD F/W
What: /sys/class/habanalabs/hl<n>/cpucp_kernel_ver
Date: Oct 2020
KernelVersion: 5.10
Contact: oded.gabbay@gmail.com
Description: Version of the Linux kernel running on the device's CPU
What: /sys/class/habanalabs/hl<n>/cpucp_ver
Date: Oct 2020
KernelVersion: 5.10
Contact: oded.gabbay@gmail.com
Description: Version of the application running on the device's CPU
What: /sys/class/habanalabs/hl<n>/device_type
Date: Jan 2019
KernelVersion: 5.1
@@ -49,10 +49,13 @@ Description:
will be changed only in device RAM, so it will be cleared when
power is lost. Trigger a 'save' to EEPROM command to keep
values after power-on. Read or write are :
* '9..12': device resolution in bit
* '9..14': device resolution in bit
or resolution to set in bit
* '-xx': xx is kernel error when reading the resolution
* Anything else: do nothing
Some DS18B20 clones are fixed in 12-bit resolution, so the
actual resolution is read back from the chip and verified. Error
is reported if the results differ.
Users: any user space application which wants to communicate with
w1_term device
@@ -86,7 +89,7 @@ Description:
*write* :
* '0' : save the 2 or 3 bytes to the device EEPROM
(i.e. TH, TL and config register)
* '9..12' : set the device resolution in RAM
* '9..14' : set the device resolution in RAM
(if supported)
* Anything else: do nothing
refer to Documentation/w1/slaves/w1_therm.rst for detailed
@@ -114,3 +117,47 @@ Description:
of the bulk read command (not the current temperature).
Users: any user space application which wants to communicate with
w1_term device
What: /sys/bus/w1/devices/.../conv_time
Date: July 2020
Contact: Ivan Zaentsev <ivan.zaentsev@wirenboard.ru>
Description:
(RW) Get, set, or measure a temperature conversion time. The
setting remains active until a resolution change. Then it is
reset to default (datasheet) conversion time for a new
resolution.
*read*: Actual conversion time in milliseconds. *write*:
'0': Set the default conversion time from the datasheet.
'1': Measure and set the conversion time. Make a single
temperature conversion, measure an actual value.
Increase it by 20% for temperature range. A new
conversion time can be obtained by reading this
same attribute.
other positive value:
Set the conversion time in milliseconds.
Users: An application using the w1_term device
What: /sys/bus/w1/devices/.../features
Date: July 2020
Contact: Ivan Zaentsev <ivan.zaentsev@wirenboard.ru>
Description:
(RW) Control optional driver settings.
Bit masks to read/write (bitwise OR):
1: Enable check for conversion success. If byte 6 of
scratchpad memory is 0xC after conversion, and
temperature reads 85.00 (powerup value) or 127.94
(insufficient power) - return a conversion error.
2: Enable poll for conversion completion. Generate read cycles
after the conversion start and wait for 1's. In parasite
power mode this feature is not available.
*read*: Currently selected features.
*write*: Select features.
Users: An application using the w1_term device
@@ -1,27 +0,0 @@
* PTN5150 CC (Configuration Channel) Logic device
PTN5150 is a small thin low power CC logic chip supporting the USB Type-C
connector application with CC control logic detection and indication functions.
It is interfaced to the host controller using an I2C interface.
Required properties:
- compatible: should be "nxp,ptn5150"
- reg: specifies the I2C slave address of the device
- int-gpio: should contain a phandle and GPIO specifier for the GPIO pin
connected to the PTN5150's INTB pin.
- vbus-gpio: should contain a phandle and GPIO specifier for the GPIO pin which
is used to control VBUS.
- pinctrl-names : a pinctrl state named "default" must be defined.
- pinctrl-0 : phandle referencing pin configuration of interrupt and vbus
control.
Example:
ptn5150@1d {
compatible = "nxp,ptn5150";
reg = <0x1d>;
int-gpio = <&msmgpio 78 GPIO_ACTIVE_HIGH>;
vbus-gpio = <&msmgpio 148 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&ptn5150_default>;
status = "okay";
};
@@ -0,0 +1,60 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/extcon/extcon-ptn5150.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: PTN5150 CC (Configuration Channel) Logic device
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
PTN5150 is a small thin low power CC logic chip supporting the USB Type-C
connector application with CC control logic detection and indication
functions. It is interfaced to the host controller using an I2C interface.
properties:
compatible:
const: nxp,ptn5150
int-gpios:
deprecated: true
description:
GPIO pin (input) connected to the PTN5150's INTB pin.
Use "interrupts" instead.
interrupts:
maxItems: 1
reg:
maxItems: 1
vbus-gpios:
description:
GPIO pin (output) used to control VBUS. If skipped, no such control
takes place.
required:
- compatible
- interrupts
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
ptn5150@1d {
compatible = "nxp,ptn5150";
reg = <0x1d>;
interrupt-parent = <&msmgpio>;
interrupts = <78 IRQ_TYPE_LEVEL_HIGH>;
vbus-gpios = <&msmgpio 148 GPIO_ACTIVE_HIGH>;
};
};
@@ -12,6 +12,13 @@ Required properties:
- pinctrl-0: phandle to pinctrl node
- pinctrl-names: pinctrl state
Optional properties:
- cfam-reset-gpios: GPIO for CFAM reset
- fsi-routing-gpios: GPIO for setting the FSI mux (internal or cabled)
- fsi-mux-gpios: GPIO for detecting the desired FSI mux state
Examples:
fsi-master {
@@ -21,4 +28,9 @@ Examples:
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fsi1_default>;
clocks = <&syscon ASPEED_CLK_GATE_FSICLK>;
fsi-routing-gpios = <&gpio0 ASPEED_GPIO(Q, 7) GPIO_ACTIVE_HIGH>;
fsi-mux-gpios = <&gpio0 ASPEED_GPIO(B, 0) GPIO_ACTIVE_HIGH>;
cfam-reset-gpios = <&gpio0 ASPEED_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
};
@@ -19,7 +19,8 @@ directly.
Required properties:
- compatible : contains the interconnect provider compatible string
- #interconnect-cells : number of cells in a interconnect specifier needed to
encode the interconnect node id
encode the interconnect node id and optionally add a
path tag
Example:
@@ -44,6 +45,10 @@ components it has to interact with.
Required properties:
interconnects : Pairs of phandles and interconnect provider specifier to denote
the edge source and destination ports of the interconnect path.
An optional path tag value could specified as additional argument
to both endpoints and in such cases, this information will be passed
to the interconnect framework to do aggregation based on the attached
tag.
Optional properties:
interconnect-names : List of interconnect path name strings sorted in the same
@@ -62,3 +67,20 @@ Example:
interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
interconnect-names = "sdhc-mem";
};
Example with path tags:
gnoc: interconnect@17900000 {
...
interconnect-cells = <2>;
};
mnoc: interconnect@1380000 {
...
interconnect-cells = <2>;
};
cpu@0 {
...
interconnects = <&gnoc MASTER_APPSS_PROC 3 &mnoc SLAVE_EBI1 3>;
}
@@ -21,6 +21,23 @@ properties:
enum:
- qcom,bcm-voter
qcom,tcs-wait:
description: |
Optional mask of which TCSs (Triggered Command Sets) wait for completion
upon triggering. If not specified, then the AMC and WAKE sets wait for
completion. The mask bits are available in the QCOM_ICC_TAG_* defines.
The AMC TCS is triggered immediately when icc_set_bw() is called. The
WAKE/SLEEP TCSs are triggered when the RSC transitions between active and
sleep modes.
In most cases, it's necessary to wait in both the AMC and WAKE sets to
ensure resources are available before use. If a specific RSC and its use
cases can ensure sufficient delay by other means, then this can be
overridden to reduce latencies.
$ref: /schemas/types.yaml#/definitions/uint32
required:
- compatible
@@ -39,7 +56,10 @@ examples:
# as defined in Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt
- |
#include <dt-bindings/interconnect/qcom,icc.h>
disp_bcm_voter: bcm_voter {
compatible = "qcom,bcm-voter";
qcom,tcs-wait = <QCOM_ICC_TAG_AMC>;
};
...
@@ -19,6 +19,8 @@ properties:
enum:
- qcom,sc7180-osm-l3
- qcom,sdm845-osm-l3
- qcom,sm8150-osm-l3
- qcom,sm8250-epss-l3
reg:
maxItems: 1
@@ -1,16 +1,17 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,sdm845.yaml#
$id: http://devicetree.org/schemas/interconnect/qcom,rpmh.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm SDM845 Network-On-Chip Interconnect
title: Qualcomm RPMh Network-On-Chip Interconnect
maintainers:
- Georgi Djakov <georgi.djakov@linaro.org>
- Odelu Kukatla <okukatla@codeaurora.org>
description: |
SDM845 interconnect providers support system bandwidth requirements through
RPMh interconnect providers support system bandwidth requirements through
RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
able to communicate with the BCM through the Resource State Coordinator (RSC)
associated with each execution environment. Provider nodes must point to at
@@ -23,6 +24,19 @@ properties:
compatible:
enum:
- qcom,sc7180-aggre1-noc
- qcom,sc7180-aggre2-noc
- qcom,sc7180-camnoc-virt
- qcom,sc7180-compute-noc
- qcom,sc7180-config-noc
- qcom,sc7180-dc-noc
- qcom,sc7180-gem-noc
- qcom,sc7180-ipa-virt
- qcom,sc7180-mc-virt
- qcom,sc7180-mmss-noc
- qcom,sc7180-npu-noc
- qcom,sc7180-qup-virt
- qcom,sc7180-system-noc
- qcom,sdm845-aggre1-noc
- qcom,sdm845-aggre2-noc
- qcom,sdm845-config-noc
@@ -31,6 +45,28 @@ properties:
- qcom,sdm845-mem-noc
- qcom,sdm845-mmss-noc
- qcom,sdm845-system-noc
- qcom,sm8150-aggre1-noc
- qcom,sm8150-aggre2-noc
- qcom,sm8150-camnoc-noc
- qcom,sm8150-compute-noc
- qcom,sm8150-config-noc
- qcom,sm8150-dc-noc
- qcom,sm8150-gem-noc
- qcom,sm8150-ipa-virt
- qcom,sm8150-mc-virt
- qcom,sm8150-mmss-noc
- qcom,sm8150-system-noc
- qcom,sm8250-aggre1-noc
- qcom,sm8250-aggre2-noc
- qcom,sm8250-compute-noc
- qcom,sm8250-config-noc
- qcom,sm8250-dc-noc
- qcom,sm8250-gem-noc
- qcom,sm8250-ipa-virt
- qcom,sm8250-mc-virt
- qcom,sm8250-mmss-noc
- qcom,sm8250-npu-noc
- qcom,sm8250-system-noc
'#interconnect-cells':
const: 1
@@ -1,85 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,sc7180.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm SC7180 Network-On-Chip Interconnect
maintainers:
- Odelu Kukatla <okukatla@codeaurora.org>
description: |
SC7180 interconnect providers support system bandwidth requirements through
RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
able to communicate with the BCM through the Resource State Coordinator (RSC)
associated with each execution environment. Provider nodes must point to at
least one RPMh device child node pertaining to their RSC and each provider
can map to multiple RPMh resources.
properties:
reg:
maxItems: 1
compatible:
enum:
- qcom,sc7180-aggre1-noc
- qcom,sc7180-aggre2-noc
- qcom,sc7180-camnoc-virt
- qcom,sc7180-compute-noc
- qcom,sc7180-config-noc
- qcom,sc7180-dc-noc
- qcom,sc7180-gem-noc
- qcom,sc7180-ipa-virt
- qcom,sc7180-mc-virt
- qcom,sc7180-mmss-noc
- qcom,sc7180-npu-noc
- qcom,sc7180-qup-virt
- qcom,sc7180-system-noc
'#interconnect-cells':
const: 1
qcom,bcm-voters:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: |
List of phandles to qcom,bcm-voter nodes that are required by
this interconnect to send RPMh commands.
qcom,bcm-voter-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: |
Names for each of the qcom,bcm-voters specified.
required:
- compatible
- reg
- '#interconnect-cells'
- qcom,bcm-voters
additionalProperties: false
examples:
- |
#include <dt-bindings/interconnect/qcom,sc7180.h>
config_noc: interconnect@1500000 {
compatible = "qcom,sc7180-config-noc";
reg = <0x01500000 0x28000>;
#interconnect-cells = <1>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
system_noc: interconnect@1620000 {
compatible = "qcom,sc7180-system-noc";
reg = <0x01620000 0x17080>;
#interconnect-cells = <1>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
mmss_noc: interconnect@1740000 {
compatible = "qcom,sc7180-mmss-noc";
reg = <0x01740000 0x1c100>;
#interconnect-cells = <1>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
@@ -11,6 +11,7 @@ board specific bus parameters.
Example:
"qcom,soundwire-v1.3.0"
"qcom,soundwire-v1.5.0"
"qcom,soundwire-v1.5.1"
"qcom,soundwire-v1.6.0"
- reg:
Usage: required
+37
View File
@@ -42,6 +42,11 @@ The session is terminated calling :c:func:`close(int fd)`.
A code snippet for an application communicating with Intel AMTHI client:
In order to support virtualization or sandboxing a trusted supervisor
can use :c:macro:`MEI_CONNECT_CLIENT_IOCTL_VTAG` to create
virtual channels with an Intel ME feature. Not all features support
virtual channels such client with answer EOPNOTSUPP.
.. code-block:: C
struct mei_connect_client_data data;
@@ -110,6 +115,38 @@ Connect to firmware Feature/Client.
data that can be sent or received. (e.g. if MTU=2K, can send
requests up to bytes 2k and received responses up to 2k bytes).
IOCTL_MEI_CONNECT_CLIENT_VTAG:
------------------------------
.. code-block:: none
Usage:
struct mei_connect_client_data_vtag client_data_vtag;
ioctl(fd, IOCTL_MEI_CONNECT_CLIENT_VTAG, &client_data_vtag);
Inputs:
struct mei_connect_client_data_vtag - contain the following
Input field:
in_client_uuid - GUID of the FW Feature that needs
to connect to.
vtag - virtual tag [1, 255]
Outputs:
out_client_properties - Client Properties: MTU and Protocol Version.
Error returns:
ENOTTY No such client (i.e. wrong GUID) or connection is not allowed.
EINVAL Wrong IOCTL Number or tag == 0
ENODEV Device or Connection is not initialized or ready.
ENOMEM Unable to allocate memory to client internal data.
EFAULT Fatal Error (e.g. Unable to access user input data)
EBUSY Connection Already Open
EOPNOTSUPP Vtag is not supported
IOCTL_MEI_NOTIFY_SET
---------------------
@@ -328,8 +328,11 @@ Code Seq# Include File Comments
0xAC 00-1F linux/raw.h
0xAD 00 Netfilter device in development:
<mailto:rusty@rustcorp.com.au>
0xAE all linux/kvm.h Kernel-based Virtual Machine
0xAE 00-1F linux/kvm.h Kernel-based Virtual Machine
<mailto:kvm@vger.kernel.org>
0xAE 40-FF linux/kvm.h Kernel-based Virtual Machine
<mailto:kvm@vger.kernel.org>
0xAE 20-3F linux/nitro_enclaves.h Nitro Enclaves
0xAF 00-1F linux/fsl_hypervisor.h Freescale hypervisor
0xB0 all RATIO devices in development:
<mailto:vgo@ratio.de>
+1
View File
@@ -11,6 +11,7 @@ Linux Virtualization Support
uml/user_mode_linux_howto_v2
paravirt_ops
guest-halt-polling
ne_overview
.. only:: html and subproject
+95
View File
@@ -0,0 +1,95 @@
.. SPDX-License-Identifier: GPL-2.0
==============
Nitro Enclaves
==============
Overview
========
Nitro Enclaves (NE) is a new Amazon Elastic Compute Cloud (EC2) capability
that allows customers to carve out isolated compute environments within EC2
instances [1].
For example, an application that processes sensitive data and runs in a VM,
can be separated from other applications running in the same VM. This
application then runs in a separate VM than the primary VM, namely an enclave.
An enclave runs alongside the VM that spawned it. This setup matches low latency
applications needs. The resources that are allocated for the enclave, such as
memory and CPUs, are carved out of the primary VM. Each enclave is mapped to a
process running in the primary VM, that communicates with the NE driver via an
ioctl interface.
In this sense, there are two components:
1. An enclave abstraction process - a user space process running in the primary
VM guest that uses the provided ioctl interface of the NE driver to spawn an
enclave VM (that's 2 below).
There is a NE emulated PCI device exposed to the primary VM. The driver for this
new PCI device is included in the NE driver.
The ioctl logic is mapped to PCI device commands e.g. the NE_START_ENCLAVE ioctl
maps to an enclave start PCI command. The PCI device commands are then
translated into actions taken on the hypervisor side; that's the Nitro
hypervisor running on the host where the primary VM is running. The Nitro
hypervisor is based on core KVM technology.
2. The enclave itself - a VM running on the same host as the primary VM that
spawned it. Memory and CPUs are carved out of the primary VM and are dedicated
for the enclave VM. An enclave does not have persistent storage attached.
The memory regions carved out of the primary VM and given to an enclave need to
be aligned 2 MiB / 1 GiB physically contiguous memory regions (or multiple of
this size e.g. 8 MiB). The memory can be allocated e.g. by using hugetlbfs from
user space [2][3]. The memory size for an enclave needs to be at least 64 MiB.
The enclave memory and CPUs need to be from the same NUMA node.
An enclave runs on dedicated cores. CPU 0 and its CPU siblings need to remain
available for the primary VM. A CPU pool has to be set for NE purposes by an
user with admin capability. See the cpu list section from the kernel
documentation [4] for how a CPU pool format looks.
An enclave communicates with the primary VM via a local communication channel,
using virtio-vsock [5]. The primary VM has virtio-pci vsock emulated device,
while the enclave VM has a virtio-mmio vsock emulated device. The vsock device
uses eventfd for signaling. The enclave VM sees the usual interfaces - local
APIC and IOAPIC - to get interrupts from virtio-vsock device. The virtio-mmio
device is placed in memory below the typical 4 GiB.
The application that runs in the enclave needs to be packaged in an enclave
image together with the OS ( e.g. kernel, ramdisk, init ) that will run in the
enclave VM. The enclave VM has its own kernel and follows the standard Linux
boot protocol [6].
The kernel bzImage, the kernel command line, the ramdisk(s) are part of the
Enclave Image Format (EIF); plus an EIF header including metadata such as magic
number, eif version, image size and CRC.
Hash values are computed for the entire enclave image (EIF), the kernel and
ramdisk(s). That's used, for example, to check that the enclave image that is
loaded in the enclave VM is the one that was intended to be run.
These crypto measurements are included in a signed attestation document
generated by the Nitro Hypervisor and further used to prove the identity of the
enclave; KMS is an example of service that NE is integrated with and that checks
the attestation doc.
The enclave image (EIF) is loaded in the enclave memory at offset 8 MiB. The
init process in the enclave connects to the vsock CID of the primary VM and a
predefined port - 9000 - to send a heartbeat value - 0xb7. This mechanism is
used to check in the primary VM that the enclave has booted. The CID of the
primary VM is 3.
If the enclave VM crashes or gracefully exits, an interrupt event is received by
the NE driver. This event is sent further to the user space enclave process
running in the primary VM via a poll notification mechanism. Then the user space
enclave process can exit.
[1] https://aws.amazon.com/ec2/nitro/nitro-enclaves/
[2] https://www.kernel.org/doc/html/latest/admin-guide/mm/hugetlbpage.html
[3] https://lwn.net/Articles/807108/
[4] https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
[5] https://man7.org/linux/man-pages/man7/vsock.7.html
[6] https://www.kernel.org/doc/html/latest/x86/boot.html

Some files were not shown because too many files have changed in this diff Show More