Don't use html U, B or I tags. Use HTML5 tags strong and em

1 files changed, 46 insertions, 46 deletions

diff --git a/site/faq/index.php b/site/faq/index.php
index 207ac9b..a0a41d4 100644
--- a/site/faq/index.php
+++ b/site/faq/index.php
@@ -115,8 +115,8 @@
 			<h2 id="intel">Why is the latest Intel hardware unsupported in libreboot? <span class="r"><a href="#intel">#intel</a></span></h2>
 				<p>
 					It is extremely unlikely that any post-2008 Intel hardware will ever be supported in libreboot, due to
-					severe security and freedom issues; so severe, that <i>the libreboot project recommends avoiding all modern Intel hardware.
-					If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible</i>. The main issues are as follows:
+					severe security and freedom issues; so severe, that <em>the libreboot project recommends avoiding all modern Intel hardware.
+					If you have an Intel based system affected by the problems described below, then you should get rid of it as soon as possible</em>. The main issues are as follows:
 				</p>
 				<h3 id="intelme">Intel Management Engine (ME) <span class="r"><a href="#intelme">#intelme</a></span></h3>
 					<p>
@@ -126,20 +126,20 @@
 						located in the (G)MCH chip.  In Q3 2009, the first generation of Intel Core
 						i3/i5/i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller
 						Hubs, or PCHs, brought a more tightly integrated ME (now at version 6.0) inside
-						the PCH chip, which itself replaced the ICH.  Thus, the ME is <b><i>present on all
-						Intel desktop, mobile (laptop), and server systems since mid 2006</i></b>.
+						the PCH chip, which itself replaced the ICH.  Thus, the ME is <strong><em>present on all
+						Intel desktop, mobile (laptop), and server systems since mid 2006</em></strong>.
 					</p>
 					<p>
 						The ME consists of an ARC processor core (replaced with other processor cores in
 						later generations of the ME), code and data caches, a timer, and a secure
 						internal bus to which additional devices are connected, including a cryptography
-						engine, internal ROM and RAM, memory controllers, and a <b><i>direct memory access
-						(DMA) engine</i></b> to access the host operating system's memory as well as to
+						engine, internal ROM and RAM, memory controllers, and a <strong><em>direct memory access
+						(DMA) engine</em></strong> to access the host operating system's memory as well as to
 						reserve a region of protected external memory to supplement the ME's limited
-						internal RAM.  The ME also has <b><i>network access</i></b> with its own MAC address
+						internal RAM.  The ME also has <strong><em>network access</em></strong> with its own MAC address
 						through an Intel Gigabit Ethernet Controller.  Its boot program, stored on the
 						internal ROM, loads a firmware "manifest" from the PC's SPI flash chip.  This
-						manifest is <b><i>signed with a strong cryptographic key</i></b>, which differs
+						manifest is <strong><em>signed with a strong cryptographic key</em></strong>, which differs
 						between versions of the ME firmware.  If the manifest isn't signed by a specific
 						Intel key, the boot ROM won't load and execute the firmware and the ME processor
 						core will be halted.
@@ -147,12 +147,12 @@
 					<p>
 						The ME firmware is compressed and consists of modules that are listed in the
 						manifest along with secure cryptographic hashes of their contents.  One module
-						is the operating system kernel, which is based on a <b><i>proprietary real-time
-						operating system (RTOS) kernel</i></b> called "ThreadX".  The developer, Express
+						is the operating system kernel, which is based on a <strong><em>proprietary real-time
+						operating system (RTOS) kernel</em></strong> called "ThreadX".  The developer, Express
 						Logic, sells licenses and source code for ThreadX.  Customers such as Intel are
 						forbidden from disclosing or sublicensing the ThreadX source code.  Another
-						module is the Dynamic Application Loader (DAL), which consists of a <b><i>Java
-						virtual machine</i></b> and set of preinstalled Java classes for cryptography,
+						module is the Dynamic Application Loader (DAL), which consists of a <strong><em>Java
+						virtual machine</em></strong> and set of preinstalled Java classes for cryptography,
 						secure storage, etc.  The DAL module can load and execute additional ME modules
 						from the PC's HDD or SSD.  The ME firmware also includes a number of native
 						application modules within its flash memory space, including Intel Active
@@ -164,12 +164,12 @@
 						Active Management Technology (AMT)</a> application, part of the Intel "vPro"
 						brand, is a Web server and application code that enables remote users to power
 						on, power off, view information about, and otherwise manage the PC.  It can
