Linux ELF sections: the past, the present and the future

Transcription

1 Linux ELF sections: the past, the present and the future Luis R. Rodriguez SUSE Labs Abstract The Linux kernel has historically made wide use of custom ELF sections. We ll review what has been done historically, and introduce a new set of architecture independent APIs which reduces the amount of work needed to work with them. There s a series of unsuspecting benefits using the new set of APIs though, we ll review the expected short term gains and dive a bit deep into the possibilities for the future. Alternatives will also be considered. Index Terms Linux, ELF, linker tables, section ranges I. INTRODUCTION Linux supports different binary file formats, the Executable and Linking Format (ELF) object file format however has become the preferred object file format used on many Unix like operating systems including Linux. ELF is preffered due to its amazing simplicity, wide market adoption, flexibility, and given it also allows for processor-specific features to be specified and taken advantage of. Processor-specific details which help alter the ELF layout are things such as endianness, should the binary file be 32-bit or 64-bit, data types used for different ELF data structures. The executable code contained in objects is naturally also architecture specific. Linux takes advantage of the ELF feature which enables programs to define object file sections whose format and meaning are determined solely by the program, this is the SHT_PROGBIT section type classifier. In assembly this is observed for most architectures and %progbits on ARM. For instance, although.init is documented as a special ELF section in the System V ABI it is defined as a SHT_PROGBIT section type, so programs can also take advantage and further customize the section for its own functionality if they so desire. Linux takes advantage of this to associate code into the.init.* sections so that after we boot, right before we kick of the first userspace process, we free all code in the.init.* sections, making more memory available to a system, and preventing this code from ever executing again. There are may other specially crafted sections used in Linux which take advantage of SHT_PROGBIT though. Another example is the.builtin_fw, used to embed into the Linux kernel firmware files that device drivers need to request using the request_firmware() API. This is an optional feature of the Linux kernel for device drivers that for whatever reason have determined reading a firmware file from the filesystem is not as efficient as loading the firmware directly from the built-in kernel. Over the years Linux has went on to extend and define more Linux program specific sections. These Linux program specific sections share generic traits. A new Linux API is being introduced which generalizes the way developers add and use Linux program specific sections. This new API reduces the amount of work required to add new program specific sections, and enables new features which can be exploited for new developments and technologies. The new APIs are being introduced as Linux section ranges and Linux linker tables. This documents these advancements, and also provide a short glimpse into the history of the ELF standard and what we can expect for the future. A. ELF and the System V ABI The history of the ELF specification is scattered throughout the internet, however there is nothing really thorough and concise. This section stiches together some of the loose information available regarding the standardization of the ELF specification. Understanding this history and how the ELF specification evolves will be important for evaluating current limitations and possibly extending it for future needs. ELF was originally developed by UNIX System Laboratories (USL), the first publication documenting ELF was USL s System V Release 4 Application Binary Interface (SRV4 ABI) specification 1. System V is one of the first commercial Unix operating systems, originally developed by AT&T, released in SVR4 was released in 1998, in its announcement 2 SRV4 was described as a two year effort to unite the major variants of the UNIX System the XENIX System, Berkeley 4.2 and UNIX System V into a single standard. The SRV4 ABI is a collection of of specifications which provide details for calling conventions (interface for calling code: order in which scalar parameters are allocated, how parameter are pushed in the stack, placed in registers, which registers must be preserved for the caller, stack preparation and restoration of the stack for a function call) 3, object file formats, executable file formats, document semantics for dynamic linking, and additionally a set of specifications for systems that complies with the X/Open Common Application Environment Specification and the System V Interface Definition. The SRV4 ABI was embraced by most Unix like operating systems as calling conventions

