summaryrefslogtreecommitdiffstats
path: root/site/faq
diff options
context:
space:
mode:
Diffstat (limited to 'site/faq')
-rw-r--r--site/faq/index.php66
1 files changed, 46 insertions, 20 deletions
diff --git a/site/faq/index.php b/site/faq/index.php
index c88e543..cf8e894 100644
--- a/site/faq/index.php
+++ b/site/faq/index.php
@@ -52,7 +52,7 @@
<li><a href="#intelbastards">Intel is uncooperative</a></li>
</ul>
</li>
- <li><a href="#librem">Will the Purism LibreM laptops be supported?</a></li>
+ <li><a href="#librem">Will the Purism Librem laptops be supported?</a></li>
<li><a href="#thinkpads">Will the latest Thinkpad models be supported?</a></li>
<li><a href="#desktops">Will desktop/server hardware be supported?</a></li>
<li><a href="#randomhardware">Hi, I have &lt;insert random system here&gt;, is it supported?</a></li>
@@ -113,18 +113,21 @@
</p>
<h3 id="intelme">Intel Management Engine (ME) <span class="ref">(<a href="#intelme">#intelme</a>)</span></h3>
<p>
- The most glaring issue on modern Intel hardware (beyond year ~2008) is
- the <i>Management Engine</i>. This is a separate processor that exists in all Intel chipsets
- past the year ~2006; some systems between those years can have the Management Engine firmware
- removed (with the ME processor permanently deactivated), but not replaced (due to cryptographic signature checking on the firmware)
- - see <a href="../docs/hcl/gm45_remove_me.html">../docs/hcl/gm45_remove_me.html</a>.
- The management engine provides remote access capabilities, independently from the running operating system. It has full access to
- your RAM, and it has full networking support. It also handles the TPM module, AMT (Active Management Technology), Boot Guard and
- various <a href="https://defectivebydesign.org/what_is_drm_digital_restrictions_management">DRM</a> mechanisms.
+ The ME is a separate processor that exists in all Intel chipsets past the year ~2006. It provides remote access capabilities,
+ independently from the running operating system, with full access to RAM, and full networking support. With a functioning ME, your system
+ is left wide open for attack. It can also phone home to Intel. It also handles the
+ TPM, AMT (Active Management Technology), Boot Guard and various <a href="https://defectivebydesign.org/what_is_drm_digital_restrictions_management">DRM</a> mechanisms.
The ME also performs some basic hardware initialization and power management, on recent systems.
</p>
<p>
- All modern Intel systems built after around the year 2008 (after ICH9) require this blob, and
+ The ME is <i>cryptographically signed</i>, which means that you cannot run a modified version of it. You also can't boot without it.
+ On some older chipsets (ICH8 and ICH9), it's possible to remove the ME <i>firmware</i> and still have a functioning system, where
+ the ME itself is permanently deactivated. For instance, libreboot supports several ICH9 based
+ laptops; see <a href="../docs/hcl/gm45_remove_me.html">../docs/hcl/gm45_remove_me.html</a>.
+ On later chipsets (basically anything produced since 2010), this is not possible.
+ </p>
+ <p>
+ All modern Intel systems built after around the year 2008/2009 (after ICH9) require this proprietary firmware, and
will not boot without it (or will shut down after 30 minutes). Replacing it is impossible, unless you are Intel (only they have the private
key, necessary for signing the firmware). The Management Engine is covered on a lot of websites
(e.g. <a href="http://me.bios.io/Main_Page">me.bios.io</a>, <a href="http://io.smashthestack.org/me/">smashthestack.org</a>,
@@ -142,8 +145,11 @@
the ME firmware is <i><a href="https://www.gnu.org/proprietary/proprietary-tyrants.html">tivoized</a></i>.
</p>
<p>
- The Management Engine is a giant backdoor, allowing full access to your entire system for malicious adversaries.
- The libreboot project strongly recommends that you avoid it entirely, and this means avoiding the latest generation of Intel hardware.
+ <b><i>
+ The Management Engine is a giant backdoor, allowing full access to your entire system for malicious adversaries. You don't have any privacy
+ at all on systems that have this.
+ 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="microcode">CPU microcode updates <span class="ref">(<a href="#microcode">#microcode</a>)</span></h3>
<p>
@@ -178,6 +184,12 @@
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.
@@ -194,6 +206,12 @@
Recent Intel graphics chipsets also <a href="https://01.org/linuxgraphics/intel-linux-graphics-firmwares?langredirect=1">require firmware blobs</a>.
</p>
<p>
+ Intel is only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because
+ of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly
+ to the free software community. Reverse engineering won't solve anything long-term, unfortunately, but we need to keep doing it
+ 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>
</p>
@@ -201,16 +219,24 @@
<a href="#pagetop">Back to top of page</a>
</p>
- <h2 id="librem">Will the Purism LibreM laptops be supported? <span class="ref">(<a href="#librem">#librem</a>)</span></h2>
+ <h2 id="librem">Will the Purism Librem laptops be supported? <span class="ref">(<a href="#librem">#librem</a>)</span></h2>
<p>
- Probably not (it uses latest generation of Intel hardware - see <a href="#intel">#intel</a>). It would be nice
- if libreboot could run on these laptops, but it's extremely unlikely
- due to the fact that there are signed proprietary blobs that cannot be replaced and are required
- (<a href="#intelme">Intel Management Engine</a> and <a href="#microcode">CPU microcode updates</a>).
+ Probably not. There are several privacy, security and freedom issues with these laptops, due to the Intel chipsets
+ that they use. See <a href="#intel">#intel</a>. There are signed proprietary blobs which cannot be replaced
+ (e.g. <a href="#intelme">Intel Management Engine</a> and <a href="#microcode">CPU microcode updates</a>).
It uses the proprietary <a href="#fsp">Intel FSP</a> blob for the entire hardware initialization, which
Intel <a href="#intelbastards">won't provide</a> the source code for. The Video BIOS (initialization firmware
- for the graphics hardware) is also proprietary, and will likely take years to reverse engineer and replace
- (once again, Intel won't provide the source code).
+ for the graphics hardware) is also proprietary.
+ </p>
+ <p>
+ It will likely take many years to replace even one of these blobs, let alone all of them. Some of them (ME firmware and microcode) can't even be replaced,
+ which immediately disqualifies these laptops from being added to libreboot. Google engineers have tried
+ for many years to get source code from Intel, and to reverse engineer the blobs that Intel provides. So far, they have
+ been unsuccessful. Google is also one of the companies that funds the coreboot project, and they hire a lot of the core
+ developers, so it's not like they don't have vast resources at their disposal. Smaller companies have no chance.
+ </p>
+ <p>
+ It's a shame, because these laptops would be perfect for libreboot.
</p>
<p>
<a href="#pagetop">Back to top of page</a>
@@ -221,7 +247,7 @@
The latest ThinkPad generation supported in libreboot are the ones
using the GM45 (ICH9) chipsets, such as the ThinkPad X200 or T400.
ThinkPads newer than this generation will probably never be supported in libreboot,
- due to the fact that there are signed blobs that cannot be replaced
+ due to the fact that there are signed blobs that cannot be removed or replaced
(e.g. <a href="#intelme">Intel Management Engine</a>). See <a href="#intel">#intel</a>. Newer Lenovo laptops are
also <a href="https://www.phoronix.com/scan.php?page=news_item&px=Intel-Boot-Guard-Kills-Coreboot">starting to use</a> the <a href="https://mjg59.dreamwidth.org/33981.html">Intel Boot Guard</a>, which specifically blocks the use of
firmware that has not been signed by the OEM.