-						be <b><i>used remotely even while the PC is powered off</i></b> (via Wake-on-Lan).
+						be <strong><em>used remotely even while the PC is powered off</em></strong> (via Wake-on-Lan).
 						Traffic is encrypted using SSL/TLS libraries, but recall that all of the major
 						SSL/TLS implementations have had highly publicized vulnerabilities.  The AMT
-						application itself has <b><i><a
+						application itself has <strong><em><a
 						href="https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Known_vulnerabilities_and_exploits">
-						known vulnerabilities</a></i></b>, which have been exploited to develop rootkits
+						known vulnerabilities</a></em></strong>, which have been exploited to develop rootkits
 						and keyloggers and covertly gain encrypted access to the management features of
 						a PC.  Remember that the ME has full access to the PC's RAM.  This means that an
 						attacker exploiting any of these vulnerabilities may gain access to everything
@@ -182,7 +182,7 @@
 						Intel Core i3/i5/i7 (Haswell) CPUs.  It allows a PC OEM to generate an
 						asymmetric cryptographic keypair, install the public key in the CPU, and prevent
 						the CPU from executing boot firmware that isn't signed with their private key.
-						This means that <b><i>coreboot and libreboot are impossible to port</i></b> to such
+						This means that <strong><em>coreboot and libreboot are impossible to port</em></strong> to such
 						PCs, without the OEM's private signing key.  Note that systems assembled from
 						separately purchased mainboard and CPU parts are unaffected, since the vendor of
 						the mainboard (on which the boot firmware is stored) can't possibly affect the
@@ -190,9 +190,9 @@
 					</p>
 					<p>
 						ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include
-						an ME application for <b><i>audio and video <a
+						an ME application for <strong><em>audio and video <a
 						href="https://defectivebydesign.org/what_is_drm_digital_restrictions_management">
-						DRM</a></i></b> called "Protected Audio Video Path" (PAVP).  The ME receives from
+						DRM</a></em></strong> called "Protected Audio Video Path" (PAVP).  The ME receives from
 						the host operating system an encrypted media stream and encrypted key, decrypts
 						the key, and sends the encrypted media decrypted key to the GPU, which then
 						decrypts the media.  PAVP is also used by another ME application to draw an
@@ -203,8 +203,8 @@
 						DRM application called "Intel Insider".  Like the AMT application, these DRM
 						applications, which in themselves are defective by design, demonstrate the
 						omnipotent capabilities of the ME: this hardware and its proprietary firmware
-						can access and control everything that is in RAM and even <b><i>everything that is
-						shown on the screen</i></b>.
+						can access and control everything that is in RAM and even <strong><em>everything that is
+						shown on the screen</em></strong>.
 					</p>
 					<p>
 						The Intel Management Engine with its proprietary firmware has complete access to
@@ -240,46 +240,46 @@
 						ROM would reject any modified firmware that isn't signed by Intel.  Thus, the ME
 						firmware is both hopelessly proprietary and "tivoized".
 					</p>
-					<p><b>
+					<p><strong>
 						In summary, the Intel Management Engine and its applications are a backdoor with
 						total access to and control over the rest of the PC.  The ME is a threat to
 						freedom, security, and privacy, and the libreboot project strongly recommends
 						avoiding it entirely.  Since recent versions of it can't be removed, this means
 						avoiding all recent generations of Intel hardware.
-					</b></p>
+					</strong></p>
 					<p>
 						More information about the Management Engine can be found on various Web sites,
 						including <a href="http://me.bios.io/Main_Page">me.bios.io</a>, <a
 						href="http://io.smashthestack.org/me/">the smashthestack network</a>, <a
 						href="http://www.coreboot.org/Intel_Management_Engine">coreboot wiki</a>, and <a
 						href="https://en.wikipedia.org/wiki/Intel_Active_Management_Technology">
-						Wikipedia</a>.  The book <b><i><a href="https://www.apress.com/9781430265719">
-						Platform Embedded Security Technology Revealed</a></i></b> describes in great
+						Wikipedia</a>.  The book <strong><em><a href="https://www.apress.com/9781430265719">
+						Platform Embedded Security Technology Revealed</a></em></strong> describes in great
 						detail the ME's hardware architecture and firmware application modules.
 					</p>
 				<h3 id="fsp">Firmware Support Package (FSP) <span class="r"><a href="#fsp">#fsp</a></span></h3>
 					<p>
 						On all recent Intel systems, coreboot support has revolved around integrating a blob (for each system) called
