ACRN Converged Security Engine (CSE) Virtualization Introduction

1. ACRN CSE Virtualization Introduction
Tomas Winkler
Tomas Winkler <tomas.winkler@intel.com>
03/25/2020

2. Agenda
❑CSE Overview
❑MEI Driver
❑MEI in ACRN Device Model.

3. Agenda
❑CSE Overview
❑MEI Driver
❑MEI in ACRN Device Model.

4. 4
CSE/CSME
CSE/CSME - an embedded subsystem in Platform
Controller Hub (PCH)
• CSE = Converged Security Engine
• CSME = Converged Security & Manageability Engine
• Standalone small x86 processor, Memory, Crypto engine and I/O’s.
• CSE is Trusted Execution Environment (TEE)
• Provides an isolated and secured HW execution environment protected from
host processors
Serves Three Main Platform Roles
• Chassis: Secure boot of the platform / Survivability
• Security: Boot & Runtime Platform Apps
• Manageability: Optional Extensions for Out Of Band (OOB) Network Management
CSE also known as ME and TXE
CPU
PCH
CSME
LAN /
WLAN
SMB
GPIO
PECI

5. 5
CSME features High Level Overview
- Root of Trust (ROT) of the platform, starts the chain of trust
- Verified system configuration: Clocks, PCIe configuration,
overclocking, power configuration, many more
Chassis
- Platform Trust Technology (PTT) – An Integrated TPM 2.0 device
- Data Rights Management (DRM) - MSFT PlayReady, Google Widevine
- Anonymous Device Identity (EPID 2.0) – Remote Attestation, Provisioning
- Dynamic Application Load (DAL), allow 3rd party write Java applets running
inside CSE.
Security
- Intel Active Management Technology (AMT), allow IT to remotely connect to
the managed platform through OOB network interface
- Works even if system in low power state or hanged.
- Remote power-management capabilities.
- Remote redirection.
Manageability

6. PCI Device.
FW HECI Driver
FW
HECI Client
DAL
HECI Clients
HOST
HECI Client -
DRM
HECI Client
FW update
PTT (TPM 2.0)
ACPI Device
• Goal, enabling access to
security services provided
by CSE to guest OS.
• Each CSE service is
represented as HECI Client
locatable by client GUID.
• PTT is unique has dedicated
ACPI device to support
standard.

7. Agenda
❑CSE Overview
• DRM Use case
• DAL Use case

8. Intro to DRM
• DRMs can be used to protect content such as music, e-books, videos and
documents.
• A DRM is a scheme that allows to obtain licenses to protected content in a secure
fashion. (Examples: Play Ready, Widevine)
• CSE offers the ability for HW-backed DRM using its security infrastructure.
• What we need to protect (in order of importance):
• Device Keys, Title keys, Decrypted Media
• HDCP 2.0 – Link protection (between device and display)

9. CSE
Gen-DRM
Secure Decode
Content
Provider
Content License
Encrypted/Compressed Content
Title Keys
(VDM)
Gen:
Display Engine Monitor
Surface Key
Encrypted
HDCP
Encrypted
Content
Write HDCP2 Keys
Read Connection Status (VDM)
DRAM
Fetch and Decrypt
Content Protection

10. Agenda
❑CSE Overview
• DRM Use case
• DAL Use case

11. Intel ® Dynamic Application Loader
• Extends the CSE FW by dynamically loading signed CSE
applications at runtime.
• Allows agile and faster deployment of FW applications by decoupling
the application development from the platform development life cycle
• The FW applications are stored on host file system, thus avoiding
flash size considerations
• Enables binary-level portability for FW applications
• The only mechanism for dynamically extending CSE FW capabilities
• DAL applications are signed by Intel, and there is support for OEM
signing on certain platforms.
• DAL is based on a virtual machine., DAL applications are written in the
Java programming language

12. Host to FW Flow
Host FW
Clients
JHI (Java Host Interface)
HECI Kernel Driver FW OS + HECI
HECI Client API
VM
HECI Server API
Service
Manager
App
1
App
2
App
3
HECI
Communication
Buffer
App
1

13. JHI ServiceUser C/C++
Application
libjhi.so
bhPlugin.dll
HECI Driver
User
Space
FW
DAL
HECI ClientVirtual
Machine
BH Applet
Applet
Library load
Connection
OS
Solution
Module
KDI

14. 14
Operating Systems
DAL SW is supported on Windows, Linux, Android and UEFI
It is released as open source on GitHub
MEI DAL (“KDI”) – enables working with DAL directly from Linux
kernel space.

15. Agenda
❑CSE Overview
❑MEI Driver
❑MEI in ACRN Device Model.

