summaryrefslogtreecommitdiffstats
path: root/site
diff options
context:
space:
mode:
Diffstat (limited to 'site')
-rw-r--r--site/faq/index.php28
1 files changed, 14 insertions, 14 deletions
diff --git a/site/faq/index.php b/site/faq/index.php
index cf8e894..6646d39 100644
--- a/site/faq/index.php
+++ b/site/faq/index.php
@@ -47,8 +47,8 @@
<a href="#intel">Why is the latest Intel hardware unsupported in libreboot?</a>
<ul>
<li><a href="#intelme">Intel Management Engine (ME)</a></li>
- <li><a href="#microcode">CPU microcode updates</a></li>
<li><a href="#fsp">Firmware Support Package (FSP)</a></li>
+ <li><a href="#microcode">CPU microcode updates</a></li>
<li><a href="#intelbastards">Intel is uncooperative</a></li>
</ul>
</li>
@@ -151,6 +151,19 @@
The libreboot project strongly recommends that you avoid it entirely, and this means avoiding all recent generations of Intel hardware.
</i></b>
</p>
+ <h3 id="fsp">Firmware Support Package (FSP) <span class="ref">(<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
+ 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
+ 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).
+ </p>
<h3 id="microcode">CPU microcode updates <span class="ref">(<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,
@@ -177,19 +190,6 @@
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>.
</p>
- <h3 id="fsp">Firmware Support Package (FSP) <span class="ref">(<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
- 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
- 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).
- </p>
<h3 id="intelbastards">Intel is uncooperative <span class="ref">(<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.