Arm CCA enablement through the Trusted Firmware community project
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 287 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/57114 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2022223 / 287
2
4
6
8
12
17
21
23
31
35
37
41
44
45
46
47
50
62
65
66
67
68
71
73
81
84
85
86
90
92
94
100
102
105
111
114
115
116
117
118
121
122
124
127
131
133
135
137
139
140
141
142
145
149
150
156
164
165
167
169
170
171
172
174
176
178
180
183
184
189
190
192
194
198
205
206
207
208
210
218
220
224
225
229
230
232
235
236
238
239
240
242
243
244
245
246
249
250
253
260
262
264
267
273
274
277
282
283
287
00:00
Element (mathematics)FirmwareArmComputerProjective planeMeeting/Interview
00:19
Canonical correlationStandard deviationModul <Datentyp>Information securityTime zoneRead-only memorySession Initiation ProtocolChainVirtualizationComputer hardwareSoftwareIntegrated development environmentCodeComputerForm (programming)BuildingVirtualizationSemiconductor memoryTime zoneDifferent (Kate Ryan album)Computer wormBootingBitIntegrated development environmentComputer architectureComputer programmingNumberWorkloadWindowKernel (computing)Run time (program lifecycle phase)Point (geometry)Standard deviationCombinational logicCategory of beingService (economics)MultilaterationComputer hardwarePhysical systemType theoryArmCASE <Informatik>Primitive (album)Operating systemLaptopComputer animation
03:22
Address spaceTime zoneInformation securityCoprocessorState of matterRead-only memoryBoundary value problemAsynchronous Transfer ModeMechanism designLevel (video gaming)OrthogonalityComputer hardwareComputer architectureCanonical correlationSpeicherschutzCartesian coordinate systemCASE <Informatik>Android (robot)CoprocessorSemiconductor memoryComputer wormData managementState of matterComputer animation
04:19
Table (information)Level (video gaming)Web pageCanonical correlationRead-only memoryAddress spaceData managementComputer architectureComputerInformation securityReal numberBuildingIntegrated development environmentMathematical analysisPhysical systemAerodynamicsScheduling (computing)SoftwareTime zoneIntegrated development environmentData managementStandard deviationWeb pageComputer wormEndliche ModelltheorieInformation securityState of matterDifferent (Kate Ryan album)Run time (program lifecycle phase)Data structureMemory managementExtension (kinesiology)Semiconductor memoryComputer architectureTable (information)WindowWorkloadProgram flowchart
06:10
Scheduling (computing)Read-only memoryReal numberIntelSimilarity (geometry)EncryptionVirtual realityCovering spaceMemory managementLevel (video gaming)Virtual machineMechanism designComputer architectureDomain nameDifferent (Kate Ryan album)Semiconductor memoryBootingKey (cryptography)Cycle (graph theory)Time zoneComputer wormEncryptionBoundary value problemLevel (video gaming)Scheduling (computing)Computer animation
07:25
Directed setCoprocessorPhysical systemCanonical correlationReal numberData modelData integrityAliasingRead-only memoryMemory managementReverse engineeringInjektivitätQuicksortLevel (video gaming)Reading (process)SoftwarePhysical systemEndliche ModelltheorieBefehlsprozessorTerm (mathematics)Computer architectureMemory managementComputer hardwarePrimitive (album)Time zoneState of matterINTEGRALCoprocessorXML
09:16
Hyperbolic functionReal numberInterface (computing)Java remote method invocationData managementService (economics)Read-only memoryAerodynamicsBefehlsprozessorMeasurementLevel (video gaming)Table (information)Translation (relic)SoftwareComputer architectureCanonical correlationImplementationInformation securityState of matterComputer programmingFirmwareOpen sourceGeneric programmingBootingFunction (mathematics)MathematicsFirmwareComputer architectureInterface (computing)Service (economics)Real numberScheduling (computing)Element (mathematics)ImplementationMereologySoftwareProjective planeMathematicsComputer hardwareSemiconductor memoryDifferent (Kate Ryan album)Data managementRight angleShared memorySupercomputerMechanism designDescriptive statisticsBootingLatent heatSlide ruleCodeComputer programmingBoundary value problemSeitentabelleMemory managementKey (cryptography)BitArmOperating systemNumberTable (information)MeasurementContext awarenessState of matterInformation securityContent (media)Process (computing)Traffic reportingComputer worm2 (number)Computer animation
12:55
Data managementSoftwareWhiteboardGroup actionOpen sourceMeeting/Interview
13:13
FirmwareWhiteboardOpen setElement (mathematics)ImplementationSoftwareOpen sourceService (economics)Transport Layer SecurityMobile WebGoogolVirtualizationProjective planeWhiteboardOpen setSoftwareSet (mathematics)Extension (kinesiology)Direction (geometry)Integrated development environmentComputing platformCryptographyData storage deviceFirmwareData managementImplementationArmPartition (number theory)Physical systemDifferent (Kate Ryan album)Right angleService (economics)Open sourceInformation securityMereologyElectronic mailing listLibrary (computing)Social classCoprocessorElement (mathematics)Process (computing)Incidence algebraComputer animation
15:23
Virtual realityReal numberCanonical correlationOpen sourceRead-only memoryVideo trackingTime evolutionComputer configurationComputer-generated imageryLibrary (computing)Computer wormSoftware testingField extensionCodeComputer architectureInternet forumSoftwareCompilerData modelOpen setFirmwareInformation securitySoftware developerComputer-generated imagerySoftware testingDiagramExtension (kinesiology)CodePresentation of a groupProjective planeSoftware developerLink (knot theory)TrailArmEndliche ModelltheorieImplementationInformationComputing platformPhysical systemAsynchronous Transfer ModeData managementDynamical systemSoftwareCompilation albumFirmwareSoftware development kitInternet forumSoftware maintenanceMathematicsOpen setServer (computing)Expert systemLibrary (computing)SpeicherschutzEmailElectronic mailing listTable (information)MereologyInterface (computing)Point (geometry)Boundary value problemFlagComputer wormComputer architectureConnectivity (graph theory)Computer animation
19:32
SimulationAsynchronous Transfer ModeComputer animation
19:59
Virtual machineEndliche ModelltheorieVirtual realityArmRegular graphFirmwareLevel (video gaming)WebsiteComputer architectureComputing platformField extensionPerfect groupMereologyLink (knot theory)Software developerExtension (kinesiology)Meeting/Interview
21:08
Canonical correlationBlock (periodic table)Key (cryptography)BitBuildingTime zoneComputer animation
21:25
Computer architectureComputing platformInternet service providerSlide ruleArmInformationAngleFirmwareData managementCanonical correlationIntelMeasurementExtension (kinesiology)Traffic reportingPatch (Unix)Equivalence relationDomain nameMeeting/Interview
23:05
Computer animation
Transcript: English(auto-generated)
00:07
Hi, my name is Charles Garcia-Tobin and I'm here to talk to you about the Arm Confidential Computer Architecture and I'm joined by my colleague Matto Carlini who will talk to you later about the trusted firmware project. So what is Arm Confidential Computing for Arm?
00:23
Confidential computing for us is about protecting data whilst it's in use from more privileged workloads such as hypervisors or kernels that actually manage the program, the data that programs are using and we do this by adding by hardware protected environments.
00:41
So actually through the years we've added a number of different technologies in the architecture that provide different forms of isolation that can be used to build confidential computing systems. So trust zone is something we've had in the architecture for a long time and many of you will have Android phones and you'll be running trust in your phones today or you might have
01:03
laptops that are based on Arm and you'll be running trust in those. It's actually used throughout all ecosystems and what it does is it gives a fixed environment where you can protect workloads from the hypervisor or operating systems effectively
01:22
from the host and by fixed environment I mean that typically the memory that's used for those environments is carved out at boot and there's no instructions in the ISO or architectural primitives by which you can make that memory bigger or smaller at runtime depending on a use case. Virtualization is something we added later. Virtualization can be used to protect a payload
01:46
from a host operating system and if you use a type one kind of environment with a primary kernel you can protect in one VM and a service in another VM you can protect that service from primary kernel and that's one example of confidential computing though you do have
02:06
to trust that hypervisor. That said you can have as much memory as you want in general because most of the memory is made available to the hypervisor. Arm CCA kind of combines the properties of trust zone and virtualization in that it provides
02:23
an environment where you can protect a payload from the host operating system or hypervisor and even from actual existing trust zone code because we do provide backward compatibility for trust zone but you can use as much memory as you need so at runtime you can pick whether
02:43
a workload is going to be protected by Arm CCA or not and also for Arm CCA another point of difference with trust zone is that you can use its aims to be a primary standard OS feature so the way by which you manage or interact with a secured payload is a primary feature of the
03:06
operating system you use and the operating systems that you run inside the payload are also standard so you could run Linux or Windows inside one of these payloads which is not the same now they're not typically well not the way trust zone has effectively been used by the industry. So very quickly I just wanted to provide a bit of background with trust zone
03:28
and what it does and fundamentally it just divides the state of the processor into being a secure state or a non-secure state and it also divides the resources really mainly memory into secure memory and non-secure memory so when the processor is in a secure state it can
03:45
access all of the memory it can access a secure memory and it can access the non-secure memory but when it's running in the non-secure state which is where the vast majority of use cases will run where for example in an android device where android would run and the applications you download then it can only access the non-secure memory so by
04:06
definition most of the memory will be non-secure memory and you carve out a small amount of secure memory for the secure payloads which be things like payment or credentials management for example with the art confidential computer architecture and the real name I could actually really is the
04:26
realm management extension so you will see us make the use of the acronym RME quite often we introduce a new environment called a realm and realms are actually and the realm environment it's actually very very similar to the trust zone secure environment in that a realm has access to
04:46
private memory that's only accessible within realms but it can also share with non-secure and access non-secure memory realm and secure cannot access each other and you might be asking well why why introduce a new environment and it's really because we wanted to provide backward
05:03
compatibility for users of trust zone but also because we wanted to run as I mentioned earlier very standard workloads so in a realm realms are really aimed at being able to run linux or being able to run windows you know standard standard payload with standard software so there are actual minor architectural differences between realms and trust zone secure world payloads
05:28
and architecture the other big difference between the trust zone world and the new rail management extension is that we've added a concept of dynamic memory so at runtime we
05:42
have a data structure called the granular protection table which tells you where a page of memory lives whether it's a page that can only be accessed by a realm or a page that can only be accessed by a secure security state payload trust and payload or whether it's a general non-secure page that any anybody can access so that's in a nutshell a very quick summarized
06:07
nutshell what CCA is all about so one good mental model for our CCA if you're familiar with these other architectures is AMD SCV or Intel TDX and that like those we protect up to the
06:22
level of virtual machines so if you're familiar with an AMD SCV VM or an Intel trust domain a realm is very similar it's it's a virtual machine where the hypervisor has all of the illusions that it's managing it and the hypervisor owns scheduling it and creating destroying it adding or removing memory from it but it's actually running on the other
06:44
side of an isolation boundary so if the hypervisor tries to access the memory of the realm it's going to take a fault there's where it's slightly different to other architectures different architectures have different protection mechanisms for us it's primarily a faulting so any access by the hypervisor or any other non-secure payload or a trust zone payload would cause
07:05
those to fault we do also have encryption but we primarily use that for reboot attacks so on every reboot we recycle the keys that are used for encryption so any memory that was left over from the previous boot cycle is now effectively garbage if you think of it in the
07:27
terms of threat model the realm threat model is one of confidentiality and integrity but not one of availability so as i already mentioned previously if a host hypervisor or the host
07:40
operating system or trust zone tries to access realm data or register state it will take a fault and that's whether it's trying to access it for read which would be confidentiality or access it for write which would be integrity and this is true not just for processors but also for devices that might try and do this through dma it is not an availability threat model so
08:06
the hypervisor host operating system is always earning their resources including the scheduling and so it can decide when to schedule around and if it gets hacked or just decided never to schedule around then that realm will not run the reverse though is not the reverse that's not
08:23
true so for that we do provide some support so if around tried to steal the CPU for itself and not allow the hypervisor to run it would fail and that's not something around can actually do architecturally we do also provide support for known software injection attacks things such
08:40
as clock screw which we do through a sort of system architecture ssc level requirements and also for non-site channels to spectra meltdown though for that you do expect the realm software itself to use make use of new architectural primitives that were introduced when spectra meltdown first appeared back in 2018. Finally it's not a we don't protect against
09:08
DRAM probe and replay in this architecture if a piece of silicon needs protection from that it needs to provide additional hardware. One of the design goals for this architecture was to
09:22
keep the hardware requirements very simple because ARM operates on anything from a watch right up to a supercomputer so we need to create an architecture that's implementable across all of those different segments but that in turn implies firmware support to actually exercise the capabilities these protection capabilities that we added to the architecture
09:42
So there are some key firmware elements that are very much part of the whole picture of ARM CCA. The first one is the realm management monitor and the realm management monitor exposes two different interfaces one interface is for the hypervisors and is used for the actual management of realms so it's how that interface is how hypervisors can
10:03
actually add or remove memory to realm create a realm schedule around so it can execute and so on and the second is the realm services interface which is about providing services to the realm itself so this is for example how realms can obtain attestation reports which is
10:23
the way by which they can ensure that they're running on a real correct implementation of ARM CCA and also know what the measurements of the initial content of the realm are so they know the payload that's running in there is what is expected The monitor is another key piece of firmware and its job is to primarily to perform
10:44
context switching between the different security states so between realm state to non-secure state and secure state and also to program this granule protection table I mentioned earlier which is what gives us the dynamic memory capability. This obviously has a number of
11:02
software impacts and I'm going to talk a little bit more about that but I just wanted to leave you the last slide obviously we need to provide the RMM and the monitor and our intention is to do that through the opensourcetrustedfirmware.org project that Mattel will talk about there are impacts to the host primarily because now to manage these realms it has to go through
11:23
the realm management interface rather than directly accessing the you know it can't directly program the page tables for them for example or it can't directly schedule them it has to go through this interface so there's impacts there the policy code is unaffected but the actual mechanics are affected and also it has to be able to manage these new faults that are introduced by the
11:44
isolation boundaries that we've introduced so if it tries to access real memory as I said earlier it will take a fault and obviously handling that fault is a new concept and it will require enlightenment. There's no impacts to the actual host firmware whether it's the bootloader or
12:04
the description because most of the way in which we expose the realm management interface is through the use of instructions that we already have in the architecture and specifications that are associated with those instructions. Then the guest software also has some impacts primarily if it wants to be able to make use of both the private realm memory
12:25
and share with a non-secure it needs to understand that there are these two different kinds of memory and if it wants to make use of attestation services or measurement services then it needs to understand the realm services interface and this affects both the actual operating system
12:42
itself but also it affects changes it affects the in-realm firmware so projects such as a VMF for example will be impacted by this and with that I will hand you over to Matteo. Thanks Charles. Hello everyone I'm Matteo Carlini. I'm a director of software technology management
13:02
in the open source software group at Aon but I'm also the chairman of the board of the trustedfirmware.org community project. So let me start precisely by introducing the trusted firmware open governance community project. It's a set of projects it's an umbrella project that provides a reference open source implementation for all the secure software
13:25
running on ARM processors across all market segments. The membership is open to all and the governance is overseen by two main governing bodies the board of directors which oversees the financial and strategic direction of the project so deciding on investments marketing
13:47
campaigns new projects being added to trusted firmware and then the other body is the technical steering committee which decides on technical matters which affects all the projects for example one of the big outcome recently has been the introduction of a brand new security incident
14:04
handling process for all the projects part of trusted firmware. So who are the company members and the projects there you go you can see list of companies from all different segments and projects on the right hand side there is a reference implementation for the secure firmware
14:24
running on both the A class and the M class processors which is trusted firmware A, TFA and trusted firmware M, TFM. There is OpT which is a reference implementation of a trusted execution environment there is Hafnium a reference secure partition manager for the A class
14:44
virtualization extension and then EmbedTLS the very popular crypto library and trusted services which provides a set of predefined secure services like crypto storage and attestation
15:00
that can be deployed on on your platforms all of that is also governed by an OpenCI system which has been a big investment by the project in the past couple of years there are member boards both for TFA and TFM which runs continuously on the OpenCI and check every commit
15:23
so how does this intersect with the ARM CCA enablement that Charles has just spoken about so let's go back to the architectural diagram describing all the software pieces for ARM CCA and this is where trustedfirmware.org comes into play so you can see that the monitor
15:43
running in the monitor mode will be deployed and is already delivered in the open as part of TFA it's an extension of the trusted firmware A project that we call TFA monitor there are changes in into the Hafnium SPM as well primarily for handling dynamic secure memory
16:05
support and then as Charles mentioned there is a new component as well which is called the Rail Management Monitor the RMM which will be deployed and delivered and developed in the open as a brand new trusted firmware project the name is provisional but might be called TFRMM so
16:27
trusted firmware implementation of the RMM code which is the status of play as of today so the TFRMM is currently under internal development in ARM it will be published as part of
16:41
trustedfirmware.org together with the first implementation of the spec and the first publication of the spec somewhere later this year and from that point onwards we foresee a continuous development in the open tracking the evolution of the spec the TFA monitor code like I said has been already delivered and tagged as part of an official TFA release TFA 2.6
17:05
last November if you look in the code there is an enable flag enable RME which provides the support for the RME extension as part of TFA that provides support for the forwards image provides an initial support for an RMM image together with test realm payload code that which
17:27
tests the interfaces across boundaries it also implements the GPT the ground protection table library support finally changes in the half new SPM are ongoing and will be ongoing
17:41
in the coming months again precisely for support GPT and the SMME extension how to collaborate in the effort well with all the means provided by the open governance trusted firmware project we have open mailing lists that everyone can subscribe to and comment on the code will be discussed in there the reviews will be happening all in the public
18:06
we have a public get rid server in which all the reviews are happening and then there are public tech forums which are open to everyone topics are selected by the community
18:20
and all the experts all the maintainers join into these forums and discuss the changes that are happening finally there is also already available a starting kit for all the developers to touch CCA with their hands arm has provided support in the compilers for the rel
18:41
management extension there is a base model which provides support for RME again already delivered by arm and the TFA monitor can run on this base model and provide the first example of an RME enabled platform running live on your systems so with that i'm going to encourage
19:06
you to reach out to us for more information we have put here a few links that has been last year anomaly narrow confidential compute day and there are various linear connect presentations about the architecture of CCA which has been developing the open already
19:28
with that i'm done with my presentation and we are happy to take questions now
19:48
simulation mode maybe something like similar to what sgx has or or will it can you say something about that um i can take that one charles if you want that's right i had already
20:01
casted an answer on the chat i'm not sure if people can see it but anyway arm provides modeling platforms as part of the regular architecture updates and these are um are called fast modeling platform which provides a simulation environment um that we affect that runs on a host machine
20:21
and that simulates all the architecture extensions up to a certain level so um i posted the link on the chat i'm not sure if you can see that um but if you look for fixed virtual platforms on the arm on the developer.arm.com website you will find different um modeling
20:42
platforms and there is one which is called architecture model the architecture model or architecture sdp already implements support for the rme extension uh that was presented in this talk so you can use the download and use that on the linux host run trusted firmware
21:01
and play with it already right charles we want to add something no no that's perfect answer all right it makes sense uh another question that i put in the chat earlier um you didn't really touch on the topic of attestation on okay building block for te so can you say something about that and sure it's been a bit missing from plus zone is that something you
21:23
want to address in cca yeah absolutely so attestation is a key requirement in cca um uh obviously with just 20 minutes to talk about the architectures yeah we should have probably had a slide on that uh but um yeah basically in in cca i think one of the slides did cover that we have um you know we have a firmware abi um that's used to
21:49
both to cover the attestation angle but also to manage to manage realms which are our equivalent of amdsc vbms or trusted domains in intel tvx and so there is uh there is the the
22:01
main actually one of the main purposes for having a realm facing api is to provide attestation reports the attestation reports comprise both the platform information you know and we're running on a host that i'm running on a piece of silicon that implements the arm realm management extension correctly but also it involves measurements of all of the firmware that
22:25
provides the tcb for the realm and then and that's what that's kind of the pieces that comprise the platform piece of the attestation and then the other thing we have is we have abi's for um providing measurement support so that realm can also measure its own
22:42
contents and put that into an attestation report as well um so yes absolutely attestation is one of the key things we're still working on the firmware abi's um but i think uh probably towards the summer you'll start to see uh specs coming out and we'll start to do some sourcing of those as well of the patches against those specs all right that's great