2 part of their own operating system ABI. ELF then was just part of the SRV4 ABI. USL was eventually acquired by Novell in June, In the same year the Tool Interface Standards committee (TIS) selected the ELF standard as a portable object file format for 32-bit Intel architecture for different Operating Systems. TIS was a committee comprised of companies working in the microcomputer industry at that time, namely Intel, IBM, Microsoft, The Santa Cruz Operation, Borland International (now Micro Focus), Lotus, MetaWare, and WATCOM International. PharLap Software and Symantec had also participated in the original specification definition efforts, they however referred to the specification put out as the TIS Portable Formats Specification, Version 1.1. They selected ELF given that they wanted to adopt, and when necessary extend, existing standards rather than invent new ones. The TIS Portable Formats Specification embraced ELF for a linking and loadable format, DWARF (Debug With Arbitrary Record Format) for a debug aid, and OMF (Relocatable Object Module Format) as an alternative loadable object format to ELF. The OMF format is the most important file format used in MS-DOS, 16-bit Windows and 32-bit OS/2. OMF was was designed to require minimal memory when linking. TIS Portable Formats Specification, version 1.2 was published in 1995, this split out specifications for the x86 Processor Suppliment abi (psabi), and the Operating System Specific Specification for SVR4 into its own book, the TIS Portable Formats Specification version 1.2 was specifically dedicated to the ELF Specification. Following these, there are also a select set of processor specific ELF documents, which can be found referenced on the Linux Foundation referenced specifications page 4. A good example of extensions to ELF is the changes needed to support x86-64 support, this was done by publishing a System V ABI, AMD64 Architecture Processor Supplement 5 (three of its four principal authors are still current SUSE employees). Although System V may not be as relevant as it was in 1998 when SVR4 was released, it is much easier to extend an existing ABI instead of creating a new generic ABI for different Unices. Despite this the AMD64 supplement did sport a new Appendix dedicated towards Linux Conventions. It is important to note that although the AMD64 supplement extended the ELF specification in a few areas to support x86-64 its work to support x86-64 on ELF was not complete. For instance new ELF header, and section header data structures are only clarified in the latest published System V Application Binary Interface - DRAFT - 24 April available online. The revision history has its own dedicated section 7 worth revising for updates as technology evolves. There is a public discussion group which is used for extending the x86-64 psabi 8. Should changes be needed for abi-0.98.pdf to extend ELF for new functionality, this would be a good starting point. B. ELF Views and Linux There are two views which can be used for inspecting data in an ELF file, a Linking view, and an Execution view. A Section Header Table enables one to describe an object using the Linking view while a Program Header Table enables one to describe an object using the Execution view. The views are not mutually exclusive. For intance, vmlinux can be viewed under both views, readelf -S vmlinux for the Linking view, and readelf -l vmlinux for the Execution view. In Linux only the vmlinux file will have an Execution view, even modules lack an Execution view given that vmlinux is the only file that describes how the the kernel runs from the start. All other Linux kernel object files have an available Linking view. Under the Linking view, the Section Header Table describes all available sections. The Section Header Table is an array of ELF section header data structures. If on a 32-bit system this is struct elf32_shd, if on a 64-bit this is struct elf64_shdr. Sections are only visible on object files that have a Linking view, since all Linux kernel files have Linking view, all kernel objects have ELF sections. 1 typedef struct elf32_shdr { 2 Elf32_Word sh_name; 3 Elf32_Word sh_type; 4 Elf32_Word sh_flags; 5 Elf32_Addr sh_addr; 6 Elf32_Off sh_offset; 7 Elf32_Word sh_size; 8 Elf32_Word sh_link; 9 Elf32_Word sh_info; 10 Elf32_Word sh_addralign; 11 Elf32_Word sh_entsize; 12 } Elf32_Shdr; 1 typedef struct elf64_shdr { 2 Elf64_Word sh_name; 3 Elf64_Word sh_type; 4 Elf64_Xword sh_flags; 5 Elf64_Addr sh_addr; 6 Elf64_Off sh_offset; 7 Elf64_Xword sh_size; 8 Elf64_Word sh_link; 9 Elf64_Word sh_info; 10 Elf64_Xword sh_addralign; 11 Elf64_Xword sh_entsize; 12 } Elf64_Shdr; Fig. 1: 32-bit section header entry Fig. 2: 64-bit section header entry It is worth reviewing what some of the data structure elements of the section header data structure means. It gives us an idea what limitations we have, if any, and what to expect when manually inspection sections on kernel object files. When necessary, the descriptions below are more verbose than the descriptions offered by the latest ELF specification to help with clarity. 2

3 sh_name: the name of the section. Its value is an index into the section header string table section, this gives the location of a null-terminated string. Strings have no limitation, as such this value can be of arbitrary size, only really limited by the file object size. sh_type: the section type. To enable programs to customize sections for their own use, they must use the value of 1 here, which associates the type to SHT_PROGBITS. In asm this is on most architectures, on ARM this is %progbits. sh_flags: section flags. These are flags which can be set via the binutils assembly section statement, for details refer to the binutils as documentation 9. The flags consist of: SHF_WRITE: The section contains data that should be writable during process execution. This corresponds to the binutils section flag w. SHF_ALLOC: The section occupies memory during process execution. Some control sections do not reside in the memory image of an object file; this attribute is off for those sections. This corresponds to the binutils section flag a. SHF_EXECINSTR: The section contains executable machine instructions. This corresponds to the binutils section flag x. SHF_MASKPROC: All bits included in this mask are reserved for processor-specific semantics 0xf sh_addr: if the section appears in the memory of a process this member gives the address at which the section s first byte should reside. Otherwise this contains 0. sh_offset: byte offset from beginning of file to the first byte in the section. sh_size: the section size sh_link: holds a section header table index link. Its interpretation depends on the section type. sh_info: holds extra information, whose interpretation depends on the section type. sh_addralign: if alignment is required, a power of 2 value representing required alignment. sh_entsize: size of fixed size table entries, if it uses a table. 1 typedef struct elf32_hdr{ 2 unsigned char e_ident[ei_nident]; 3 Elf32_Half e_type; 4 Elf32_Half e_machine; 5 Elf32_Word e_version; 6 Elf32_Addr e_entry; /* Entry point */ 7 Elf32_Off e_phoff; 8 Elf32_Off e_shoff; 9 Elf32_Word e_flags; 10 Elf32_Half e_ehsize; 11 Elf32_Half e_phentsize; 12 Elf32_Half e_phnum; 13 Elf32_Half e_shentsize; 14 Elf32_Half e_shnum; 15 Elf32_Half e_shstrndx; 16 } Elf32_Ehdr; Fig. 4: 32-bit ELF header 1 typedef struct elf64_hdr { 2 unsigned char e_ident[ei_nident]; 3 Elf64_Half e_type; 4 Elf64_Half e_machine; 5 Elf64_Word e_version; 6 Elf64_Addr e_entry; 7 Elf64_Off e_phoff; 8 Elf64_Off e_shoff; 9 Elf64_Word e_flags; 10 Elf64_Half e_ehsize; 11 Elf64_Half e_phentsize; 12 Elf64_Half e_phnum; 13 Elf64_Half e_shentsize; 14 Elf64_Half e_shnum; 15 Elf64_Half e_shstrndx; 16 } Elf64_Ehdr; Fig. 5: 32-bit ELF header For purposes of evaluating section limitations we must also inspect two values from the ELF header. The ELF header is described in the struct elf32_hdr on 32-bit systems and the struct elf64_hdr on 64-bit systems. e_shentsize: This member holds a section headers size in bytes. A section header is one entry in the section header table; all entries are the same size. The size will be either: sizeof(struct elf64_shdr) == 40 sizeof(struct elf64_shdr) == 64 e_shnum: This member holds the number of entries in the section header table. Thus the product of e shentsize and e shnum gives the section header tables size in bytes. If a file has no section header table, e shnum holds the value zero. 1 typedef u16 Elf32_Half; typedef u32 Elf32_Word; typedef u16 Elf64_Half; typedef u64 Elf64_Xword; Fig. 3: Data types for size 9 C. Limits on ELF sections Now that we have documented what ELF allows for regarding sections we can consider ELF section limitations. Naturally, the size of an ELF section will be limitted by the data type used to describe its size inside the section header structure, so the sh_size on either struct elf32_shdr or struct elf64_shdr. On 32-bit systems this is Elf32_Word ( u32), on 64-bit systems this is Elf64_Xword ( u64), which corresponds to 4 GiB for 32-bit, and TiB for 64-bit. 3

