GNUBoot
/
hardware-init-review
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

WIP: some progressed and refactoring

This commit is contained in:
Adrien Bourmault 2024-08-22 15:38:22 +02:00
parent 312b458ec5
commit cfd5194fbc
Signed by: neox
GPG Key ID: 57BC26A3687116F6
8 changed files with 483 additions and 351 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Makefile
View File

@ -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

8
bibliographie.bib
View File

@ -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}
}

28
hardware_init_review.bbl
View File

@ -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}{%

BIN
hardware_init_review.pdf
View File

Binary file not shown.

688
hardware_init_review.tex
View File

@ -1,3 +1,13 @@
% -*- coding: utf-8 -*-
% Copyright (C) 2024 Adrien 'neox' Bourmault <neox@gnu.org>
%
% 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}

76
hardware_init_review.toc
View File

@ -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}%

15
packages.tex
View File

@ -1,11 +1,19 @@
% -*- coding: utf-8 -*-
% Preamble
% Copyright (C) 2024 Adrien 'neox' Bourmault <neox@gnu.org>
%
% 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}

9
titlepage.tex
View File

@ -1,3 +1,12 @@
% -*- coding: utf-8 -*-
% Copyright (C) 2024 Adrien 'neox' Bourmault <neox@gnu.org>
%
% 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}