1Secure Partition Manager (MM) 2***************************** 3 4Foreword 5======== 6 7Two implementations of a Secure Partition Manager co-exist in the TF-A codebase: 8 9- SPM based on the PSA FF-A specification (`Secure Partition Manager`__). 10- SPM based on the MM interface. 11 12.. __: secure-partition-manager.html 13 14Both implementations differ in their architectures and only one can be selected 15at build time. 16 17This document describes the latter implementation where the Secure Partition Manager 18resides at EL3 and management services run from isolated Secure Partitions at S-EL0. 19The communication protocol is established through the Management Mode (MM) interface. 20 21Background 22========== 23 24In some market segments that primarily deal with client-side devices like mobile 25phones, tablets, STBs and embedded devices, a Trusted OS instantiates trusted 26applications to provide security services like DRM, secure payment and 27authentication. The Global Platform TEE Client API specification defines the API 28used by Non-secure world applications to access these services. A Trusted OS 29fulfils the requirements of a security service as described above. 30 31Management services are typically implemented at the highest level of privilege 32in the system, i.e. EL3 in Trusted Firmware-A (TF-A). The service requirements are 33fulfilled by the execution environment provided by TF-A. 34 35The following diagram illustrates the corresponding software stack: 36 37|Image 1| 38 39In other market segments that primarily deal with server-side devices (e.g. data 40centres and enterprise servers) the secure software stack typically does not 41include a Global Platform Trusted OS. Security functions are accessed through 42other interfaces (e.g. ACPI TCG TPM interface, UEFI runtime variable service). 43 44Placement of management and security functions with diverse requirements in a 45privileged Exception Level (i.e. EL3 or S-EL1) makes security auditing of 46firmware more difficult and does not allow isolation of unrelated services from 47each other either. 48 49Introduction 50============ 51 52A **Secure Partition** is a software execution environment instantiated in 53S-EL0 that can be used to implement simple management and security services. 54Since S-EL0 is an unprivileged Exception Level, a Secure Partition relies on 55privileged firmware (i.e. TF-A) to be granted access to system and processor 56resources. Essentially, it is a software sandbox in the Secure world that runs 57under the control of privileged software, provides one or more services and 58accesses the following system resources: 59 60- Memory and device regions in the system address map. 61 62- PE system registers. 63 64- A range of synchronous exceptions (e.g. SMC function identifiers). 65 66Note that currently TF-A only supports handling one Secure Partition. 67 68A Secure Partition enables TF-A to implement only the essential secure 69services in EL3 and instantiate the rest in a partition in S-EL0. 70Furthermore, multiple Secure Partitions can be used to isolate unrelated 71services from each other. 72 73The following diagram illustrates the place of a Secure Partition in a typical 74Armv8-A software stack. A single or multiple Secure Partitions provide secure 75services to software components in the Non-secure world and other Secure 76Partitions. 77 78|Image 2| 79 80The TF-A build system is responsible for including the Secure Partition image 81in the FIP. During boot, BL2 includes support to authenticate and load the 82Secure Partition image. A BL31 component called **Secure Partition Manager 83(SPM)** is responsible for managing the partition. This is semantically 84similar to a hypervisor managing a virtual machine. 85 86The SPM is responsible for the following actions during boot: 87 88- Allocate resources requested by the Secure Partition. 89 90- Perform architectural and system setup required by the Secure Partition to 91 fulfil a service request. 92 93- Implement a standard interface that is used for initialising a Secure 94 Partition. 95 96The SPM is responsible for the following actions during runtime: 97 98- Implement a standard interface that is used by a Secure Partition to fulfil 99 service requests. 100 101- Implement a standard interface that is used by the Non-secure world for 102 accessing the services exported by a Secure Partition. A service can be 103 invoked through a SMC. 104 105Alternatively, a partition can be viewed as a thread of execution running under 106the control of the SPM. Hence common programming concepts described below are 107applicable to a partition. 108 109Description 110=========== 111 112The previous section introduced some general aspects of the software 113architecture of a Secure Partition. This section describes the specific choices 114made in the current implementation of this software architecture. Subsequent 115revisions of the implementation will include a richer set of features that 116enable a more flexible architecture. 117 118Building TF-A with Secure Partition support 119------------------------------------------- 120 121SPM is supported on the Arm FVP exclusively at the moment. The current 122implementation supports inclusion of only a single Secure Partition in which a 123service always runs to completion (e.g. the requested services cannot be 124preempted to give control back to the Normal world). 125 126It is not currently possible for BL31 to integrate SPM support and a Secure 127Payload Dispatcher (SPD) at the same time; they are mutually exclusive. In the 128SPM bootflow, a Secure Partition image executing at S-EL0 replaces the Secure 129Payload image executing at S-EL1 (e.g. a Trusted OS). Both are referred to as 130BL32. 131 132A working prototype of a SP has been implemented by re-purposing the EDK2 code 133and tools, leveraging the concept of the *Standalone Management Mode (MM)* in 134the UEFI specification (see the PI v1.6 Volume 4: Management Mode Core 135Interface). This will be referred to as the *Standalone MM Secure Partition* in 136the rest of this document. 137 138To enable SPM support in TF-A, the source code must be compiled with the build 139flag ``SPM_MM=1``, along with ``EL3_EXCEPTION_HANDLING=1``. On Arm 140platforms the build option ``ARM_BL31_IN_DRAM`` must be set to 1. Also, the 141location of the binary that contains the BL32 image 142(``BL32=path/to/image.bin``) must be specified. 143 144First, build the Standalone MM Secure Partition. To build it, refer to the 145`instructions in the EDK2 repository`_. 146 147Then build TF-A with SPM support and include the Standalone MM Secure Partition 148image in the FIP: 149 150.. code:: shell 151 152 BL32=path/to/standalone/mm/sp BL33=path/to/bl33.bin \ 153 make PLAT=fvp SPM_MM=1 EL3_EXCEPTION_HANDLING=1 ARM_BL31_IN_DRAM=1 all fip 154 155Describing Secure Partition resources 156------------------------------------- 157 158TF-A exports a porting interface that enables a platform to specify the system 159resources required by the Secure Partition. Some instructions are given below. 160However, this interface is under development and it may change as new features 161are implemented. 162 163- A Secure Partition is considered a BL32 image, so the same defines that apply 164 to BL32 images apply to a Secure Partition: ``BL32_BASE`` and ``BL32_LIMIT``. 165 166- The following defines are needed to allocate space for the translation tables 167 used by the Secure Partition: ``PLAT_SP_IMAGE_MMAP_REGIONS`` and 168 ``PLAT_SP_IMAGE_MAX_XLAT_TABLES``. 169 170- The functions ``plat_get_secure_partition_mmap()`` and 171 ``plat_get_secure_partition_boot_info()`` have to be implemented. The file 172 ``plat/arm/board/fvp/fvp_common.c`` can be used as an example. It uses the 173 defines in ``include/plat/arm/common/arm_spm_def.h``. 174 175 - ``plat_get_secure_partition_mmap()`` returns an array of mmap regions that 176 describe the memory regions that the SPM needs to allocate for a Secure 177 Partition. 178 179 - ``plat_get_secure_partition_boot_info()`` returns a 180 ``spm_mm_boot_info_t`` struct that is populated by the platform 181 with information about the memory map of the Secure Partition. 182 183For an example of all the changes in context, you may refer to commit 184``e29efeb1b4``, in which the port for FVP was introduced. 185 186Accessing Secure Partition services 187----------------------------------- 188 189The `SMC Calling Convention`_ (*Arm DEN 0028B*) describes SMCs as a conduit for 190accessing services implemented in the Secure world. The ``MM_COMMUNICATE`` 191interface defined in the `Management Mode Interface Specification`_ (*Arm DEN 1920060A*) is used to invoke a Secure Partition service as a Fast Call. 193 194The mechanism used to identify a service within the partition depends on the 195service implementation. It is assumed that the caller of the service will be 196able to discover this mechanism through standard platform discovery mechanisms 197like ACPI and Device Trees. For example, *Volume 4: Platform Initialisation 198Specification v1.6. Management Mode Core Interface* specifies that a GUID is 199used to identify a management mode service. A client populates the GUID in the 200``EFI_MM_COMMUNICATE_HEADER``. The header is populated in the communication 201buffer shared with the Secure Partition. 202 203A Fast Call appears to be atomic from the perspective of the caller and returns 204when the requested operation has completed. A service invoked through the 205``MM_COMMUNICATE`` SMC will run to completion in the partition on a given CPU. 206The SPM is responsible for guaranteeing this behaviour. This means that there 207can only be a single outstanding Fast Call in a partition on a given CPU. 208 209Exchanging data with the Secure Partition 210----------------------------------------- 211 212The exchange of data between the Non-secure world and the partition takes place 213through a shared memory region. The location of data in the shared memory area 214is passed as a parameter to the ``MM_COMMUNICATE`` SMC. The shared memory area 215is statically allocated by the SPM and is expected to be either implicitly known 216to the Non-secure world or discovered through a platform discovery mechanism 217e.g. ACPI table or device tree. It is possible for the Non-secure world to 218exchange data with a partition only if it has been populated in this shared 219memory area. The shared memory area is implemented as per the guidelines 220specified in Section 3.2.3 of the `Management Mode Interface Specification`_ 221(*Arm DEN 0060A*). 222 223The format of data structures used to encapsulate data in the shared memory is 224agreed between the Non-secure world and the Secure Partition. For example, in 225the `Management Mode Interface specification`_ (*Arm DEN 0060A*), Section 4 226describes that the communication buffer shared between the Non-secure world and 227the Management Mode (MM) in the Secure world must be of the type 228``EFI_MM_COMMUNICATE_HEADER``. This data structure is defined in *Volume 4: 229Platform Initialisation Specification v1.6. Management Mode Core Interface*. 230Any caller of a MM service will have to use the ``EFI_MM_COMMUNICATE_HEADER`` 231data structure. 232 233Runtime model of the Secure Partition 234===================================== 235 236This section describes how the Secure Partition interfaces with the SPM. 237 238Interface with SPM 239------------------ 240 241In order to instantiate one or more secure services in the Secure Partition in 242S-EL0, the SPM should define the following types of interfaces: 243 244- Interfaces that enable access to privileged operations from S-EL0. These 245 operations typically require access to system resources that are either shared 246 amongst multiple software components in the Secure world or cannot be directly 247 accessed from an unprivileged Exception Level. 248 249- Interfaces that establish the control path between the SPM and the Secure 250 Partition. 251 252This section describes the APIs currently exported by the SPM that enable a 253Secure Partition to initialise itself and export its services in S-EL0. These 254interfaces are not accessible from the Non-secure world. 255 256Conduit 257^^^^^^^ 258 259The `SMC Calling Convention`_ (*Arm DEN 0028B*) specification describes the SMC 260and HVC conduits for accessing firmware services and their availability 261depending on the implemented Exception levels. In S-EL0, the Supervisor Call 262exception (SVC) is the only architectural mechanism available for unprivileged 263software to make a request for an operation implemented in privileged software. 264Hence, the SVC conduit must be used by the Secure Partition to access interfaces 265implemented by the SPM. 266 267A SVC causes an exception to be taken to S-EL1. TF-A assumes ownership of S-EL1 268and installs a simple exception vector table in S-EL1 that relays a SVC request 269from a Secure Partition as a SMC request to the SPM in EL3. Upon servicing the 270SMC request, Trusted Firmware-A returns control directly to S-EL0 through an 271ERET instruction. 272 273Calling conventions 274^^^^^^^^^^^^^^^^^^^ 275 276The `SMC Calling Convention`_ (*Arm DEN 0028B*) specification describes the 27732-bit and 64-bit calling conventions for the SMC and HVC conduits. The SVC 278conduit introduces the concept of SVC32 and SVC64 calling conventions. The SVC32 279and SVC64 calling conventions are equivalent to the 32-bit (SMC32) and the 28064-bit (SMC64) calling conventions respectively. 281 282Communication initiated by SPM 283^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 284 285A service request is initiated from the SPM through an exception return 286instruction (ERET) to S-EL0. Later, the Secure Partition issues an SVC 287instruction to signal completion of the request. Some example use cases are 288given below: 289 290- A request to initialise the Secure Partition during system boot. 291 292- A request to handle a runtime service request. 293 294Communication initiated by Secure Partition 295^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 296 297A request is initiated from the Secure Partition by executing a SVC instruction. 298An ERET instruction is used by TF-A to return to S-EL0 with the result of the 299request. 300 301For instance, a request to perform privileged operations on behalf of a 302partition (e.g. management of memory attributes in the translation tables for 303the Secure EL1&0 translation regime). 304 305Interfaces 306^^^^^^^^^^ 307 308The current implementation reserves function IDs for Fast Calls in the Standard 309Secure Service calls range (see `SMC Calling Convention`_ (*Arm DEN 0028B*) 310specification) for each API exported by the SPM. This section defines the 311function prototypes for each function ID. The function IDs specify whether one 312or both of the SVC32 and SVC64 calling conventions can be used to invoke the 313corresponding interface. 314 315Secure Partition Event Management 316^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 317 318The Secure Partition provides an Event Management interface that is used by the 319SPM to delegate service requests to the Secure Partition. The interface also 320allows the Secure Partition to: 321 322- Register with the SPM a service that it provides. 323- Indicate completion of a service request delegated by the SPM 324 325Miscellaneous interfaces 326------------------------ 327 328``SPM_MM_VERSION_AARCH32`` 329^^^^^^^^^^^^^^^^^^^^^^^^^^ 330 331- Description 332 333 Returns the version of the interface exported by SPM. 334 335- Parameters 336 337 - **uint32** - Function ID 338 339 - SVC32 Version: **0x84000060** 340 341- Return parameters 342 343 - **int32** - Status 344 345 On success, the format of the value is as follows: 346 347 - Bit [31]: Must be 0 348 - Bits [30:16]: Major Version. Must be 0 for this revision of the SPM 349 interface. 350 - Bits [15:0]: Minor Version. Must be 1 for this revision of the SPM 351 interface. 352 353 On error, the format of the value is as follows: 354 355 - ``NOT_SUPPORTED``: SPM interface is not supported or not available for the 356 client. 357 358- Usage 359 360 This function returns the version of the Secure Partition Manager 361 implementation. The major version is 0 and the minor version is 1. The version 362 number is a 31-bit unsigned integer, with the upper 15 bits denoting the major 363 revision, and the lower 16 bits denoting the minor revision. The following 364 rules apply to the version numbering: 365 366 - Different major revision values indicate possibly incompatible functions. 367 368 - For two revisions, A and B, for which the major revision values are 369 identical, if the minor revision value of revision B is greater than the 370 minor revision value of revision A, then every function in revision A must 371 work in a compatible way with revision B. However, it is possible for 372 revision B to have a higher function count than revision A. 373 374- Implementation responsibilities 375 376 If this function returns a valid version number, all the functions that are 377 described subsequently must be implemented, unless it is explicitly stated 378 that a function is optional. 379 380See `Error Codes`_ for integer values that are associated with each return 381code. 382 383Secure Partition Initialisation 384------------------------------- 385 386The SPM is responsible for initialising the architectural execution context to 387enable initialisation of a service in S-EL0. The responsibilities of the SPM are 388listed below. At the end of initialisation, the partition issues a 389``MM_SP_EVENT_COMPLETE_AARCH64`` call (described later) to signal readiness for 390handling requests for services implemented by the Secure Partition. The 391initialisation event is executed as a Fast Call. 392 393Entry point invocation 394^^^^^^^^^^^^^^^^^^^^^^ 395 396The entry point for service requests that should be handled as Fast Calls is 397used as the target of the ERET instruction to start initialisation of the Secure 398Partition. 399 400Architectural Setup 401^^^^^^^^^^^^^^^^^^^ 402 403At cold boot, system registers accessible from S-EL0 will be in their reset 404state unless otherwise specified. The SPM will perform the following 405architectural setup to enable execution in S-EL0 406 407MMU setup 408^^^^^^^^^ 409 410The platform port of a Secure Partition specifies to the SPM a list of regions 411that it needs access to and their attributes. The SPM validates this resource 412description and initialises the Secure EL1&0 translation regime as follows. 413 4141. Device regions are mapped with nGnRE attributes and Execute Never 415 instruction access permissions. 416 4172. Code memory regions are mapped with RO data and Executable instruction access 418 permissions. 419 4203. Read Only data memory regions are mapped with RO data and Execute Never 421 instruction access permissions. 422 4234. Read Write data memory regions are mapped with RW data and Execute Never 424 instruction access permissions. 425 4265. If the resource description does not explicitly describe the type of memory 427 regions then all memory regions will be marked with Code memory region 428 attributes. 429 4306. The ``UXN`` and ``PXN`` bits are set for regions that are not executable by 431 S-EL0 or S-EL1. 432 433System Register Setup 434^^^^^^^^^^^^^^^^^^^^^ 435 436System registers that influence software execution in S-EL0 are setup by the SPM 437as follows: 438 4391. ``SCTLR_EL1`` 440 441 - ``UCI=1`` 442 - ``EOE=0`` 443 - ``WXN=1`` 444 - ``nTWE=1`` 445 - ``nTWI=1`` 446 - ``UCT=1`` 447 - ``DZE=1`` 448 - ``I=1`` 449 - ``UMA=0`` 450 - ``SA0=1`` 451 - ``C=1`` 452 - ``A=1`` 453 - ``M=1`` 454 4552. ``CPACR_EL1`` 456 457 - ``FPEN=b'11`` 458 4593. ``PSTATE`` 460 461 - ``D,A,I,F=1`` 462 - ``CurrentEL=0`` (EL0) 463 - ``SpSel=0`` (Thread mode) 464 - ``NRW=0`` (AArch64) 465 466General Purpose Register Setup 467^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 468 469SPM will invoke the entry point of a service by executing an ERET instruction. 470This transition into S-EL0 is special since it is not in response to a previous 471request through a SVC instruction. This is the first entry into S-EL0. The 472general purpose register usage at the time of entry will be as specified in the 473"Return State" column of Table 3-1 in Section 3.1 "Register use in AArch64 SMC 474calls" of the `SMC Calling Convention`_ (*Arm DEN 0028B*) specification. In 475addition, certain other restrictions will be applied as described below. 476 4771. ``SP_EL0`` 478 479 A non-zero value will indicate that the SPM has initialised the stack pointer 480 for the current CPU. 481 482 The value will be 0 otherwise. 483 4842. ``X4-X30`` 485 486 The values of these registers will be 0. 487 4883. ``X0-X3`` 489 490 Parameters passed by the SPM. 491 492 - ``X0``: Virtual address of a buffer shared between EL3 and S-EL0. The 493 buffer will be mapped in the Secure EL1&0 translation regime with read-only 494 memory attributes described earlier. 495 496 - ``X1``: Size of the buffer in bytes. 497 498 - ``X2``: Cookie value (*IMPLEMENTATION DEFINED*). 499 500 - ``X3``: Cookie value (*IMPLEMENTATION DEFINED*). 501 502Runtime Event Delegation 503------------------------ 504 505The SPM receives requests for Secure Partition services through a synchronous 506invocation (i.e. a SMC from the Non-secure world). These requests are delegated 507to the partition by programming a return from the last 508``MM_SP_EVENT_COMPLETE_AARCH64`` call received from the partition. The last call 509was made to signal either completion of Secure Partition initialisation or 510completion of a partition service request. 511 512``MM_SP_EVENT_COMPLETE_AARCH64`` 513^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 514 515- Description 516 517 Signal completion of the last SP service request. 518 519- Parameters 520 521 - **uint32** - Function ID 522 523 - SVC64 Version: **0xC4000061** 524 525 - **int32** - Event Status Code 526 527 Zero or a positive value indicates that the event was handled successfully. 528 The values depend upon the original event that was delegated to the Secure 529 partition. They are described as follows. 530 531 - ``SUCCESS`` : Used to indicate that the Secure Partition was initialised 532 or a runtime request was handled successfully. 533 534 - Any other value greater than 0 is used to pass a specific Event Status 535 code in response to a runtime event. 536 537 A negative value indicates an error. The values of Event Status code depend 538 on the original event. 539 540- Return parameters 541 542 - **int32** - Event ID/Return Code 543 544 Zero or a positive value specifies the unique ID of the event being 545 delegated to the partition by the SPM. 546 547 In the current implementation, this parameter contains the function ID of 548 the ``MM_COMMUNICATE`` SMC. This value indicates to the partition that an 549 event has been delegated to it in response to an ``MM_COMMUNICATE`` request 550 from the Non-secure world. 551 552 A negative value indicates an error. The format of the value is as follows: 553 554 - ``NOT_SUPPORTED``: Function was called from the Non-secure world. 555 556 See `Error Codes`_ for integer values that are associated with each return 557 code. 558 559 - **uint32** - Event Context Address 560 561 Address of a buffer shared between the SPM and Secure Partition to pass 562 event specific information. The format of the data populated in the buffer 563 is implementation defined. 564 565 The buffer is mapped in the Secure EL1&0 translation regime with read-only 566 memory attributes described earlier. 567 568 For the SVC64 version, this parameter is a 64-bit Virtual Address (VA). 569 570 For the SVC32 version, this parameter is a 32-bit Virtual Address (VA). 571 572 - **uint32** - Event context size 573 574 Size of the memory starting at Event Address. 575 576 - **uint32/uint64** - Event Cookie 577 578 This is an optional parameter. If unused its value is SBZ. 579 580- Usage 581 582 This function signals to the SPM that the handling of the last event delegated 583 to a partition has completed. The partition is ready to handle its next event. 584 A return from this function is in response to the next event that will be 585 delegated to the partition. The return parameters describe the next event. 586 587- Caller responsibilities 588 589 A Secure Partition must only call ``MM_SP_EVENT_COMPLETE_AARCH64`` to signal 590 completion of a request that was delegated to it by the SPM. 591 592- Callee responsibilities 593 594 When the SPM receives this call from a Secure Partition, the corresponding 595 syndrome information can be used to return control through an ERET 596 instruction, to the instruction immediately after the call in the Secure 597 Partition context. This syndrome information comprises of general purpose and 598 system register values when the call was made. 599 600 The SPM must save this syndrome information and use it to delegate the next 601 event to the Secure Partition. The return parameters of this interface must 602 specify the properties of the event and be populated in ``X0-X3/W0-W3`` 603 registers. 604 605Secure Partition Memory Management 606---------------------------------- 607 608A Secure Partition executes at S-EL0, which is an unprivileged Exception Level. 609The SPM is responsible for enabling access to regions of memory in the system 610address map from a Secure Partition. This is done by mapping these regions in 611the Secure EL1&0 Translation regime with appropriate memory attributes. 612Attributes refer to memory type, permission, cacheability and shareability 613attributes used in the Translation tables. The definitions of these attributes 614and their usage can be found in the `Armv8-A ARM`_ (*Arm DDI 0487*). 615 616All memory required by the Secure Partition is allocated upfront in the SPM, 617even before handing over to the Secure Partition for the first time. The initial 618access permissions of the memory regions are statically provided by the platform 619port and should allow the Secure Partition to run its initialisation code. 620 621However, they might not suit the final needs of the Secure Partition because its 622final memory layout might not be known until the Secure Partition initialises 623itself. As the Secure Partition initialises its runtime environment it might, 624for example, load dynamically some modules. For instance, a Secure Partition 625could implement a loader for a standard executable file format (e.g. an PE-COFF 626loader for loading executable files at runtime). These executable files will be 627a part of the Secure Partition image. The location of various sections in an 628executable file and their permission attributes (e.g. read-write data, read-only 629data and code) will be known only when the file is loaded into memory. 630 631In this case, the Secure Partition needs a way to change the access permissions 632of its memory regions. The SPM provides this feature through the 633``MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64`` SVC interface. This interface is 634available to the Secure Partition during a specific time window: from the first 635entry into the Secure Partition up to the first ``SP_EVENT_COMPLETE`` call that 636signals the Secure Partition has finished its initialisation. Once the 637initialisation is complete, the SPM does not allow changes to the memory 638attributes. 639 640This section describes the standard SVC interface that is implemented by the SPM 641to determine and change permission attributes of memory regions that belong to a 642Secure Partition. 643 644``MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64`` 645^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 646 647- Description 648 649 Request the permission attributes of a memory region from S-EL0. 650 651- Parameters 652 653 - **uint32** Function ID 654 655 - SVC64 Version: **0xC4000064** 656 657 - **uint64** Base Address 658 659 This parameter is a 64-bit Virtual Address (VA). 660 661 There are no alignment restrictions on the Base Address. The permission 662 attributes of the translation granule it lies in are returned. 663 664- Return parameters 665 666 - **int32** - Memory Attributes/Return Code 667 668 On success the format of the Return Code is as follows: 669 670 - Bits[1:0] : Data access permission 671 672 - b'00 : No access 673 - b'01 : Read-Write access 674 - b'10 : Reserved 675 - b'11 : Read-only access 676 677 - Bit[2]: Instruction access permission 678 679 - b'0 : Executable 680 - b'1 : Non-executable 681 682 - Bit[30:3] : Reserved. SBZ. 683 684 - Bit[31] : Must be 0 685 686 On failure the following error codes are returned: 687 688 - ``INVALID_PARAMETERS``: The Secure Partition is not allowed to access the 689 memory region the Base Address lies in. 690 691 - ``NOT_SUPPORTED`` : The SPM does not support retrieval of attributes of 692 any memory page that is accessible by the Secure Partition, or the 693 function was called from the Non-secure world. Also returned if it is 694 used after ``MM_SP_EVENT_COMPLETE_AARCH64``. 695 696 See `Error Codes`_ for integer values that are associated with each return 697 code. 698 699- Usage 700 701 This function is used to request the permission attributes for S-EL0 on a 702 memory region accessible from a Secure Partition. The size of the memory 703 region is equal to the Translation Granule size used in the Secure EL1&0 704 translation regime. Requests to retrieve other memory region attributes are 705 not currently supported. 706 707- Caller responsibilities 708 709 The caller must obtain the Translation Granule Size of the Secure EL1&0 710 translation regime from the SPM through an implementation defined method. 711 712- Callee responsibilities 713 714 The SPM must not return the memory access controls for a page of memory that 715 is not accessible from a Secure Partition. 716 717``MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64`` 718^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 719 720- Description 721 722 Set the permission attributes of a memory region from S-EL0. 723 724- Parameters 725 726 - **uint32** - Function ID 727 728 - SVC64 Version: **0xC4000065** 729 730 - **uint64** - Base Address 731 732 This parameter is a 64-bit Virtual Address (VA). 733 734 The alignment of the Base Address must be greater than or equal to the size 735 of the Translation Granule Size used in the Secure EL1&0 translation 736 regime. 737 738 - **uint32** - Page count 739 740 Number of pages starting from the Base Address whose memory attributes 741 should be changed. The page size is equal to the Translation Granule Size. 742 743 - **uint32** - Memory Access Controls 744 745 - Bits[1:0] : Data access permission 746 747 - b'00 : No access 748 - b'01 : Read-Write access 749 - b'10 : Reserved 750 - b'11 : Read-only access 751 752 - Bit[2] : Instruction access permission 753 754 - b'0 : Executable 755 - b'1 : Non-executable 756 757 - Bits[31:3] : Reserved. SBZ. 758 759 A combination of attributes that mark the region with RW and Executable 760 permissions is prohibited. A request to mark a device memory region with 761 Executable permissions is prohibited. 762 763- Return parameters 764 765 - **int32** - Return Code 766 767 - ``SUCCESS``: The Memory Access Controls were changed successfully. 768 769 - ``DENIED``: The SPM is servicing a request to change the attributes of a 770 memory region that overlaps with the region specified in this request. 771 772 - ``INVALID_PARAMETER``: An invalid combination of Memory Access Controls 773 has been specified. The Base Address is not correctly aligned. The Secure 774 Partition is not allowed to access part or all of the memory region 775 specified in the call. 776 777 - ``NO_MEMORY``: The SPM does not have memory resources to change the 778 attributes of the memory region in the translation tables. 779 780 - ``NOT_SUPPORTED``: The SPM does not permit change of attributes of any 781 memory region that is accessible by the Secure Partition. Function was 782 called from the Non-secure world. Also returned if it is used after 783 ``MM_SP_EVENT_COMPLETE_AARCH64``. 784 785 See `Error Codes`_ for integer values that are associated with each return 786 code. 787 788- Usage 789 790 This function is used to change the permission attributes for S-EL0 on a 791 memory region accessible from a Secure Partition. The size of the memory 792 region is equal to the Translation Granule size used in the Secure EL1&0 793 translation regime. Requests to change other memory region attributes are not 794 currently supported. 795 796 This function is only available at boot time. This interface is revoked after 797 the Secure Partition sends the first ``MM_SP_EVENT_COMPLETE_AARCH64`` to 798 signal that it is initialised and ready to receive run-time requests. 799 800- Caller responsibilities 801 802 The caller must obtain the Translation Granule Size of the Secure EL1&0 803 translation regime from the SPM through an implementation defined method. 804 805- Callee responsibilities 806 807 The SPM must preserve the original memory access controls of the region of 808 memory in case of an unsuccessful call. The SPM must preserve the consistency 809 of the S-EL1 translation regime if this function is called on different PEs 810 concurrently and the memory regions specified overlap. 811 812Error Codes 813----------- 814 815.. csv-table:: 816 :header: "Name", "Value" 817 818 ``SUCCESS``,0 819 ``NOT_SUPPORTED``,-1 820 ``INVALID_PARAMETER``,-2 821 ``DENIED``,-3 822 ``NO_MEMORY``,-5 823 ``NOT_PRESENT``,-7 824 825-------------- 826 827*Copyright (c) 2017-2020, Arm Limited and Contributors. All rights reserved.* 828 829.. _Armv8-A ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile 830.. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64StandaloneMm/HowtoBuild.MD 831.. _Management Mode Interface Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf 832.. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf 833.. _SMC Calling Convention: https://developer.arm.com/docs/den0028/latest 834 835.. |Image 1| image:: ../resources/diagrams/secure_sw_stack_tos.png 836.. |Image 2| image:: ../resources/diagrams/secure_sw_stack_sp.png 837