4 The System V ABI, AMD64 Architecture Processor Supplement 10 extended support for increasing the section size beyond 2 GiB but in order to allow for this the specification also requires a processor-specific section attribute flag for sh flag to be used, SHF_X86_64_LARGE (0x ). The e_shnum member of the ELF header tells us the number sections in a given object file. Naturally, the data type for e_shnum tells us the maximum number of sections in an ELF object file. On 32-bit systems this is Elf32_Half ( u16), on 64-bit systems this is Elf64_Half (also u16)! It may be surprising that both Elf32_Half and Elf64_Half are both 2 bytes in size, or 16 bits, this would imply though that by default both 32-bit and 64-bit systems have an uppler limit of sections per object file. The latest System V Application Binary Interface indicates however that if the number of sections is greater than or equal to SHN_LORESERVE (0xff00 or 65280), e_shnum has the value SHN UNDEF (0) and the actual number of section header table entries is contained in the sh_size field of the section header at the specially reserved index 0. If e_shnum is not set to SHN_UNDEF the specially reserved index 0 section always has the sh_size set to 0. The sh_size is either Elf64_Xword ( u64) or Elf32_Word ( u32). This should in theory increase the number of supported sections in an ELF object file up to for 32-bit and for 64-bit. We still need a way to associate sections and section indexes. The tenth draft of the System V Application Binary Interface published on June 22, 2000 has a revision note indicating that in order to support more than sections the new section type SHT_SYMTAB_SHNDX was added 11. The latest online System V Application Binary Interface - DRAFT - 24 April describes that a section with type SHT_SYMTAB_SHNDX indicates that there is an association between this section and another another section of type SHT_SYMTAB. The section type SHT SYMTAB is used to hold a symbol table. The section with type SHT_SYMTAB_SHNDX consists of an array of Elf32_Word values, each value representing a value in a symbol table entry. The order of entries in the SHT_SYMTAB_SHNDX section correspond to the same order as the entries for the symbol table section of type SHT_SYMTAB. Furthermore the specification refers to.symtab_shndx as the special section of type SHT_SYMTAB_SHNDX which can be used to hold the special symbol table section index array. If using really large kernels or objects with large amounts of sections one would still need to be sure that ELF loader in charge of loading the Linux kernel is properly updated to handle coping with the latest ELF extensions. For userspace application the ELF loader would typically be /lib/ld-linux.so.2, for the Linux kernel this would be up to the boot loader. II. HOW CUSTOM ELF SECTIONS ARE ADDED TODAY Today Linux program specific sections are added by modifying the generic Linux kernel linker script, include/asm-generic/vmlinux.lds.h. If the feature is not architecture specific or does not require architecture tweaks adding it to the generic linker script suffices. If architecture specific tweaks are required you d want to enable earch architecture to optionally include the program specific section you are introducing, this is done by letting each architecture add the section into their own architecture linker script, arch/$(arch)/kernel/vmlinux.lds.s. A. Adding.text section customizations 1 #define KPROBES_TEXT \ 2 ALIGN_FUNCTION(); \ 3 VMLINUX_SYMBOL( kprobes_text_start) =.; \ 4 *(.kprobes.text) \ 5 VMLINUX_SYMBOL( kprobes_text_end) =.; Fig. 6: kprobers text For instance, kprobe support defines a generic KPROBES_TEXT macro defined in include/asm-generic/vmlinux.lds.h. If your architecture supports kprobes then you would add a KPROBES_TEXT line in your architecture linker script. For instance the s390 architecture defines its.text section as follows: SECTIONS 3 { 4. = 0x ; 5.text : { 6 _text =.; /* Text and read-only data */ 7 HEAD_TEXT 8 TEXT_TEXT 9 SCHED_TEXT 10 LOCK_TEXT 11 KPROBES_TEXT 12 IRQENTRY_TEXT 13 SOFTIRQENTRY_TEXT 14 *(.fixup) 15 *(.gnu.warning) 16 } :text = 0x _etext =.; /* End of text section */ Fig. 7: S390 custom linker script C code however still needs access to the beginning and end of this section, delineated by kprobes_text_start and kprobes_text_end in the linker script. This is accomplished by declaring it without defining it using the C keyword extern. In Linux this is accomplished by delcaring it in the include/asm-generic/sections.h file abi-0.98.pdf extern char kprobes_text_start[], kprobes_text_end[]; Fig. 8: kprobe asm-generic sections.h extern entry 4

