diff --git a/Makefile b/Makefile index 778e894..4c9ce05 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,7 @@ .PHONY: clean distclean all force_update +.DELETE_ON_ERROR: $(DOC).pdf -XELATEX=xelatex -shell-escape +XELATEX=xelatex -shell-escape -interaction=nonstopmode DOC=hardware_init_review all: $(DOC).pdf @@ -9,7 +10,7 @@ clean: rm -rf *.log *.bak *.out *.xml *.gz *.aux *.bcf *.blg distclean: clean - rm -rf *.bbl *.pdf *.toc $(DOC).bibready + rm -rf *.bbl *.lof *.lol *.pdf *.toc $(DOC).bibready $(DOC).bibready: $(XELATEX) $(DOC).tex @@ -18,7 +19,10 @@ $(DOC).bibready: $(DOC).bbl: $(DOC).bibready bibliographie.bib biber $(DOC) -$(DOC).pdf: $(DOC).bbl $(DOC).tex +$(DOC).aux: + $(XELATEX) $(DOC).tex + +$(DOC).pdf: $(DOC).bbl $(DOC).aux *.tex listings/* $(XELATEX) $(DOC).tex force_update: $(DOC).toc diff --git a/bibliographie.bib b/bibliographie.bib index 248a5fd..3527623 100644 --- a/bibliographie.bib +++ b/bibliographie.bib @@ -966,3 +966,11 @@ note = "[Online; accessed 17-August-2024]" year={2017}, publisher={Open Source Press} } + +@manual{coreboot_mem_management, + title = {Coreboot Memory Management and Payload Allocation}, + author = {{Coreboot Project}}, + year = 2024, + url = {https://doc.coreboot.org/memory-map.html}, + note = {Accessed: 2024-08-17} +} \ No newline at end of file diff --git a/hardware_init_review.bbl b/hardware_init_review.bbl index 6a399f9..5d4b5aa 100644 --- a/hardware_init_review.bbl +++ b/hardware_init_review.bbl @@ -375,7 +375,6 @@ \field{howpublished}{\url{https://www.asus.com/Commercial-Servers-Workstations/KGPE-D16/HelpDesk_Manual/}} \field{note}{Accessed: 2024-07-05} \field{title}{Asus KGPE-D16 Mainboard Documentation and User Manuals} - \true{nocite} \endentry \entry{BashunVladimir2013Tytb}{inproceedings}{} \name{author}{4}{}{% @@ -586,6 +585,33 @@ \range{pages}{13} \keyw{Computer science} \endentry + \entry{coreboot_mem_management}{manual}{} + \name{author}{1}{}{% + {{hash=9d0db915bc81244c5474dc57d9fb132a}{% + family={{Coreboot Project}}, + familyi={C\bibinitperiod}}}% + } + \strng{namehash}{9d0db915bc81244c5474dc57d9fb132a} + \strng{fullhash}{9d0db915bc81244c5474dc57d9fb132a} + \strng{bibnamehash}{9d0db915bc81244c5474dc57d9fb132a} + \strng{authorbibnamehash}{9d0db915bc81244c5474dc57d9fb132a} + \strng{authornamehash}{9d0db915bc81244c5474dc57d9fb132a} + \strng{authorfullhash}{9d0db915bc81244c5474dc57d9fb132a} + \field{sortinit}{C} + \field{sortinithash}{4d103a86280481745c9c897c925753c0} + \field{labelnamesource}{author} + \field{labeltitlesource}{title} + \field{note}{Accessed: 2024-08-17} + \field{title}{Coreboot Memory Management and Payload Allocation} + \field{year}{2024} + \true{nocite} + \verb{urlraw} + \verb https://doc.coreboot.org/memory-map.html + \endverb + \verb{url} + \verb https://doc.coreboot.org/memory-map.html + \endverb + \endentry \entry{intel_acpi_spec}{book}{} \name{author}{1}{}{% {{hash=42af28f239d9ce2a4d0f9a032741150e}{% diff --git a/hardware_init_review.pdf b/hardware_init_review.pdf index 6d881bb..bf08c20 100644 Binary files a/hardware_init_review.pdf and b/hardware_init_review.pdf differ diff --git a/hardware_init_review.tex b/hardware_init_review.tex index 034b91c..cd2eaf5 100644 --- a/hardware_init_review.tex +++ b/hardware_init_review.tex @@ -1,3 +1,13 @@ +% -*- coding: utf-8 -*- +% Copyright (C) 2024 Adrien 'neox' Bourmault +% +% Permission is granted to copy, distribute and/or modify this document +% under the terms of the GNU Free Documentation License, Version 1.3 +% or any later version published by the Free Software Foundation; +% with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. +% A copy of the license is included in the section entitled "GNU +% Free Documentation License". + \input{packages.tex} % setup things @@ -80,8 +90,7 @@ are analyzed to demonstrate the complexity and importance of firmware in achieving optimal system performance. Furthermore, this document explores the relationship between firmware and - hardware virtualization, discussing how modern firmware supports and enhances - virtualized environments. Security considerations and future trends in + hardware virtualization. Security considerations and future trends in firmware development are also addressed, emphasizing the need for continued research and advocacy for free software-compatible hardware. @@ -443,7 +452,7 @@ slot sharing. For storage, the mainboard provides several SATA ports. Networking capabilities are enhanced by integrated dual gigabit Ethernet ports, which provide high-speed connectivity essential for - data-intensive tasks and network communication \cite{ASUS_kgpe_d16_manual}. + data-intensive tasks and network communication \cite{asus_kgpe_d16_manual}. Additionally, the board is equipped with various peripheral interfaces, including USB ports, audio outputs, and other I/O ports, ensuring compatibility with a wide range of external devices. \\ @@ -675,292 +684,351 @@ \section{General structure of coreboot} - The firmware of the ASUS KGPE-D16 is crucial in ensuring the proper functioning - and optimization of the mainboard's hardware components. For this to be done - efficiently, \textit{coreboot} is organized in different stages (fig. - \ref{fig:coreboot_stages}) \cite{coreboot_docs}. + The firmware of the ASUS KGPE-D16 is crucial in ensuring the proper + functioning and optimization of the mainboard's hardware components. + For this to be done efficiently, \textit{coreboot} is organized in + different stages (fig. \ref{fig:coreboot_stages}) \cite{coreboot_docs}. \begin{figure}[H] \centering \includegraphics[width=0.9\textwidth]{ images/fig9_coreboot_stages.png} - \caption{\textit{coreboot}'s stages timeline, by \textit{coreboot} project (CC BY-SA 4.0, 2009)} + \caption{\textit{coreboot}'s stages timeline, by + \textit{coreboot} project (CC BY-SA 4.0, 2009)} \label{fig:coreboot_stages} \end{figure} - - Being a complex project with ambitious goals, \textit{coreboot} decided early on - to establish an file-system-based architecture for its images (also called ROMs). - This special file-system is CBFS (which stands for coreboot file system). - The CBFS architecture consists of a binary image that can be interpreted as a - physical disk, referred to here as ROM. A number of independent components, each - with a header added to the data, are located within the ROM. The components are - nominally arranged sequentially, although they are aligned along a predefined - boundary (fig. \ref{fig:coreboot_diagram}). \\ - - Each stage is compiled as a separate binary and inserted into the CBFS with - custom compression. The bootblock stage is usually not compressed, while the - ramstage and the payload are compressed with LZMA. - Each stage loads the next stage at a given address (possibly decompressing it - in the process). \\ + Being a complex project with ambitious goals, \textit{coreboot} decided + early on to establish an file-system-based architecture for its images + (also called ROMs). This special file-system is CBFS (which stands for + coreboot file system). The CBFS architecture consists of a binary image + that can be interpreted as a physical disk, referred to here as ROM. A + number of independent components, each with a header added to the data, + are located within the ROM. The components are nominally arranged + sequentially, although they are aligned along a predefined boundary + (fig. \ref{fig:coreboot_diagram}). \\ - \begin{figure}[H] - \centering - \includegraphics[width=0.8\textwidth]{ - images/fig8_coreboot_architecture.png} - \caption{\textit{coreboot} ROM architecture (CC BY-SA 4.0, 2024)} - \label{fig:coreboot_diagram} - \end{figure} + Each stage is compiled as a separate binary and inserted into the CBFS + with custom compression. The bootblock stage is usually not compressed, + while the ramstage and the payload are compressed with LZMA. Each stage + loads the next stage at a given address (possibly decompressing it in + the process). \\ + + Some stages are relocatable and can be placed anywhere in the RAM. + These stages are typically cached in the CBMEM for faster loading times + during wake-up. The CBMEM is a specific memory area used by the + \textit{coreboot} firmware to store important data structures and logs + during the boot process. This area is typically allocated in the + system's RAM and is used to store various types of runtime information + that it might need to reference after the initial boot stages. \\ + + In general, \textit{coreboot} manages main memory through a structured + memory map (fig. \ref{tab:memmap}), allocating specific address ranges + for various hardware functions and system operations. The first 640KB + of memory space is typically unused by coreboot due to historical + reasons. Graphics-related operations use the VGA address range + and the text mode address ranges. It also reserves the higher for + operating system use, ensuring that critical system components + like the IOAPIC and TPM registers have dedicated address spaces. + This structured approach helps maintain system stability and + compatibility across different platforms. + Payloads are typically loaded into high memory, above the reserved areas + for hardware components and system resources. The exact memory location + can vary depending on the system's configuration, but generally, + payloads are placed in a region of memory that does not conflict with + the firmware code or the reserved memory map areas, such as the ROM + mapping ranges. This placement ensures that payloads have sufficient + space to execute without interfering with other critical memory regions + allocated \cite{coreboot_mem_management}. + + \begin{table}[ht] + \makebox[\textwidth][c]{% + \begin{tabular}{ + |>{\centering\arraybackslash}p{0.35\textwidth} + |>{\centering\arraybackslash}p{0.5\textwidth}|} + \hline + \texttt{0x00000 - 0x9FFFF} + & Low memory (first 640KB). Never used. \\ + \hline + \texttt{0xA0000 - 0xAFFFF} + & VGA graphics address range. \\ + \hline + \texttt{0xB0000 - 0xB7FFF} + & Monochrome text mode address range. + Few motherboards use + it, but the KGPE-D16 does. \\ + \hline + \texttt{0xB8000 - 0xBFFFF} + & Text mode address range. \\ + \hline + \texttt{0xFEC00000} + & IOAPIC address. \\ + \hline + \texttt{0xFED44000 - 0xFED4FFFF} + & Address range for TPM registers. \\ + \hline + \texttt{0xFF000000 - 0xFFFFFFFF} + & 16 MB ROM mapping address range. \\ + \hline + \texttt{0xFF800000 - 0xFFFFFFFF} + & 8 MB ROM mapping address range. \\ + \hline + \texttt{0xFFC00000 - 0xFFFFFFFF} + & 4 MB ROM mapping address range. \\ + \hline + \texttt{0xFEC00000 - DEVICE MEM HIGH} + & Reserved area for OS use. \\ + \hline + \end{tabular}} + \caption{\textit{coreboot} memory map} + \label{tab:memmap} + \end{table} - Some stages are relocatable and can be placed anywhere in the RAM. These stages - are typically cached in the CBMEM for faster loading times during - wake-up. The CBMEM is a specific memory area used by the - \textit{coreboot} firmware to store important data structures and logs during the - boot process. This area is typically allocated in the system's RAM and is used to - store various types of runtime information that it might need to reference - after the initial boot stages. - \subsection{Bootblock stage} - - The bootblock is the first stage executed after the CPU reset. - The beginning of this stage is written in assembly language, and its main task is - to set everything up for a C environment. The rest, of course, is written in C. - This stage occupies the last 20k (fig. \ref{fig:coreboot_diagram}) of the image - and within it is a main header containing information about the ROM, including - the size, component alignment, and the offset of the start of the first CBFS - component in the ROM. - This block is a mandatory component as it also contains the entry point of the - firmware. \\ - - Upon startup, this stage is responsible for the initial hardware setup, which - involves identifying and configuring the CPU. This process is particularly - significant for AMD Family 10h/15h processors, where the firmware sets up the - Bootstrap Processor (BSP) and executes the necessary initialization routines: - using the BSP, it enables the processor's cache, a small but fast type of memory - that stores frequently accessed data, improving overall system speed by reducing - data access time. However, the cache is there used as memory since DDR DIMMs are - not available yet. This is done by programming the Memory Type Range - Registers (MTRRs), which define how different ranges of system memory are - accessed such as whether they are cacheable or non-cacheable, used to optimize - memory performance on normal operation \cite{BKDG}. - The firmware will then set the stack pointer, allocate memory for the BSS, and - decompress and load the next stage. On x86 platforms, this process also includes - updating the CPU microcode, initializing the timer, and transitioning from 16-bit - real mode to 32-bit protected mode. The bootblock is responsible for - loading the romstage, or the verstage if verified boot is enabled - \cite{coreboot_docs}. - - \subsection{Romstage} - - The purpose of the romstage is the early initialization of peripherals, - particularly system memory. The firmware also configures the Advanced - Programmable Interrupt Controller (APIC), responsible in handling interrupts - correctly across multiple CPUs, particularly in systems that use Symmetric - Multiprocessing (SMP). - In this phase, \textit{coreboot} sets up the APIC to manage interrupt routing, - which includes configuring the Local APIC on each processor and the IOAPIC, part - of the southbridge, for routing interrupts from peripherals to the appropriate - CPUs. - Lastly, it sets up the routing for HyperTransport (HT) - technology, a high-speed communication protocol used for data exchange between - the processor and the northbridge, ensuring that data flows smoothly - between these components. \\ - Memory training and optimization are key functions of the firmware. During this - process, the firmware adjusts memory settings, such as timings, frequencies, and - voltages, to ensure that the installed memory modules operate efficiently and - stably. This step is crucial for achieving optimal performance, especially when - dealing with large amounts of RAM for a large amount of CPU cores, as - supported by the KGPE-D16. We will dive into this topic later on. \\ - + The bootblock is the first stage executed after the CPU reset. The + beginning of this stage is written in assembly language, and its + main task is to set everything up for a C environment. The rest, of + course, is written in C. This stage occupies the last 20k + (fig. \ref{fig:coreboot_diagram}) of the image and within it is a + main header containing information about the ROM, including the + size, component alignment, and the offset of the start of the first + CBFS component. This block is a mandatory component as it also + contains the entry point of the firmware. \\ + + \begin{figure}[H] + \centering + \includegraphics[width=0.8\textwidth]{ + images/fig8_coreboot_architecture.png} + \caption{\textit{coreboot} ROM architecture + (CC BY-SA 4.0, 2024)} + \label{fig:coreboot_diagram} + \end{figure} + + Upon startup, this stage is responsible for the initial hardware + setup, which involves identifying and configuring the CPU. This + process is particularly significant for AMD Family 10h/15h + processors, where the firmware sets up the Bootstrap Processor + (BSP) and executes the necessary initialization routines: using + the BSP, it enables the processor's cache, a small but fast type + of memory that stores frequently accessed data, improving overall + system speed by reducing data access time. However, the cache is + there used as memory since DDR DIMMs are not available yet. This is + done by programming the Memory Type Range Registers (MTRRs), which + define how different ranges of system memory are accessed such as + whether they are cacheable or non-cacheable, used to optimize memory + performance on normal operation \cite{BKDG}. The firmware will then + set the stack pointer, allocate memory for the BSS, and decompress + and load the next stage. On x86 platforms, this process also + includes updating the CPU microcode, initializing the timer, and + transitioning from 16-bit real mode to 32-bit protected mode. The + bootblock is responsible for loading the romstage, or the verstage + if verified boot is enabled \cite{coreboot_docs}. \\ + + \subsection{Romstage} + + The purpose of the romstage is the early initialization of + peripherals, particularly system memory. The firmware also + configures the Advanced Programmable Interrupt Controller (APIC), + responsible in handling interrupts correctly across multiple CPUs, + particularly in systems that use Symmetric Multiprocessing (SMP). + In this phase, \textit{coreboot} sets up the APIC to manage + interrupt routing, which includes configuring the Local APIC on each + processor and the IOAPIC, part of the southbridge, for routing + interrupts from peripherals to the appropriate CPUs. Lastly, it sets + up the routing for HyperTransport (HT) technology, a high-speed + communication protocol used for data exchange between the processor + and the northbridge, ensuring that data flows smoothly between these + components. \\ + + Memory training and optimization are key functions of the firmware. + During this process, the firmware adjusts memory settings, such as + timings, frequencies, and voltages, to ensure that the installed + memory modules operate efficiently and stably. This step is crucial + for achieving optimal performance, especially when dealing with large + amounts of RAM for a large amount of CPU cores, as supported by the + KGPE-D16. We will dive into this topic later on. \\ + \subsection{Ramstage} - The ramstage performs the general initialization of all peripherals, including - the initialization of PCI devices, on-chip devices, the TPM (if not done by - verstage), graphics (optional), and the CPU (setting up the System Management - Mode). After this initialization, tables are written to inform the payload or - operating system about the existence and current state of the hardware. These - tables include ACPI tables (specific to x86), SMBIOS tables (specific to x86), - coreboot tables, and updates to the device tree (specific to ARM). Additionally, - the ramstage locks down the hardware and firmware by applying write protection to - boot media, locking security-related registers, and locking SMM (specific to - x86). \\ - - Effective resource allocation is essential for system stability, particularly in - complex configurations involving multiple CPUs and peripherals. The firmware - manages resource allocation, resolving any conflicts between hardware components - to prevent resource contention and ensure smooth operation. \\ + The ramstage performs the general initialization of all peripherals, + including the initialization of PCI devices, on-chip devices, the TPM + (if not done by verstage), graphics (optional), and the CPU (setting up + the System Management Mode). After this initialization, tables are + written to inform the payload or operating system about the existence + and current state of the hardware. These tables include ACPI tables + (specific to x86), SMBIOS tables (specific to x86), coreboot tables, + and updates to the device tree (specific to ARM). Additionally, the + ramstage locks down the hardware and firmware by applying write + protection to boot media, locking security-related registers, and + locking SMM (specific to x86). + Effective resource allocation is essential for system stability, + particularly in complex configurations involving multiple CPUs and + peripherals. This stage manages initial resource allocation, resolving + any conflicts between hardware components to prevent resource contention + and ensure smooth operation and security, which is a major + concern in modern systems. This includes support for IOMMU, which is + crucial for preventing unauthorized direct memory access (DMA) attacks, + particularly in virtualized environments. - Power management is another critical aspect managed by the firmware. Through the - Advanced Configuration and Power Interface (ACPI), the firmware can adjust the - power states of various components, optimizing energy consumption across the - system. This not only reduces power usage but also minimizes heat generation, - which is vital for maintaining system longevity and efficiency. \\ + \subsubsection{Advanced Configuration and Power Interface} - Security is a major concern in modern systems, and the KGPE-D16’s firmware - includes features designed to protect the system from unauthorized access and - maintain the integrity of its operations. This includes support for IOMMU, which - is crucial for preventing unauthorized direct memory access (DMA) attacks, - particularly in virtualized environments. + The Advanced Configuration and Power Interface (ACPI) is a critical component + of modern computing systems, providing an open standard for device + configuration and power management by the operating system (OS). Developed in + 1996 by Intel, Microsoft, and Toshiba, ACPI replaced the older Advanced Power + Management (APM) standard with more advanced and flexible power management + capabilities\cite{intel_acpi_spec}. + At its core, ACPI is implemented through a series of data structures and + executable code known as ACPI tables, which are provided by the system firmware + and interpreted by the OS. These tables describe various aspects of the system, + including hardware resources, device power states, and thermal zones. The ACPI + Specification outlines these structures and provides the necessary + standardization for interoperability across different platforms and operating + systems\cite{acpi_os_support}. These tables are used by the OS to perform + low-level task, including managing power states of the CPU, controlling the + voltage and frequency scaling (also known as Dynamic Voltage and Frequency + Scaling, or DVFS), and coordinating power delivery to peripherals. \newline + + The ACPI Component Architecture (ACPICA) is the reference implementation of + ACPI, providing a common codebase that can be used by OS developers to + integrate ACPI support. ACPICA includes tools and libraries that allow for the + parsing and execution of ACPI Machine Language (AML) code, which is embedded + within the ACPI tables\cite{acpi_programming}. One of the key tools in ACPICA + is the Intel ACPI Source Language (IASL) compiler, which converts ACPI Source + Language (ASL) code into AML bytecode, allowing firmware developers to write + custom ACPI methods\cite{intel_acpi_spec}. + The triggering of ACPI events is managed through a combination of hardware + signals and software routines. For example, when a user presses the power + button on a system, an ACPI event is generated, which is then handled by the + OS. This event might trigger the system to enter a low-power state, such as + sleep or hibernation, depending on the configuration provided by the ACPI + tables\cite{acpi_os_support}. These power states are defined in the ACPI + specification, with global states (G0 to G3) representing different levels of + system power consumption, and device states (D0 to D3) representing individual + device power levels. \\ + + The ASUS KGPE-D16 mainboard, which is designed + for server and high-performance computing environments, utilizes ACPI for + managing its power distribution across multiple CPUs and attached peripherals. + ACPI is integral in controlling the power states of various components, thereby + optimizing performance and energy use. Additionally, the firmware on the + KGPE-D16 uses ACPI tables to manage system temperature and fan speed, ensuring + reliable operation under heavy workloads\cite{asus_kgpe_d16_manual}. + + \subsubsection{System Management Mode} + + System Management Mode (SMM) is a highly privileged operating mode provided by + x86 processors for handling system-level functions such as power management, + hardware control, and other critical tasks that must be isolated from the OS + and applications. Introduced by Intel, SMM operates in an environment separate + from the main operating system, offering a secure and controlled space for + executing sensitive operations\cite{uefi_smm_security}. \\ + + SMM is triggered by a System Management Interrupt (SMI), which is a + non-maskable interrupt that causes the CPU to save its current state and switch + to executing code stored in a protected area of memory called System Management + RAM (SMRAM). SMRAM is a specialized memory region that is isolated from the + rest of the system, making it inaccessible to the OS and preventing tampering + or interference from other software\cite{heasman2007}. Within SMM, the + firmware can execute various low-level functions that require direct hardware + control or need to be protected from the OS. This includes tasks such as + thermal management, where the system monitors CPU temperature and adjusts + performance or power levels to prevent overheating, as well as power management + routines that enable efficient energy usage by adjusting power states based on + system activity\cite{offsec_bios_smm}. + One of the critical security features of SMM is its role in managing firmware + updates and handling system-level security events. Because SMM operates in a + privileged mode that is isolated from the OS, it can securely apply firmware + updates and respond to security threats without being affected by potentially + compromised system software\cite{domas2015}. However, the high privilege level + and isolation of SMM also present significant security challenges. If an + attacker can compromise SMM, they gain full control over the system, bypassing + all security measures implemented by the OS\cite{cyber_smm_hack}. \\ + + The ASUS KGPE-D16 mainboard utilizes SMM to + perform critical management tasks that need to be isolated from the operating + system. For example, SMM is used to monitor and manage system health by + responding to thermal events and adjusting power levels to maintain system + stability. SMM operates independently of the main operating system, allowing it + to perform sensitive tasks securely. + \textit{coreboot}, an open-source firmware project, supports SMM, but its + implementation + is typically minimal compared to traditional BIOS/UEFI systems. + In \textit{coreboot}, SMM initialization involves setting up the System Management + Interrupt (SMI) handler and configuring System Management RAM (SMRAM), the + memory region where SMM code executes\cite{brown2003linuxbios}. The extent of + SMM support in \textit{coreboot} can vary significantly depending on the hardware + platform and the specific requirements of the system. \textit{coreboot}'s design + philosophy emphasizes a lightweight and fast boot process, delegating more + complex management tasks to payloads or the operating system itself + \cite{reinauer2008coreboot}. + + One of the key challenges with implementing SMM in \textit{coreboot} is ensuring + that + SMI handlers are configured correctly to manage necessary system tasks without + compromising security or performance. \textit{coreboot}'s approach to SMM is + consistent + with its overall goal of providing a streamlined and efficient firmware + solution, leaving more intricate functionalities to be handled by subsequent + software layers\cite{mohr2012comparative}. \subsection{Payload} - TODO + TODO - \begin{listing}[H] - \begin{adjustwidth}{0.5cm}{0.5cm} - \inputminted{c}{listings/test.c} - \end{adjustwidth} - \caption{\textit{Example Python functions}} - \label{lst:python_code} - \end{listing} + \begin{listing}[H] + \begin{adjustwidth}{0.5cm}{0.5cm} + \inputminted{c}{listings/test.c} + \end{adjustwidth} + \caption{\textit{Example C code}} + \label{lst:c_code} + \end{listing} - We saw that in (lst. \ref{lst:python_code}). + We saw that in (lst. \ref{lst:c_code}). - \section{Advanced Configuration and Power Interface} + \section{AMD Platform Security Processor and Intel Management Engine} - The Advanced Configuration and Power Interface (ACPI) is a critical component - of modern computing systems, providing an open standard for device - configuration and power management by the operating system (OS). Developed in - 1996 by Intel, Microsoft, and Toshiba, ACPI replaced the older Advanced Power - Management (APM) standard with more advanced and flexible power management - capabilities\cite{intel_acpi_spec}. - At its core, ACPI is implemented through a series of data structures and - executable code known as ACPI tables, which are provided by the system firmware - and interpreted by the OS. These tables describe various aspects of the system, - including hardware resources, device power states, and thermal zones. The ACPI - Specification outlines these structures and provides the necessary - standardization for interoperability across different platforms and operating - systems\cite{acpi_os_support}. These tables are used by the OS to perform - low-level task, including managing power states of the CPU, controlling the - voltage and frequency scaling (also known as Dynamic Voltage and Frequency - Scaling, or DVFS), and coordinating power delivery to peripherals. \newline + The AMD Platform Security Processor (PSP) and Intel Management Engine (ME) are + embedded subsystems within AMD and Intel processors, respectively, that handle + a range of security-related tasks independent of the main CPU. These + subsystems are fundamental to the security architecture of modern computing + platforms, providing functions such as secure boot, cryptographic key + management, and remote system management\cite{amd_psp_overview}. + The AMD PSP is based on an ARM Cortex-A5 processor and is responsible for + several security functions, including the validation of firmware during boot + (secure boot), management of Trusted Platform Module (TPM) functions, and + handling cryptographic operations such as key generation and storage. The PSP + operates independently of the main x86 cores, which allows it to execute + security functions even when the main system is powered off or compromised by + malware\cite{amd_psp_overview}. The PSP's isolated environment ensures that + sensitive operations are protected from threats that could affect the main OS. - The ACPI Component Architecture (ACPICA) is the reference implementation of - ACPI, providing a common codebase that can be used by OS developers to - integrate ACPI support. ACPICA includes tools and libraries that allow for the - parsing and execution of ACPI Machine Language (AML) code, which is embedded - within the ACPI tables\cite{acpi_programming}. One of the key tools in ACPICA - is the Intel ACPI Source Language (IASL) compiler, which converts ACPI Source - Language (ASL) code into AML bytecode, allowing firmware developers to write - custom ACPI methods\cite{intel_acpi_spec}. - The triggering of ACPI events is managed through a combination of hardware - signals and software routines. For example, when a user presses the power - button on a system, an ACPI event is generated, which is then handled by the - OS. This event might trigger the system to enter a low-power state, such as - sleep or hibernation, depending on the configuration provided by the ACPI - tables\cite{acpi_os_support}. These power states are defined in the ACPI - specification, with global states (G0 to G3) representing different levels of - system power consumption, and device states (D0 to D3) representing individual - device power levels. \newline + Similarly, the Intel Management Engine (ME) is a dedicated microcontroller + embedded within Intel chipsets that operates independently of the main CPU. + The ME is a comprehensive subsystem that provides a variety of functions, + including out-of-band system management, security enforcement, and support for + Digital Rights Management (DRM) \cite{intel_csme}. The ME's firmware runs on an + isolated environment that allows it to perform these tasks securely, even when + the system is powered off. This capability is crucial for enterprise + environments where administrators need to perform remote diagnostics, updates, + and security checks without relying on the main OS. \newline - \textbf{ASUS KGPE-D16 Example}: The ASUS KGPE-D16 mainboard, which is designed - for server and high-performance computing environments, utilizes ACPI for - managing its power distribution across multiple CPUs and attached peripherals. - ACPI is integral in controlling the power states of various components, thereby - optimizing performance and energy use. Additionally, the firmware on the - KGPE-D16 uses ACPI tables to manage system temperature and fan speed, ensuring - reliable operation under heavy workloads\cite{ASUS_kgpe_d16_manual}. + The Intel ME, however, has been a source of controversy due to its deep + integration into the hardware and its potential to be exploited if + vulnerabilities are discovered. Researchers have demonstrated ways to hack into + the ME, potentially gaining control over a system even when it is powered off + \cite{blackhat_me_hack}. These concerns have led to calls for greater + transparency and security measures around the ME and similar subsystems. + When comparing Intel ME and AMD PSP, the primary difference lies in their scope + and functionality. Intel ME offers more extensive remote management + capabilities, making it a more comprehensive tool for enterprise environments, + while AMD PSP focuses more narrowly on core security tasks. Nonetheless, both + play critical roles in ensuring the security and integrity of modern computing + systems. \newline - \section{System Management Mode} - - System Management Mode (SMM) is a highly privileged operating mode provided by - x86 processors for handling system-level functions such as power management, - hardware control, and other critical tasks that must be isolated from the OS - and applications. Introduced by Intel, SMM operates in an environment separate - from the main operating system, offering a secure and controlled space for - executing sensitive operations\cite{uefi_smm_security}. \newline - - SMM is triggered by a System Management Interrupt (SMI), which is a - non-maskable interrupt that causes the CPU to save its current state and switch - to executing code stored in a protected area of memory called System Management - RAM (SMRAM). SMRAM is a specialized memory region that is isolated from the - rest of the system, making it inaccessible to the OS and preventing tampering - or interference from other software\cite{heasman2007}. Within SMM, the - firmware can execute various low-level functions that require direct hardware - control or need to be protected from the OS. This includes tasks such as - thermal management, where the system monitors CPU temperature and adjusts - performance or power levels to prevent overheating, as well as power management - routines that enable efficient energy usage by adjusting power states based on - system activity\cite{offsec_bios_smm}. - One of the critical security features of SMM is its role in managing firmware - updates and handling system-level security events. Because SMM operates in a - privileged mode that is isolated from the OS, it can securely apply firmware - updates and respond to security threats without being affected by potentially - compromised system software\cite{domas2015}. However, the high privilege level - and isolation of SMM also present significant security challenges. If an - attacker can compromise SMM, they gain full control over the system, bypassing - all security measures implemented by the OS\cite{cyber_smm_hack}. \newline - - \textbf{ASUS KGPE-D16 Example}: The ASUS KGPE-D16 mainboard utilizes SMM to - perform critical management tasks that need to be isolated from the operating - system. For example, SMM is used to monitor and manage system health by - responding to thermal events and adjusting power levels to maintain system - stability. SMM operates independently of the main operating system, allowing it - to perform sensitive tasks securely. - \textit{coreboot}, an open-source firmware project, supports SMM, but its - implementation - is typically minimal compared to traditional BIOS/UEFI systems. - In \textit{coreboot}, SMM initialization involves setting up the System Management - Interrupt (SMI) handler and configuring System Management RAM (SMRAM), the - memory region where SMM code executes\cite{brown2003linuxbios}. The extent of - SMM support in \textit{coreboot} can vary significantly depending on the hardware - platform and the specific requirements of the system. \textit{coreboot}'s design - philosophy emphasizes a lightweight and fast boot process, delegating more - complex management tasks to payloads or the operating system itself - \cite{reinauer2008coreboot}. - - One of the key challenges with implementing SMM in \textit{coreboot} is ensuring - that - SMI handlers are configured correctly to manage necessary system tasks without - compromising security or performance. \textit{coreboot}'s approach to SMM is - consistent - with its overall goal of providing a streamlined and efficient firmware - solution, leaving more intricate functionalities to be handled by subsequent - software layers\cite{mohr2012comparative}. - - \section{AMD Platform Security Processor and Intel Management Engine} - - The AMD Platform Security Processor (PSP) and Intel Management Engine (ME) are - embedded subsystems within AMD and Intel processors, respectively, that handle - a range of security-related tasks independent of the main CPU. These - subsystems are fundamental to the security architecture of modern computing - platforms, providing functions such as secure boot, cryptographic key - management, and remote system management\cite{amd_psp_overview}. - The AMD PSP is based on an ARM Cortex-A5 processor and is responsible for - several security functions, including the validation of firmware during boot - (secure boot), management of Trusted Platform Module (TPM) functions, and - handling cryptographic operations such as key generation and storage. The PSP - operates independently of the main x86 cores, which allows it to execute - security functions even when the main system is powered off or compromised by - malware\cite{amd_psp_overview}. The PSP's isolated environment ensures that - sensitive operations are protected from threats that could affect the main OS. - - Similarly, the Intel Management Engine (ME) is a dedicated microcontroller - embedded within Intel chipsets that operates independently of the main CPU. - The ME is a comprehensive subsystem that provides a variety of functions, - including out-of-band system management, security enforcement, and support for - Digital Rights Management (DRM) \cite{intel_csme}. The ME's firmware runs on an - isolated environment that allows it to perform these tasks securely, even when - the system is powered off. This capability is crucial for enterprise - environments where administrators need to perform remote diagnostics, updates, - and security checks without relying on the main OS. \newline - - The Intel ME, however, has been a source of controversy due to its deep - integration into the hardware and its potential to be exploited if - vulnerabilities are discovered. Researchers have demonstrated ways to hack into - the ME, potentially gaining control over a system even when it is powered off - \cite{blackhat_me_hack}. These concerns have led to calls for greater - transparency and security measures around the ME and similar subsystems. - When comparing Intel ME and AMD PSP, the primary difference lies in their scope - and functionality. Intel ME offers more extensive remote management - capabilities, making it a more comprehensive tool for enterprise environments, - while AMD PSP focuses more narrowly on core security tasks. Nonetheless, both - play critical roles in ensuring the security and integrity of modern computing - systems. \newline - - \textbf{ASUS KGPE-D16 Example}: The ASUS KGPE-D16 mainboard does not include - the AMD Platform Security Processor (PSP) or the Intel ME. + The ASUS KGPE-D16 mainboard does not include the AMD Platform Security + Processor (PSP) nor the Intel ME. \chapter{Memory initialization and training algorithms [WIP]} @@ -1080,9 +1148,18 @@ \newpage -\chapter*{\rlap{GNU Free Documentation License}} +% List of figures +\addcontentsline{toc}{chapter}{List of Figures} +\listoffigures +\newpage + +% List of figures +\addcontentsline{toc}{chapter}{List of Listings} +\listoflistings +\newpage + +\chapter*{\center\rlap{GNU Free Documentation License}} \addcontentsline{toc}{chapter}{GNU Free Documentation License} - \begin{center} Version 1.3, 3 November 2008 @@ -1097,12 +1174,12 @@ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. -\end{center} -\begin{center} -{\bf\large Preamble} -\end{center} + + +\bigskip\bigskip{\bf\large Preamble}\bigskip + The purpose of this License is to make a manual, textbook, or other functional and useful document ``free'' in the sense of freedom: to @@ -1126,9 +1203,9 @@ whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. -\begin{center} -{\Large\bf 1. APPLICABILITY AND DEFINITIONS\par} -\end{center} + +\bigskip\bigskip{\Large\bf 1. APPLICABILITY AND DEFINITIONS\par}\bigskip + This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be @@ -1219,9 +1296,9 @@ implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. -\begin{center} -{\Large\bf 2. VERBATIM COPYING\par} -\end{center} + +\bigskip\bigskip{\Large\bf 2. VERBATIM COPYING\par}\bigskip + You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the @@ -1237,9 +1314,9 @@ You may also lend copies, under the same conditions stated above, and you may publicly display copies. -\begin{center} -{\Large\bf 3. COPYING IN QUANTITY\par} -\end{center} + +\bigskip\bigskip{\Large\bf 3. COPYING IN QUANTITY\par}\bigskip + If you publish printed copies (or copies in media that commonly have @@ -1278,9 +1355,9 @@ Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. -\begin{center} -{\Large\bf 4. MODIFICATIONS\par} -\end{center} + +\bigskip\bigskip{\Large\bf 4. MODIFICATIONS\par}\bigskip + You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release @@ -1396,9 +1473,9 @@ give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. -\begin{center} -{\Large\bf 5. COMBINING DOCUMENTS\par} -\end{center} + +\bigskip\bigskip{\Large\bf 5. COMBINING DOCUMENTS\par}\bigskip + You may combine the Document with other documents released under this @@ -1423,9 +1500,9 @@ in the various original documents, forming one section Entitled and any sections Entitled ``Dedications''. You must delete all sections Entitled ``Endorsements''. -\begin{center} -{\Large\bf 6. COLLECTIONS OF DOCUMENTS\par} -\end{center} + +\bigskip\bigskip{\Large\bf 6. COLLECTIONS OF DOCUMENTS\par}\bigskip + You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this @@ -1439,9 +1516,9 @@ License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. -\begin{center} -{\Large\bf 7. AGGREGATION WITH INDEPENDENT WORKS\par} -\end{center} + +\bigskip\bigskip{\Large\bf 7. AGGREGATION WITH INDEPENDENT WORKS\par}\bigskip + A compilation of the Document or its derivatives with other separate @@ -1462,9 +1539,9 @@ Otherwise they must appear on printed covers that bracket the whole aggregate. -\begin{center} -{\Large\bf 8. TRANSLATION\par} -\end{center} + +\bigskip\bigskip{\Large\bf 8. TRANSLATION\par}\bigskip + Translation is considered a kind of modification, so you may @@ -1486,9 +1563,9 @@ its Title (section~1) will typically require changing the actual title. -\begin{center} -{\Large\bf 9. TERMINATION\par} -\end{center} + +\bigskip\bigskip{\Large\bf 9. TERMINATION\par}\bigskip + You may not copy, modify, sublicense, or distribute the Document @@ -1517,9 +1594,9 @@ reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it. -\begin{center} -{\Large\bf 10. FUTURE REVISIONS OF THIS LICENSE\par} -\end{center} + +\bigskip\bigskip{\Large\bf 10. FUTURE REVISIONS OF THIS LICENSE\par}\bigskip + The Free Software Foundation may publish new, revised versions @@ -1542,9 +1619,9 @@ version permanently authorizes you to choose that version for the Document. -\begin{center} -{\Large\bf 11. RELICENSING\par} -\end{center} + +\bigskip\bigskip{\Large\bf 11. RELICENSING\par}\bigskip + ``Massive Multiauthor Collaboration Site'' (or ``MMC Site'') means any @@ -1575,9 +1652,9 @@ under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing. -\begin{center} -{\Large\bf ADDENDUM: How to use this License for your documents\par} -\end{center} + +\bigskip\bigskip{\Large\bf ADDENDUM: How to use this License for your documents\par}\bigskip + To use this License in a document you have written, include a copy of the License in the document and put the following copyright and @@ -1615,4 +1692,3 @@ free software license, such as the GNU General Public License, to permit their use in free software. \end{document} - diff --git a/hardware_init_review.toc b/hardware_init_review.toc index baf3add..c1b35c7 100644 --- a/hardware_init_review.toc +++ b/hardware_init_review.toc @@ -1,38 +1,40 @@ \babel@toc {english}{}\relax -\contentsline {chapter}{Abstract}{4}{chapter*.1}% -\contentsline {chapter}{\numberline {1}Introduction to firmware and BIOS evolution}{5}{chapter.1}% -\contentsline {section}{\numberline {1.1}Historical context of BIOS}{5}{section.1.1}% -\contentsline {subsection}{\numberline {1.1.1}Definition and origin}{5}{subsection.1.1.1}% -\contentsline {subsection}{\numberline {1.1.2}Functionalities and limitations}{6}{subsection.1.1.2}% -\contentsline {section}{\numberline {1.2}Modern BIOS and UEFI}{7}{section.1.2}% -\contentsline {subsection}{\numberline {1.2.1}Transition from traditional BIOS to UEFI (Unified Extensible Firmware Interface)}{7}{subsection.1.2.1}% -\contentsline {subsection}{\numberline {1.2.2}An other way with \textit {coreboot}}{7}{subsection.1.2.2}% -\contentsline {section}{\numberline {1.3}Shift in firmware responsibilities}{9}{section.1.3}% -\contentsline {chapter}{\numberline {2}Characteristics of ASUS KGPE-D16 mainboard}{10}{chapter.2}% -\contentsline {section}{\numberline {2.1}Overview of ASUS KGPE-D16 hardware}{11}{section.2.1}% -\contentsline {section}{\numberline {2.2}Chipset}{12}{section.2.2}% -\contentsline {section}{\numberline {2.3}Processors}{14}{section.2.3}% -\contentsline {section}{\numberline {2.4}Baseboard Management Controller}{15}{section.2.4}% -\contentsline {chapter}{\numberline {3}Key components in modern firmware [WIP]}{17}{chapter.3}% -\contentsline {section}{\numberline {3.1}General structure of coreboot}{17}{section.3.1}% -\contentsline {subsection}{\numberline {3.1.1}Bootblock stage}{18}{subsection.3.1.1}% -\contentsline {subsection}{\numberline {3.1.2}Romstage}{18}{subsection.3.1.2}% -\contentsline {subsection}{\numberline {3.1.3}Ramstage}{19}{subsection.3.1.3}% -\contentsline {subsection}{\numberline {3.1.4}Payload}{19}{subsection.3.1.4}% -\contentsline {section}{\numberline {3.2}Advanced Configuration and Power Interface}{19}{section.3.2}% -\contentsline {section}{\numberline {3.3}System Management Mode}{20}{section.3.3}% -\contentsline {section}{\numberline {3.4}AMD Platform Security Processor and Intel Management Engine}{21}{section.3.4}% -\contentsline {chapter}{\numberline {4}Memory initialization and training algorithms [WIP]}{22}{chapter.4}% -\contentsline {section}{\numberline {4.1}Importance of memory initialization}{22}{section.4.1}% -\contentsline {section}{\numberline {4.2}Memory training algorithms}{22}{section.4.2}% -\contentsline {section}{\numberline {4.3}Practical examples}{23}{section.4.3}% -\contentsline {chapter}{\numberline {5}Firmware and hardware virtualization [WIP]}{24}{chapter.5}% -\contentsline {section}{\numberline {5.1}Introduction to hardware virtualization}{24}{section.5.1}% -\contentsline {section}{\numberline {5.2}Role of BIOS/UEFI in virtualization}{24}{section.5.2}% -\contentsline {section}{\numberline {5.3}Security and freedom considerations}{24}{section.5.3}% -\contentsline {section}{\numberline {5.4}Future trends in firmware and virtualization}{24}{section.5.4}% -\contentsline {chapter}{Conclusion}{25}{chapter*.2}% -\contentsline {section}{\numberline {5.5}Summary of key points}{25}{section.5.5}% -\contentsline {section}{\numberline {5.6}Call for action}{25}{section.5.6}% -\contentsline {chapter}{Bibliography}{26}{section.5.6}% -\contentsline {chapter}{GNU Free Documentation License}{31}{chapter*.4}% +\contentsline {chapter}{Abstract}{5}{chapter*.1}% +\contentsline {chapter}{\numberline {1}Introduction to firmware and BIOS evolution}{6}{chapter.1}% +\contentsline {section}{\numberline {1.1}Historical context of BIOS}{6}{section.1.1}% +\contentsline {subsection}{\numberline {1.1.1}Definition and origin}{6}{subsection.1.1.1}% +\contentsline {subsection}{\numberline {1.1.2}Functionalities and limitations}{7}{subsection.1.1.2}% +\contentsline {section}{\numberline {1.2}Modern BIOS and UEFI}{8}{section.1.2}% +\contentsline {subsection}{\numberline {1.2.1}Transition from traditional BIOS to UEFI (Unified Extensible Firmware Interface)}{8}{subsection.1.2.1}% +\contentsline {subsection}{\numberline {1.2.2}An other way with \textit {coreboot}}{8}{subsection.1.2.2}% +\contentsline {section}{\numberline {1.3}Shift in firmware responsibilities}{10}{section.1.3}% +\contentsline {chapter}{\numberline {2}Characteristics of ASUS KGPE-D16 mainboard}{11}{chapter.2}% +\contentsline {section}{\numberline {2.1}Overview of ASUS KGPE-D16 hardware}{12}{section.2.1}% +\contentsline {section}{\numberline {2.2}Chipset}{13}{section.2.2}% +\contentsline {section}{\numberline {2.3}Processors}{15}{section.2.3}% +\contentsline {section}{\numberline {2.4}Baseboard Management Controller}{16}{section.2.4}% +\contentsline {chapter}{\numberline {3}Key components in modern firmware [WIP]}{18}{chapter.3}% +\contentsline {section}{\numberline {3.1}General structure of coreboot}{18}{section.3.1}% +\contentsline {subsection}{\numberline {3.1.1}Bootblock stage}{19}{subsection.3.1.1}% +\contentsline {subsection}{\numberline {3.1.2}Romstage}{20}{subsection.3.1.2}% +\contentsline {subsection}{\numberline {3.1.3}Ramstage}{20}{subsection.3.1.3}% +\contentsline {subsubsection}{\numberline {3.1.3.1}Advanced Configuration and Power Interface}{20}{subsubsection.3.1.3.1}% +\contentsline {subsubsection}{\numberline {3.1.3.2}System Management Mode}{21}{subsubsection.3.1.3.2}% +\contentsline {subsection}{\numberline {3.1.4}Payload}{22}{subsection.3.1.4}% +\contentsline {section}{\numberline {3.2}AMD Platform Security Processor and Intel Management Engine}{22}{section.3.2}% +\contentsline {chapter}{\numberline {4}Memory initialization and training algorithms [WIP]}{23}{chapter.4}% +\contentsline {section}{\numberline {4.1}Importance of memory initialization}{23}{section.4.1}% +\contentsline {section}{\numberline {4.2}Memory training algorithms}{23}{section.4.2}% +\contentsline {section}{\numberline {4.3}Practical examples}{24}{section.4.3}% +\contentsline {chapter}{\numberline {5}Firmware and hardware virtualization [WIP]}{25}{chapter.5}% +\contentsline {section}{\numberline {5.1}Introduction to hardware virtualization}{25}{section.5.1}% +\contentsline {section}{\numberline {5.2}Role of BIOS/UEFI in virtualization}{25}{section.5.2}% +\contentsline {section}{\numberline {5.3}Security and freedom considerations}{25}{section.5.3}% +\contentsline {section}{\numberline {5.4}Future trends in firmware and virtualization}{25}{section.5.4}% +\contentsline {chapter}{Conclusion}{26}{chapter*.2}% +\contentsline {section}{\numberline {5.5}Summary of key points}{26}{section.5.5}% +\contentsline {section}{\numberline {5.6}Call for action}{26}{section.5.6}% +\contentsline {chapter}{Bibliography}{27}{section.5.6}% +\contentsline {chapter}{List of Figures}{32}{chapter*.3}% +\contentsline {chapter}{List of Listings}{33}{chapter*.3}% +\contentsline {chapter}{GNU Free Documentation License}{34}{chapter*.5}% diff --git a/packages.tex b/packages.tex index f839ef9..561e447 100644 --- a/packages.tex +++ b/packages.tex @@ -1,11 +1,19 @@ % -*- coding: utf-8 -*- -% Preamble +% Copyright (C) 2024 Adrien 'neox' Bourmault +% +% Permission is granted to copy, distribute and/or modify this document +% under the terms of the GNU Free Documentation License, Version 1.3 +% or any later version published by the Free Software Foundation; +% with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. +% A copy of the license is included in the section entitled "GNU +% Free Documentation License". + \documentclass[french, 11pt]{report} \usepackage[utf8]{inputenc} \usepackage{url} \usepackage{float} \usepackage{fontspec} - \usepackage{hyperref} + \usepackage[hidelinks]{hyperref} \usepackage{setspace} \usepackage[style=numeric]{biblatex} \usepackage{tocloft} @@ -18,6 +26,7 @@ \usepackage{xcolor} \usepackage{chngcntr} \usepackage{changepage} + \usepackage{array} \usepackage[a4paper, portrait, margin=1.45cm]{geometry} \title{Titre du mémoire} \author{Nom et prénom de l'auteur} @@ -34,8 +43,6 @@ \renewcommand{\cftsecleader}{\cftdotfill{\cftdotsep}} %places dots on sections lines as well -\counterwithout{figure}{chapter} - \cftsetindents{section}{0pt}{4em} \cftsetindents{subsection}{10pt}{4em} \cftsetindents{subsubsection}{20pt}{4em} diff --git a/titlepage.tex b/titlepage.tex index 3db81f5..a9a1dfd 100644 --- a/titlepage.tex +++ b/titlepage.tex @@ -1,3 +1,12 @@ +% -*- coding: utf-8 -*- +% Copyright (C) 2024 Adrien 'neox' Bourmault +% +% Permission is granted to copy, distribute and/or modify this document +% under the terms of the GNU Free Documentation License, Version 1.3 +% or any later version published by the Free Software Foundation; +% with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. +% A copy of the license is included in the section entitled "GNU +% Free Documentation License". % Titlepage \begin{titlepage}