[PATCH] D139092: [LLD][ELF] Cortex-M Security Extensions (CMSE) Support

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

Just a couple of suggestions. I think there is a way of implementing the symbol changes without needing an ObjFile member function. I've also recommended adding a comment to describe the implementation as a whole.



================
Comment at: lld/ELF/Arch/ARM.cpp:917
 }
 
+// Initialize symbols. symbols is a parallel array to the corresponding ELF
----------------
For the benefit of our future selves I think it would be useful to put a summary comment about how the LLD CMSE code fits together.

The Arm Cortex-M Security Extensions (CMSE) splits a system into two parts, the non-secure and secure states with the secure state inaccessible from the non-secure state, apart from an area of memory in secure state called the secure gateway which is accessible from non-secure state. The secure gateway contains one or more entry points which must start with a landing pad instruction SG. Arm recommends that the secure gateway consists only of secure gateway veneers, which are made up of a SG instruction followed by a branch to the destination in secure state. Full details can be found in Arm v8-M Security Extensions Requirements on Development Tools.

The CMSE model of software development requires the non-secure and secure states to be developed as two separate programs. The non-secure developer is provided with an import library defining symbols describing the entry points in the secure gateway. No additional linker support is required for the non-secure state.

Development of the secure state requires linker support to manage the secure gateway veneers. The management consists of:
* Creation of new secure gateway veneers based on symbol conventions.
* Checking the address of existing secure gateway veneers.
* Warning when existing secure gateway veneers removed.

The secure gateway veneers are created in an import library, which is just an ELF object with a symbol table. The import library is controlled by two command line options:
--in-implib (specify an input import library from a previous revision of the program).
--out-implib (specify an output import library to be created by the linker).

The input import library is used to manage consistency of the secure entry points. The output import library is for new and updated secure entry points.

The symbol convention that identifies secure entry functions is the prefix __acle_se_ for a symbol called name the linker is expected to create a secure gateway veneer if symbols __acles_se_name and name have the same address. After creating a secure gateway veneer the symbol name labels the secure gateway veneer and the __acle_se_name labels the function definition.

The LLD implementation:
* Reads an existing import library with importCmseSymbols().
* Determines which new secure gateway veneers to create and redirects calls within the secure state to the __acle_se_ prefixed symbol with processCmseSymbols().
* Models the SG veneers as a synthetic section.




================
Comment at: lld/ELF/Arch/ARM.cpp:975
+    case ELF32LEKind:
+      cast<ObjFile<ELF32LE>>(f)->redirectCmseSymbols();
+      break;
----------------
wrapSymbols does something similar but uses `file->getMutableSymbols()` are we able to use this instead as it will mean that we don't need redirectCmseSymbols() in ObjFile.

The code in wrapSymbols is:
```
 parallelForEach(symtab->objectFiles, [&](InputFile *file) {
    MutableArrayRef<Symbol *> syms = file->getMutableSymbols();
    for (size_t i = 0, e = syms.size(); i != e; ++i)
      if (Symbol *s = map.lookup(syms[i]))
        syms[i] = s;
  });
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139092/new/

https://reviews.llvm.org/D139092