5 Typically you would access the beginning and end of a section so you can determine if a piece of code is part of that section or get the section s size. In this case a series of pointers of function. To make the kprobes section useful developers will want to associate a C function into the kprobes section. This is accomplished in C code using the attribute (( section (name_of_section))) helper. For instance, kprobes is defined as follows: 1 #define kprobes \ 2 attribute (( section (".kprobes.text"))) Fig. 9: kprobes definition For example the tile architecture uses kprobes to associate the function arch_arm_kprobe() into the kprobes section as follows: 1 quiet_cmd_fwbin = MK_FW $@ 2 cmd_fwbin = FWNAME="$(patsubst firmware/%.gen.s,%,$@)"; \ 3 FWSTR="$(subst /,_,$(subst.,_,$(subst -,_,$(patsubst \ 4 firmware/%.gen.s,%,$@))))"; \ 5 ASM_WORD=$(if $(CONFIG_64BIT),.quad,.long); \ 6 ASM_ALIGN=$(if $(CONFIG_64BIT),3,2); \ 7 PROGBITS=$(if $(CONFIG_ARM),%,@)progbits; \ 8 echo "/* Generated by firmware/makefile */" > $@;\ 9 echo "\#include <asm/tables.h>" >>$@;\ 10 echo ".section.rodata" >>$@;\ 11 echo ".p2align $${ASM_ALIGN}" >>$@;\ 12 echo "_fw_$${fwstr}_bin:" >>$@;\ 13 echo ".incbin \"$(2)\"" >>$@;\ 14 echo "_fw_end:" >>$@;\ 15 echo ".section.rodata.str,\"ams\",$${progbits},1" >>$@;\ 16 echo ".p2align $${ASM_ALIGN}" >>$@;\ 17 echo "_fw_$${fwstr}_name:" >>$@;\ 18 echo ".string \"$$FWNAME\"" >>$@;\ 19 echo " section.builtin_fw,\"a\",$${progbits}" >>$@;\ 20 echo ".p2align $${ASM_ALIGN}" >>$@;\ 21 echo " $${ASM_WORD} _fw_$${fwstr}_name" >>$@;\ 22 echo " $${ASM_WORD} _fw_$${fwstr}_bin" >>$@;\ 23 echo " $${ASM_WORD} _fw_end - _fw_$${fwstr}_bin" >>$@; Fig. 11: firmware/makefile cmd fwbin 1 void kprobes arch_arm_kprobe(struct kprobe *p) 2 { } Fig. 10: tile arch arm kprobe() association to kprobes This paper will purposely not document how kprobes works, for details refer to the Linux kernel Documentation/kprobes.txt documentation. It turns out this form of use of sections is very common in the Linux kernel, code is associated to the.text section, and a define is used to help developers associate routines to a section. The Linux Linux section ranges API is being introduced to make this easier. This will be documented in the next section, but before moving on to this lets consider further custom uses Linux has of sections. B. Adding.rodata section customizations In Linux often features need to also add data, and this data does not need to be executable code. You might also want to restrict such data without modificaitons, so you d want to mark it as read-only. An example of this is firmware. When device drivers need firmware to upload into a microprocessor it needs only data access to the firmware file. The Linux firmware optionally supports stuffing firmware into the kernel image in case your device driver might need access to the firmware early and stuffing it into the initramfs is not sufficient for your needs. A special section exists for this named.builtin_fw. Since the input in this case are not C functions implemented by developers but rather data the process for associating a file into a section is a bit more complex. The details of all the magic are in the firmware/makefile. Of interest to us is the Makefile command used to generate the assembly file for each firmware, cmd_fwbin. This evil monstrosity generates a firmware/iwlwifi ucode.gen.s if your firmware filename was iwlwifi ucode. The asm.incbin directive includes the file specified verbatim at the current location. Of interest to us is line 19. The $PROGBITS is a Makefile variable that ends up transforming into the respective architecture equivalent to indicates this contains data or is a program specific for most architectures and %progbits for ARM, which we ve documented earlier. The a correspond to the ELF section flag SHF_ALLOC which we ve documented as noting this section is allocatable. This generates this line in the file firmware/iwlwifi ucode.gen.s on x86-64: 1 %.section.builtin_fw,a,@progbits Fig. 12: iwlwifi ucode.gen.s The association of the.builtin_fw with.rodata is done in similar way as with kprobes, by modifying the linker script. In this case it suffices to just add the section directly into the generic custom linker script helper as all architectures are supported. In include/asm-generic/vmlinux.lds.h we have: 5