-						the <i>FSP</i> (firmware support package), which handles all of the hardware initialization, including
+						the <em>FSP</em> (firmware support package), which handles all of the hardware initialization, including
 						memory initialization. Reverse engineering and replacing this blob is almost impossible, due to how complex it is. Even for the most skilled developer,
 						it would take years to replace. Intel distributes this blob to firmware developers, without source.
 					</p>
 					<p>
 						Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is
-						a special mode that operates below the operating system level. <b>It's possible that rootkits could be implemented there, which could
+						a special mode that operates below the operating system level. <strong>It's possible that rootkits could be implemented there, which could
 						perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at
-						all.</b> In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find them).
+						all.</strong> In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find them).
 					</p>
 				<h3 id="microcode">CPU microcode updates <span class="r"><a href="#microcode">#microcode</a></span></h3>
 					<p>
-						All modern x86 CPUs (from Intel and AMD) use what is called <i>microcode</i>. CPUs are extremely complex,
+						All modern x86 CPUs (from Intel and AMD) use what is called <em>microcode</em>. CPUs are extremely complex,
 						and difficult to get right, so the circuitry is designed in a very generic way, where only basic instructions
 						are handled in hardware. Most of the instruction set is implemented using microcode, which is low-level software
 						running inside the CPU that can specify how the circuitry is to be used, for each instruction. The built-in microcode
 						is part of the hardware, and read-only. Both the circuitry and the microcode can have bugs, which could cause reliability issues.
 					</p>
 					<p>
-						Microcode <i>updates</i> are proprietary blobs, uploaded to the CPU at boot time, which patches the built-in
+						Microcode <em>updates</em> are proprietary blobs, uploaded to the CPU at boot time, which patches the built-in
 						microcode and disables buggy parts of the CPU to improve reliability. In the past, these updates were
 						handled by the operating system kernel, but on all recent systems it is the boot firmware that must perform this task.
 						Coreboot does distribute microcode updates for Intel and AMD CPUs, but libreboot cannot, because the whole point of libreboot
@@ -292,15 +292,15 @@
 						unstable (memory corruption, for example).
 					</p>
 					<p>
-						Intel CPU microcode updates are <i>signed</i>, which means that you could not even run a modified version, even if
+						Intel CPU microcode updates are <em>signed</em>, which means that you could not even run a modified version, even if
 						you had the source code. If you try to upload your own modified updates, the CPU will reject them. In other words,
-						the microcode updates are <i><a href="https://www.gnu.org/proprietary/proprietary-tyrants.html">tivoized</a></i>.
+						the microcode updates are <em><a href="https://www.gnu.org/proprietary/proprietary-tyrants.html">tivoized</a></em>.
 					</p>
 				<h3 id="intelbastards">Intel is uncooperative <span class="r"><a href="#intelbastards">#intelbastards</a></span></h3>
 					<p>
 						For years, coreboot has been struggling against Intel. Intel has been shown to be extremely uncooperative in general.
 						Many coreboot developers, and companies, have tried to get Intel to cooperate; namely, releasing source code
-						for the firmware components. Even Google, which sells millions of <i>chromebooks</i> (coreboot preinstalled)
+						for the firmware components. Even Google, which sells millions of <em>chromebooks</em> (coreboot preinstalled)
 						have been unable to persuade them.
 					</p>
 					<p>
@@ -318,8 +318,8 @@
 						anyway. Moving forward, Intel hardware is a non-option unless a radical change happens within Intel.
 					</p>
 					<p>
-						<b>Basically, all Intel hardware from year 2010 and beyond will never be supported by libreboot. The libreboot project
-						is actively ignoring all modern Intel hardware at this point, and focusing on alternative platforms.</b>
+						<strong>Basically, all Intel hardware from year 2010 and beyond will never be supported by libreboot. The libreboot project
+						is actively ignoring all modern Intel hardware at this point, and focusing on alternative platforms.</strong>
 					</p>
 				<p>
 					<a href="#pagetop">Back to top of page</a>
@@ -372,7 +372,7 @@
 					coreboot do have onboard graphics chipsets, but these also require a proprietary Video BIOS, in most cases.
 				</p>
 				<p>
