1# Relocatable Modules (rmodules) 2 3Relocatable modules are currently only used on x86. Relocatable 4modules are executables. Exectuables which can be executed anywhere in 5memory. Anywhere means that the module does not need to be executed 6at a defined memory address which is known at build/link time. For 7coreboot stages like bootblock and romstage it is known at build 8time at which addresses they are executed. For some exectuables it 9is however not known at which specific address they are executed in 10runtime (for example postcar and ramstage). Relocateable modules 11usually allocate the space for the modules just before they are 12supposed to be executed. After enough space is allocated, CBMEM will 13return the location of the allocated space. Now the relocation can be 14done by fixing up all relocation entries in the relocatable module 15based on the location of the binary (which was returned by CBMEM 16at runtime). 17 18# Implementation Details 19 20## build time 21 22At build time the rmodtool (util/cbfstool/rmodtool.c) is used to 23create relocatable modules. The rmodtool basically takes an ELF 24file as an input and writes an ELF as output. It basically does 25a simple conversion from one ELF file to another slighty changed 26ELF file. First the tool makes sure that the ELF file fits a few 27requirements. For example there can only be one segment (loadable 28program header) in the input ELF file. After that it goes through 29the ELF relocation table and takes any entry that applies to the one 30segment we want to load at runtime. The rmodtool will then write all 31these relocation entires in a new ELF section called ".reloc". After 32that the ELF relocation table will be cleared. 33 34One can split the rmodules in two different kinds: 351. coreboot stages (postcar, ramstage) 362. simple binaries (smm, smmstub, sipi\_vector) 37 38They are actually handled the same by the build system and only differ 39in the fact, that they are either coreboot stages or they are not. 40 41In the end the ELF files will have three different ELF sections, 42which are all created by the rmodtool. 431. relocation header (.header) 442. program (.program) 453. relocation entries (.relocs) 46 47## runtime 48 49Either rmodule\_load (lib/rmodule.c) is used directly or through the 50rmodule\_stage\_load (lib/rmodule.c) wrapper. It is used to load the 51stages (postcar and ramstage) or small programs like (sipi\_vector, 52smm, smmstub) into memory before jumping to them. In the case of a 53coreboot stage, CBMEM is used to allocate space for the stage in memory 54via the rmodule\_cbfs\_allocater (lib/rmodule.c). At this point the 55location of the stage in memory is known and all relocation (address 56fixups) need to be done now. This is basically just a simple loop that 57goes through each relocation entry. Each relocation entry is just an 58address pointing to a location that needs relocation. The relocation 59itself is just a simple addition, that adds an offset from where the 60image was "supposed" to be at link time, to where it is now relocated. 61 62## module\_parameters 63 64module\_parameters is a section inside the rmodule ELF file. Its 65basically a way to pass runtime information to an rmodule 66before jumping to it. The caller will use rmodule\_parameters() 67(lib/rmodule.c) to get the runtime address of the module\_parameters 68and the callee (the rmodule itself) usually appends the section to 69specific types via compiler attributes. For example: 70``` 71static const 72volatile __attribute((aligned(4), __section__(".module_parameters"))) 73struct smm_runtime smm_runtime; 74``` 75 76# x86 why rmodules 77//TODO 78x86: postcar and ramstage cannot conflict with payload regarding 79memory placement. Therefore payload location is usually fixed and 80postcar/ramstage can be placed at a location in memory that is 81figured out at runtime. 82