6 1 #define RO_DATA_SECTION(align) \ 2. = ALIGN((align)); \ 3.rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \ 4 VMLINUX_SYMBOL( start_rodata) =.; \ 5 *(.rodata) *(.rodata.*) \ 6 RO_AFTER_INIT_DATA /* Read only after init */ \ 7 *( vermagic) /* Kernel version magic */ \ 8. = ALIGN(8); \ 9 VMLINUX_SYMBOL( start tracepoints_ptrs) =.; \ 10 *( tracepoints_ptrs) /* Tracepoints: pointer array */ \ 11 VMLINUX_SYMBOL( stop tracepoints_ptrs) =.; \ 12 *( tracepoints_strings)/* Tracepoints: strings */ \ 13 } \ /* Built-in firmware blobs */ \ 16.builtin_fw : AT(ADDR(.builtin_fw) - LOAD_OFFSET) { \ 17 VMLINUX_SYMBOL( start_builtin_fw) =.; \ 18 *(.builtin_fw) \ 19 VMLINUX_SYMBOL( end_builtin_fw) =.; \ 20 } = ALIGN((align)); \ 23 VMLINUX_SYMBOL( end_rodata) =.; \ 24 } \ 25. = ALIGN((align)); Fig. 13: Generic RODATA Then finally the only code that should in theory have access to iterate over the firmware is the code handlng the firmware requests, drivers/base/firmware_class.c. It uses extern to also be able to access the start and end parts of the.builtin_fw firmware section, because of this the following declaration is in drivers/base/firmware_class.c and not in include/linux/firmware.h: 1 extern struct builtin_fw start_builtin_fw[]; 2 extern struct builtin_fw end_builtin_fw[]; Fig. 14: Firmware declaration The other piece of kernel code that also declares and uses the start_builtin_fw and end_builtin_fw is the code in arch/x86/kernel/cpu/microcode/core.c for the kernel x86 microcode loader. No other kernel code accesses these variables directly, as such the declaration is not made in any header file. C. Common traits Both examples we ve reviewed so far, kprobes using the.text and firmware using.rodata have a common set traits though, below we list these. If a generic API is going to make it easier to declare and define Linux program specific sections it must at least satisfy these requirements. Ability to associate a section to a specific section in the linker script. Ability to implement helper code in C or assembly which associates code (functions), or data (data structures) with a specific section. Ability to declare the beginning and ending addresses of a section All C code, and assembly code, and linker script helpers provided must work across all architectures. III. MAKING ADDING NEW SECTIONS EASIER Before intorducing the new APIs let us conisder the challenges we face today. Each time a developer adds a new Linux program specific section they have to modify the generic linker script helper and/or modify each architecture s linker script. Instead of requiring each developer adding a new feature to modify the linker script a new API should strive to enable an entry should only be added once into the linker script for major Linux section. Then, once in place developers can associate new program specific sections to the these main sections by only using C code, or optionally assembly code. Historically program specific sections for which there is concern of conflict with compiler generated sections two dots are used to prexit them (..). We will use this to avoid conflicts with the special constructs we will be adding to make adding new sections with C code easier. The generic custom linker script helper include/asm-generic/vmlinux.lds.h has series of macros used by architecture linker scripts. For.text that is TEXT_TEXT. If you want to ensure most architectures get a new section added to.text you d modify the TEXT_TEXT and embed your program specific sectin section into it. The APIs we are adding enable this flexibility. Lets review the challenges with this and the solutions which were implemented. With Linux section ranges, we d be able to enable developers to extend TEXT_TEXT by modifying its definition only once. For example, we will use the section name.text..rng for section ranges, to add support for section ranges onto the.text section we d first start with this: a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h -433,7 4 * during second ld run in second ld pass when generating System.map */ 5 #define TEXT_TEXT \ 6 ALIGN_FUNCTION(); \ 7 - *(.text.hot.text.text.fixup.text.unlikely)\ 8 + *(.text.hot.text) \ 9 + *(SORT(.text..rng.*)) \ 10 + *(.text.fixup.text.unlikely) \ 11 *(.ref.text) \ 12 MEM_KEEP(init.text) \ 13 MEM_KEEP(exit.text) Fig. 15: TEXT TEXT This is a simple change, however combining this with a few other tricks will make this much more powerful and useful. By itself the above change of using an asterisk on a new section we are able to fold any C or asm directives declaring some code structure as part of any.text.rng.* section directly into.text. So for instance, say I wanted to add a custom foo section and have it fold under.text I could create a 6

7 foo definition for C using the section attribute helper to associate it into a.text..rng.foo section. 1 #define foo \ 2 attribute (( section (".text..rng.foo"))) Fig. 16: Demo foo section range Prefixing foo on a routine would ensure one folds the routine into the.text..rng.foo section, and in turn this is part of the overall larger.text section. C code and asm code can now create new program specific sections as part of the.text without modifying the linker script, however these new program specific sections aren t yet that useful. As we determined in the previous section we want to be able to get the starting and ending address of the new program specific section. How do we accomplish this without modifying the linker script? The answer is that code that defines the program specific sections, that is code which is in charge of this new program specific section, can add 2 new specially crafted sections, based on foo, which can be used as delimiters for sections in between. The binutils linker script SORT directive sorts all sections under text..rng.*. The binutils SORT actually is an alias for SORT_BY_NAME, which instructs linker to sort the sections into ascending order by name before placing them in the output file. Linux has long been using binutlis SORT() on the linker script, as such it is not new and would not require any binutils upgrade at build time. The two specially crafted section names to delimit a program specific section are (the empty string) to annotate the beginning of a program specific section, and to annotate the end of a custom section. We are still not done. We still need one more special postfix which can be used for elements in between. If order is of interest to use we can use digits to create order as we add entries. For instance 001, up to 999. Since sections are strings there is no limitation to the length of the digits used other than the abiding by the file size limit. If order is not of interest to us we can use an arbitrary order annotation. To make it clear order is not needed we can use any. Let us consider what the order of the sections would be like if we declared a program specific section.text..rng.foo and added just one function, let s say bar() with an order of any. We d have:.text..rng.foo. - the first section.text..rng.foo.any - bar() is stuffed here.text..rng.foo. - the last section Without SORT() the first and last section would not be ordered properly, even if we did not need any order for the functions we are adding. Now, typically empty sections get discarded by default at link time, to preserve them we must use the used gcc attribute: attribute ((used)). We use this for both the first section with the (empty string) order specifier or order level and the last section with order specifier. The last issue to resolve is how to make the computation of the size of the program specific section 0 when no elements have been added in between, but still enable the first entry to have the same address as the the first section,.text..rng.foo.. We do this by using the weak gcc attribute: attribute ((weak)) but only for the first section with the (empty string) order level. With all this in place now we just need C code and asm code which can help us declare all this across all architectures. IV. GAINS OF A FORMAL LINUX SECTION API The last section described how we could take advantage of the Linux s linker script, use SORT() and add two delimiters to make it easier to deal with program specific Linux sections. The next two sections will introduce two new APIs being proposed which will take advantage of this to help make it easier to add and manage Linux program specific sections. Its first worth to enumerate the advantages that such a scheme can have on Linux. The immediate observed value of adding a new API will be that of the obvious features provided by such an API. There are additional features, some not so obvious, and some more for consideration for the future that adding these APIs can have on Linux. We ll enumerate them here and elaborate on them later after the APIs are introduced. When reviewing these newly proposed APIs what should be considered is not just the short term immediate obvious gains then, but also what the future holds with them. A. The obvious gains - using only C Provided you can write an API to use the proposed strategy described in the last section, the immediate obvious gain is that you can declare, define, and access the arrays using only the standard C array syntax. They behave just like a normal C array. This provides two immediate benefits: Allows us to just use plain C code to add new Linux program specific ELF sections Makes it less error prone to add new sections B. Short term non-obvious gains A list of short term not so obvious gains are: Helps simplify initialization code Helps optionally avoid code bit-rot (see commit kbuild: enable option to force compile force-obj-y and force-liby) Enables link time ordering which can help make an extremely lightweight dependency annotations explicit (for this refer to the tools/linker-tables/ demo for simplfying of the Xen PV initialization code. C. Long term non-obvious gains The list of known long term non-obvious possible gains are: Run time ordering customization are still possible. We already have one precedents in the kernel to do this, one uses memmove() on entries on a section per some dependency heuristic. Reducing code attack surfice: may help prevent use of dead code by either free ing / nop ing, marking code as no-exec on sections which we know should definitely not run. 7