16. 16
MEI driver.
MEI – Kernel driver drivers/misc/mei
AMT WD - drives/watchdog/wdt_me
SOL- drivers/serial (generic driver
IDR – drivers/hda
NFC – drivers/nfc/mei_phy.c
KDI – drivers/misc/mei/dal
SPD – drivers/misc/mei/spd
TPM_CRB – TPM PTT support drivers/char/tpm/tpm_crb
• MEI is a PCI device driver exposed /dev/mei character device
node.
• MEI also provides a client bus where FW clients can be
expressed as virtual devices, to be exposed via standard Linux
kernel subsystems or provide interface to other Linux kernel
drivers.

17. mei.ko (protocol).
HECI PCI Device.
FW HECI Driver
FW
HECI Client DAL
MEI Driver
OS
HECI Client -
DRM
HECI Client
FW update
mei_me.ko (pci).
HOST Client
1
HOST Client
2
HOST Client
FW update
Mei-bus.
mei_dal.ko HECI Client – DRM
mei_hdcp.ko
/dev/meiX
/dev/dalX
GFX
Key-master
User
Space

18. MEI (protocol).
HECI PCI
Device.
FW HECI Driver
FW
MEI Management Protocol
OS
Management Messages and Clients bookkeeping.
1. Enumerates Clients.
2. Create connections between:
Host and ME Clients
3. Disconnection
4. Flow Controller
5. (Few more)

19. MEI user space API.
Basic user space API for the MEI driver.
fd = open(“/dev/mei”, O_RDWR);
ret = ioclt(fd, IOCTL_MEI_CONNECT_CLIENT, CL_GUID);
ret = write(fd, cmd, sizeof(cmd));
ret = read(fd, resp, sizeof(resp));
Usually there is only one connection to one client.

20. Driver
After driver is located via GUID:
A tuple (Host Address ME Address) is used for communication
Data
Host
Address
Length
Message
complete
ME
Address
HECI PCI Device.
FW
HECI Client
ME Address
HECI Client
ME Address
HECI Client
ME Address
HOST Client
Host Address
HOST Client
Host Address
HOST Client
Host Address
HOST Client
Host Address
MEI Addressing..

21. Agenda
❑CSE Overview
❑MEI Driver
❑MEI in ACRN Device Model.

22. CSE Virtualization Requirements.
• CSE is a singleton in the system.
• In most cases a single connection to a client is allowed.
• Client resources are singleton.
• Required Changes:
• Allow virtual channels over single connection to support UOs
• Multiply FW resources.
• Isolated FW resources.
• User space applications should be oblivious to virtualization or
lack of it.

23. MEI Virtio Addressing
• Not enough free bits in the original
header.
• Extension bit is added.
• In the extended header a VTag is
added.
• VTag designate virtual channel.
• This affects available data size but
internal is already In place.
Data
Host
Address
Length
EXT
Message
complete
ME
Address
Rsvd VTag

24. Client Resources.
• A ME client declares during enumeration if it can support multiple
virtual channels.
• Some resources must be assigned to specific VTag.
• Persistent tag assignment is required between VTag and resources.
• Examples: WV Keybox, HDCP ports.
• Some ME clients don’t require context and have no real resources
associated. Can support unlimited number of virtual connections.
• Isolation – Relay on device model persistent vtag assignment,
possible to enhance with cryptography.

25. Device Model Framework
(reminder)
ACRN Device Model (DM) is a
QEMU-like application in SOS
and it is responsible for
creating a UOS VM and then
performing devices emulation
based on command line
configurations.

26. Service OS.
HECI Virtualization – components introduction
HECI virtio
pci device
PCI-MEI
HECI virtio BE Add/Strip VM
TAG to HECI
message
header
User OS 1
User
Kernel
MEI
PCI-HECI-VIRTIO (mei-virtion.ko)
/dev/mei0
APP
CSE FW
VM1 TAG
CSE CL 1 CSE CL2 CSE CLN
HECI virtio
pci device
VM2 TAG
User OS 2
User
Kernel
MEI
/dev/mei0
APP
PCI-HECI-VIRTIO (mei-virtion.ko)

27. MEI Front end driver.
mei-virtio.ko
• mei-virito.ko implements a
virtio_driver that binds to virtio
device [0x1AF4, 0x8602]. The
device ID is hard coded in ACRN
device model.
• The driver implements virtio_driver
handlers: probe, remove,
config_changes, freeze, and
restore.
• The driver is using two virtio
queues for communication. One for
RX and one for TX.
OS HECI Driver
(e.g. /dev/mei0)
mei.ko
mei_virtio.ko
vHECI-FE
virtio
mei_me.ko

28. MEI backend
Implemented in ACRN SOS mediator
• MEI-BE backend comprise of two parts.
1. Enhanced MEI base driver.
(SOS kernel)
New IOCTL - IOCTL_MEI_CONNECT_CLIENT_VTAG
2. The virtio backend service (VBE-U) that operates in service OS.
./devicemodel/hw/pci/virtio/virtio_mei.c
• MEI-BE will serve as a HECI FW driver proxy.
1. It implements management protocol towards vHECI-FE.
2. HW states CSE readiness and the link reset are mediated to the
vMEI-FE via virtio configurations as well as FW status register values.
3. vHECI-FE will sees only clients that supports virtualization.
4. Maps UOS ids to vtags

29. Device Model Configuration
acrn-dm -A
-m 2048M
-s 0:0,hostbridge
-s 2,pci-gvt -G "64 448 8“
-s 5,virtio-blk,/home/clear/uos/uos.img
-s 6,virtio-net,tap0
-s 15,virtio-heci,0/0f/0 "
--ovmf /usr/share/acrn/bios/OVMF.fd
vm1
acrn-hypervisor/devicemodel/samples
https://projectacrn.github.io/latest/user-guides/acrn-dm-parameters.html#acrn-dm-parameters

30. Q & A