-					There is the XGI Z9s PCI-E graphics card, documented under <i>Board Ports</i> in <a href="../docs/tasks.html">../docs/tasks.html</a>, which might be viable for you.
+					There is the XGI Z9s PCI-E graphics card, documented under <em>Board Ports</em> in <a href="../docs/tasks.html">../docs/tasks.html</a>, which might be viable for you.
 				</p>
 				<p>
 					Although not desktop hardware (it's a server board), libreboot does support
@@ -413,7 +413,7 @@
 
 			<h2 id="arm">What about ARM? <span class="r"><a href="#arm">#arm</a></span></h2>
 				<p>
-					Libreboot has support for some ARM based laptops, using the <i>Rockchip RK3288</i> SoC.
+					Libreboot has support for some ARM based laptops, using the <em>Rockchip RK3288</em> SoC.
 					Check the libreboot <a href="../docs/hcl/index.html#supported_list">hardware compatibility list</a>, for more information.
 				</p>
 				<p>
@@ -495,12 +495,12 @@
 					More information about payloads can be found at <a href="http://www.coreboot.org/Payloads">coreboot.org/Payloads</a>.
 				</p>
 				<p>
-					Libreboot inherits the modular payload concept from coreboot, which means that pre-OS bare-metal <i>BIOS setup</i> programs
-					are not very practical. Coreboot (and libreboot) does include a utility called <i>nvramtool</i>, which can be used
-					to change some settings. You can find nvramtool under <i>coreboot/util/nvramtool/</i>, in the libreboot source archives.
+					Libreboot inherits the modular payload concept from coreboot, which means that pre-OS bare-metal <em>BIOS setup</em> programs
+					are not very practical. Coreboot (and libreboot) does include a utility called <em>nvramtool</em>, which can be used
+					to change some settings. You can find nvramtool under <em>coreboot/util/nvramtool/</em>, in the libreboot source archives.
 				</p>
 				<p>
-					The <i>-a</i> option in nvramtool will list the available options, and <i>-w</i> can be used to change them. Consult
+					The <em>-a</em> option in nvramtool will list the available options, and <em>-w</em> can be used to change them. Consult
 					the nvramtool documentation on the coreboot wiki for more information.
 				</p>
 				<p>
@@ -511,8 +511,8 @@
 				</p>
 			<h2 id="bootloader">Do I need to install a bootloader when installing GNU/Linux? <span class="r"><a href="#bootloader">#bootloader</a></span></h2>
 				<p>
-					Libreboot integrates the GRUB bootloader already, as a <i><a href="http://www.coreboot.org/Payloads">payload</a></i>. This means
-					that the GRUB bootloader is actually <i>flashed</i>, as part of the boot firmware (libreboot). This means that you do
+					Libreboot integrates the GRUB bootloader already, as a <em><a href="http://www.coreboot.org/Payloads">payload</a></em>. This means
+					that the GRUB bootloader is actually <em>flashed</em>, as part of the boot firmware (libreboot). This means that you do
 					not have to install a boot loader on the HDD or SSD, when installing GNU/Linux. You'll be able to boot GNU/Linux just fine,
 					using the bootloader (GRUB) that is in the flash chip.
 				</p>
@@ -545,10 +545,10 @@
 				<p>
 					The Video BIOS is present on most video hardware. On all current libreboot systems, this is implemented using free software.
 					The Video BIOS is responsible for initializing any sort of visual display; without it, you'd have what's called
-					a <i>headless</i> system.
+					a <em>headless</em> system.
 				</p>
 				<p>
-					For integrated graphics, the VBIOS is usually embedded as an <i>option ROM</i> in the main boot firmware. For external
+					For integrated graphics, the VBIOS is usually embedded as an <em>option ROM</em> in the main boot firmware. For external
 					graphics, the VBIOS is usually on the graphics card itself. This is usually proprietary; the only difference is that
 					SeaBIOS executes it (alternatively, you embed it in a coreboot ROM image and have coreboot executes it, if you use
 					a different payload, such as GRUB).
@@ -702,8 +702,8 @@
 						The current theory (unproven) is that this will at least prevent malicious drives from wrongly manipulating data
 						being read from or written to the drive, since it can't access your LUKS key if it's only ever in RAM,
 						provided that the HDD doesn't have DMA (USB devices don't have DMA). The worst that it could do in this case
-						is destroy your data. Of course, you should make sure never to put any keyfiles in the LUKS header. <b>Take what
-						this paragraph says with a pinch of salt. This is still under discussion, and none of this is proven.</b>
+						is destroy your data. Of course, you should make sure never to put any keyfiles in the LUKS header. <strong>Take what
+						this paragraph says with a pinch of salt. This is still under discussion, and none of this is proven.</strong>
 					</p>
 					<p>
 						<a href="#pagetop">Back to top of page</a>