8 Can easily increase the levels of initialization in the kernel without significant changes (refer to tools/linkertables/ for an example init with linker tables). Some subsystems have already run out of space to get init right. Subsystems could also easily implement their own custom initialization run levels. Synthetic functions: enables custom C / asm functions which could help add new functionality (see synth init or() on tools/linkertables/drivers/synth/main.c). One future prospect is RADI6 support. Self modifying consts (see ps shr() on tools/linkertables/drivers/synth/main.c) V. LINUX SECTION RANGE API The Linux section range API is being introduced to exclusively help with custom Linux sections which are used to stitch together a series of executable code under arbitrary sections. Helpers are provided for both C code and assembly. A. Linux Section range API - C code This documents the sectoin range API, as used with C code. DECLARE SECTION RANGE RO(): used to declare a section range to help code access the section range. Typically if a subsystems needs code to have direct access to the section range the subsystem s header file would declare the section range. Care should be taken to only declare the section range in a header file if access to it is truly needed outside of the code defining it. Since section ranges are executable code it is read-only. DEFINE SECTION RANGE(): Defines a section range, used for executable code. Section ranges are defined in the code that takes ownership and makes use of the section range. SECTION RANGE ADDR WITHIN(): returns true if address provided is in the section range. B. Linux Section range API - assembly It turns out Linux has no generic assembly helpers for all architectures. The Linux range API helps start giving this some shape, it starts by providing helpers for associating code to a specific section. Assembly code can be written in dedicated assembly files or embedded into C code when using extended Asm, using the asm() directive. The major difference between both is the extended Asm is always quoted. Since the code is the same though we provide a raw form, use for code in ASSEMBLER (used by gcc when in an assembly file) or ASSEMBLY (used by the kernel when linking, ld, or building.s output files from.s input files). When not in assembly we can provide similarly named macros but stringify() them, which adds quotes for us. The set of asm helpers for section ranges then are: set section rng(): associates a piece of code to a section, using the any order level. set section rng level() similar to set section rng() but enables a specific order level to be specified. set section rng type(): similar to set section rng() but allows the section type to be explicitly specified by the code. LINUX RANGE: although this is a C helper we define this in asm header files to enable architecture code to make use of it as well. Assembly header files typically have less requirements, making it easiert to avoid build issues accross architectures. This is a short hand helper which provides association of a piece of code into a section range using gcc attributes, so attribute (( section (SECTION RNG(section, name)))) LINUX RANGE ORDER: similar to LINUX RANGE but allows for an order level to be specified. VI. LINUX LINKER TABLES A linker table is a data structure that is stitched together from items in multiple object files for the purpose of selective placement into standard or architecture specific ELF sections. What section is used is utility specific. Linker tables are the API provided to enable association of data structures stitched together into a program specific section. It is very similar to section ranges, however the section range API is purposely left to be lightweight, and specifically for stitched executable code. There are things you simply would not do with section ranges which you do want to enable for data structures. For example, you will often iterate over a data structure, you will not iterate over a set of bundled code. The exact same practice for only modifying the generic linker script helper once for each main section is used to add support for linker tables onto a section. To add linker table support onto the generic DATA_DATA definition, after we added section range support, we extend its definition with: a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h -202,6 4 #define DATA_DATA \ 5 *(.data) \ 6 *(SORT(.data..rng.*)) \ 7 + *(SORT(.data..tbl.*)) \ 8 *(SECTION_REF_DATA) \ 9 *(.data..shared_aligned) /* percpu related */ \ 10 MEM_KEEP(init.data) \ Fig. 17: DATA DATA With linker tables we end up with two declarer macros, one for read-only data, and another for regular data, which allows for data modifications. DECLARE_LINKTABLE - Declares a data linker table entry DECLARE_LINKTABLE_RO - Declares a read-only linker table entry Macros used to define linker tables are associated with each supported section. For instance we have DEFINE_LINKTABLE_TEXT() which declares 8

9 a linker table for execution. Likewise we have DEFINE_LINKTABLE_RO() which defines a readonly linker table. The macro without any prefix, DEFINE_LINKTABLE() is for data. The macros are self explanatory: DEFINE_LINKTABLE DEFINE_LINKTABLE_TEXT DEFINE_LINKTABLE_RO DEFINE_LINKTABLE_INIT DEFINE_LINKTABLE_INIT_DATA A. Linker tables iterators To iterate over a data structure in a linker table we provide three helpers: LINKTABLE_FOR_EACH: iterates over each data structure entry LINKTABLE_RUN_ALL: provided a function name is specified, iterate and run through all entries on a linker table and run the specified function. LINKTABLE_RUN_ERR: provided a function name is specified, run each linker table entry funcion and return error if any. B. Linker table module support Modules can use linker tables, however the linker table definition must be built-in to the kernel. That is, the code that implements DEFINE_LINKTABLE*() must be builtin, and modular code cannot add more items in to the table, unless kernel/module.c find_module_sections() and the modules linker script are updated accordingly, a respective module notifier to account for updates would also be needed. This restriction is expected to be enhanced in the future. The sample set of patches for review port a few custom Linux sections to linker tables that are used by modules: dynamic debug and jump labels. The infrastructure to handle program specific sections on the modules however was already present in these modules. A future goal here would be to make it easier so we do not have to extend this work further when modules define or can extend new linker tables. C. How linker tables simplify initialization code Traditionally, we would implement features in C code by calling the feature, say, foo_init() in some C file upon initialization. You d then have a foo.h which would have an #ifndef CONFIG_FOO sequence with an implementation for foo_init() which does nothing. This enables foo_init() to be added to C code unconditionally either when CONFIG_FOO is enabled or not. 1 #ifndef CONFIG_FOO 2 static inline void foo_init(void) { } 3 #endif Fig. 18: CONFIG FOO ifdef madness With linker tables this is no longer necessry as your init routines would be implicit, you d instead just call call_init_fns() in you C code. call_init_fns() would call all functions present in your init table and if and only if foo.o gets linked in, then its initialisation function will be called. As an example, suppose that we want to create a frobnicator feature framework, and allow for several independent modules to provide frobnicating services. Then we would create a frob.h header file containing e.g.: 1 struct frobnicator { 2 const char *name; 3 void (*frob) (void); 4 }; 5 6 DECLARE_LINKTABLE(struct frobnicator, frobnicator_fns); Fig. 19: frobnicator Any module providing frobnicating services would look something like: 1 #include "frob.h" 2 3 static void my_frob(void) { 4... Do my frobnicating 5 } 6 7 LINKTABLE_INIT_DATA(frobnicator_fns, all) my_frobnicator = { 8.name = "my_frob", 9.frob = my_frob, 10 }; Fig. 20: Example frob definition The central frobnicator code, say in frob.c, would use the frobnicating modules as follows: 1 #include "frob.h" 2 3 void frob_all(void) { 4 struct frobnicator *f; 5 6 LINKTABLE_FOR_EACH(f, frobnicator_fns) { 7 pr_info("calling frobnicator %s\n", frob->name); 8 f->frob(); 9 } 10 } Fig. 21: Iterate on frobnicator VII. CODE BIT-ROT Linux provides a rich array of features, enabling each feature however increases the size of the kernel and there are many features which users often want disabled. The traditional solution to this problem is for each feature to have its own Kconfig symbol, followed by a series of #ifdef statements in C code and header files, allowing the feature to be compiled only when desirable. As the variability of Linux increases build tests can and are often done with random kernel configurations, allyesconfig, and allmodconfig to help find code issues. This however doesn t catch all errors and as a consequence code that is typically not enabled often can suffer from bit-rot over time. 9

10 A. The build-all selective-link philosophy A code architecture philosophy to help avoid code bitrot consists of using Kconfig symbols for each subsystem feature, replace all #ifdefs by instead having each feature implemented it its own C file, and force compilation for all features. Only features that are enabled get linked in, the forced compilation therefore has no size impact on the final result of the kernel. The practice of having each feature implemented in its own C file is already prevalent in many subsystems, however #ifdefs are still typically required during feature initialization. For instance in: 1 #ifdef CONFIG_FOO 2 foo_init(); 3 #endif Fig. 22: Wrapped foo init We cannot remove the #ifdef and leave foo_init() as we d either need to always enable the feature or add a respective #ifdef in a foo.h which makes foo_init() do nothing when CONFIG_FOO is disabled. B. Avoiding the code bit-rot problem with linker tables Linker tables can be used to further help avoid the code bit-rot problem when embracing the build-all selective-link philosophy by lifting the requirement to use of #ifdefs during initialization. With linker tables initialization sequences can be aggregated into a custom ELF section at link time, during run time the table can be iterated over and each init sequence enabled can be called. A feature s init routine is only added to a table when its respective Kconfig symbols has been enabled and therefore linked in. Linker tables enable subsystems to completely do away with #ifdefs if one is comfortable in accepting all subsystem s feature s structural size implications. To further help with this, this work is proposing extending the Linux build system with supports for two new special targets, force-obj-y and force-lib-y. A subsystem which wants to follow the build-all selective-link philosophy can use these targets for a feature s kconfig symbol. Using these targets will always require compilation of the kconfig s objects if the kconfig symbol s dependencies are met but only link the objects into the kernel, and therefore enable the feature, if and only if the kconfig symbol has been enabled. Not all users or build systems may want to opt-in to compile all objects following the build-all selectivelink philosophy, as such the targets force-obj-y and force-lib-y only force compilation when the kconfig symbol CONFIG_BUILD_AVOID_BITROT has been enabled. Disabling this feature makes force-obj-y and force-lib-y functionally equivalent to obj-y and lib-y. Example use: 1 force-obj-$(config_feature_foo) += foo.o Fig. 23: force-obj-foo VIII. FUTURE CONSIDERATIONS Section ranges and Linker tables provide link-time sorting functionality. The potential of these features can be easily overlooked. With dependency information properly set, you can use linker tables as an extremely light weight API to perform topological sorting of a Directed Acyclic Graph (DAG), provided the graph has no cycles. With the new ease to wrap code into sections it is possible to be more explicit about code ordering; the APIs provide enough flexibility so that ordering can be handled for you at link time, independent of how you use your code. A topological sort is accomplished by using order-levels suffixes as part of the section names. This strategy can help in certain cases, however it would be pointless to use order-levels to replace order sequence in a long list of calls in a function, where each call represents a feature. For instance, the the x86 arch/x86/kernel/setup.c setup_arch(). In order to take advantage of the linker sort it also means means we must have all dependency relationship variable information available to us at the time we sort, for linker tables this is at build time. This is an important limitation in terms of semantics to keep in mind. Complex subsystems however may alter initialization depending on several run time variables. A good example of a complex initialization sequence is the x86 PCI IOMMU initialization sequence, which actually inspired some of this work, refer to arch/x86/kernel/pci-iommu_table.c. The x86 PCI IOMMU initialization code deals with a topological sort of a DAG, at run time in the kernel. The linker table work is an attempt to generalize the the x86 PCI IOMMU initialization work. It was originally inspired by the ipxe project s 13 respective linker table solution, however its at this point a full rewrite with more features and flexibility. The details of the rewrite are visible in the userspace linker table sandbox 14, the proposal for linker tables however is also suggesting to merge this under the kernels tools/ directory to enable more easy testing of concepts and ideas and to be able to keep code in sync more easily. Despite the new set of rich features offered by the Linux linker table API, the Linux kernel x86 PCI IOMMU initialization code does much more it uses some simple semantics to build relationships between elements in a section, then later after boot during run time it uses some some variables to sort once again some special sections accordingly. The simple semantics enable simple dependency relationships to be expressed. The semantics are however loose and cannot be generalized due to the implications this would have on data structures. Similar run time sort solution approach however however could be devised for different subsystems. The semantics 13 git://git.ipxe.org/ipxe.git

11 for this would be subystem specific. However are there any techniques or sortint tools which can be shared? A proposal will be made as an additional step after linker tables are merged to provide some more concrete semantics to the initialization routines used in the x86 boot path. More importantly, even though one can use these semantics to help with code ordering, the same techniques should help us determine when certain code should not run. This is in turn could help to address dead code in Linux: code we know should never run after a certain run time condition. 15. If at a specific point in time in run time we know certain code can no longer possibly be used what can we and should we do with that code? Can we free it? Should we just disable execution of it. Should we page fault? If we are going to free some dead code, what synchronization mechanisms do we need to ensure nothing breaks? This train of thought should make us think then: what sort of dependency relationships can be expressed solely using code prior to run time? If there is some considerable amount of relationships which could be sorted at build time, can the linker be enhanced to support sorting using more advanced techniques? Is this desirable? Likewise, if more subsystems start sorting code at run time based on dependency relationships, can we generalize a solution to enable to sort dependencies for other types of mechanisms in the kernel? If we needed more advanced logic to express relationships of dependencies for code and features in the kernel what sort of infrastructure or tools could we use? What are other subsystems doing to express run time dependencies, and is a generic solution possible somehow? C. Compiler multiverse Lastly, if all this proves very useful to Linux, are other projects likely to benefit from such type of work? One alternatve being considered to linker tables is the concept of a compiler multiverse 16, whereby gcc, for instance, could be extended to generalize the binary patching technique used in the Linux kernel for use for any application. Compiler multiverse support would provide variable optimized run time multiverse support. That is, instead of sorting code at run time, the compiler would create copies of code for the different branching possible, creating all possible completely separate universes in one binary. At run time, once a run time variable is determined, one would follow the pre-built binary section optimized for that run time variable. Compiler multiverse support would have a penalty on binary size. The size penalty would depend on the data type for each run time variable. Since this can increase the size of a binary exponentially compiler multiverse support is only being considered at this time with boolean run time variables. For more details refer to FATE# Upon initial review though it would seem that the preferred approach for the Linux kernel is using linker tables due to the expected size impact of the final kernel image using the compiler multiverse feature. A. Extending the kernel s initialization semantics Certain subsystems are finding that using module_init() and late_initcall() do not suffice to help provide the necessary order when code is built-in to the kernel. Such a situation is present in the for IOMMU device drivers. There linker order through Makefiles is being used as last-resort measure to ensure proper order. This order however is fragile and implicit. Linker tables enable lifting the 7 fixed order level system of the Linux kernel to an arbitrary size, and futhermore enables subsystems and device drivers to also specifiy their own set of ordering schemes for initialization. An example of how to do this is provided in the tools/ section of the proposed patches. B. Synthetic functions Stitching together code also means the idea of a function can be modified, using assembly one can craft a custom series of execution bits of code and have order specified using the order level provided by the section ranges and linker tables. An example of a synthetic function is provided in the tools/ section of the kernel as example future use case