summaryrefslogtreecommitdiffstats
path: root/site/faq/index.php
blob: 207ac9b5918d76df64f78e799f2a28875039bf1c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
<?php
/*
    Frequently asked questions
    Copyright (C) 2015  Francis Rowe <info@gluglug.org.uk>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU Affero General Public License as
    published by the Free Software Foundation, either version 3 of the
    License, or (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU Affero General Public License for more details.

    You should have received a copy of the GNU Affero General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/
	header('Content-type: text/html; charset=utf-8');
	ob_start();
	include_once "../common/variables.php";
	include_once "../common/functions.php";
?>
<!DOCTYPE html>
<html>
<head>
	<style type="text/css">
		<?php echo miniCss(file_get_contents("../common/css/main.css")); ?>
	</style>
	<title>Answers to Frequently Asked Questions about libreboot</title>
</head>

<body>

	<div id="pagetop">

		<h1>Answers to Frequently Asked Questions about libreboot</h1>
			<p>
				Over time, there have been many questions asked about libreboot. We have to answer them every time,
				so it makes sense to document them here instead. More questions and answers will be added here,
				as time goes by. <a href="../">Back to home page</a>
			</p>
			<h2>Hardware compatibility</h2>
				<ul class="c">
					<li><a href="#compatibility">What systems are compatible with libreboot?</a></li>
					<li>
						<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="#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>
					<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>
					<li><a href="#arm">What about ARM?</a></li>
					<li><a href="#amd">What about AMD?</a></li>
				</ul>
			<h2>General questions</h2>
				<ul class="c">
					<li><a href="#install">How do I install libreboot?</a></li>
					<li><a href="#repugnantpi">How do I program an SPI flash chip with the Raspberry Pi?</a></li>
					<li><a href="#bootpassword">How do I set a boot password?</a></li>
					<li><a href="#writeprotect">How do I write-protect the flash chip?</a> (for example, to protect against firmware-level malware being installed)</li>
					<li><a href="#biossettings">How do I change the BIOS settings?</a></li>
					<li><a href="#bootloader">Do I need to install a bootloader when installing GNU/Linux?</a></li>
					<li><a href="#reinstallos">Do I need to re-flash when I re-install GNU/Linux?</a></li>
				</ul>
			<h2>Freedom questions</h2>
				<ul class="c">
					<li><a href="#external-gpu">Are external GPUs (e.g. PCI-E) OK?</a></li>
					<li>
						<a href="#otherfirmware">What other firmware exists outside of libreboot?</a>
						<ul>
							<li><a href="#firmware-ec">EC (embedded controller) firmware</a></li>
							<li><a href="#firmware-hddssd">HDD/SSD firmware</a></li>
							<li><a href="#firmware-nic">NIC (ethernet controller)</a></li>
							<li><a href="#firmware-cpu">CPU microcode</a></li>
							<li><a href="#firmware-sound">Sound card</a></li>
							<li><a href="#firmware-webcam">Web cam</a></li>
							<li><a href="#firmware-usbhost">USB host controller</a></li>
							<li><a href="#firmware-wwan">WWAN firmware</a></li>
						</ul>
					</li>
				</ul>
			<h2>Operating Systems</h2>
				<ul class="c">
					<li><a href="#gnulinux">Can I use GNU/Linux?</a> (yes, you can)</li>
					<li><a href="#gnuhurd">Can I use GNU/Hurd?</a></li>
					<li><a href="#bsd">Can I use BSD?</a></li>
					<li><a href="#windows">Can I use Windows?</a></li>
					<li><a href="#otheros">Are other operating systems compatible?</a></li>
				</ul>
			<h2></h2>
	</div>

	<div>
		<h1>Hardware compatibility</h1>

			<h2 id="compatibility">What systems are compatible with libreboot? <span class="r"><a href="#compatibility">#compatibility</a></span></h2>
				<p>
					See <a href="../docs/hcl/index.html">../docs/hcl/index.html</a>.
				</p>
				<p>
					Several supported systems are also available with libreboot preinstalled.
					Check the <a href="../suppliers/">suppliers</a> page for more information.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<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:
				</p>
				<h3 id="intelme">Intel Management Engine (ME) <span class="r"><a href="#intelme">#intelme</a></span></h3>
					<p>
						Introduced in June 2006 in Intel's 965 Express Chipset Family of (Graphics and)
						Memory Controller Hubs, or (G)MCHs, and the ICH8 I/O Controller Family, the
						Intel Management Engine (ME) is a separate computing environment physically
						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>.
					</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
						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
						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
						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.
					</p>
					<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
						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,
						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
						Management Technology (AMT), an implementation of a Trusted Platform Module
						(TPM), Intel Boot Guard, and audio and video DRM systems.
					</p>
					<p>
						The <a href="https://www.fsf.org/blogs/community/active-management-technology">
						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).
						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
						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
						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
						on the PC as it runs: all open files, all running applications, all keys
						pressed, and more.
					</p>
					<p>
						<a href="https://mjg59.dreamwidth.org/33981.html">Intel Boot Guard</a> is an ME
						application introduced in Q2 2013 with ME firmware version 9.0 on 4th Generation
						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
						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
						public key stored on the CPU.
					</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
						href="https://defectivebydesign.org/what_is_drm_digital_restrictions_management">
						DRM</a></i></b> 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
						authentication PIN pad directly onto the screen.  In this usage, the PAVP
						application directly controls the graphics that appear on the PC's screen in a
						way that the host OS cannot detect.  ME firmware version 7.0 on PCHs with 2nd
						Generation Intel Core i3/i5/i7 (Sandy Bridge) CPUs replaces PAVP with a similar
						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>.
					</p>
					<p>
						The Intel Management Engine with its proprietary firmware has complete access to
						and control over the PC: it can power on or shut down the PC, read all open
						files, examine all running applications, track all keys pressed and mouse
						movements, and even capture or display images on the screen.  And it has a
						network interface that is demonstrably insecure, which can allow an attacker on
						the network to inject rootkits that completely compromise the PC and can report
						to the attacker all activities performed on the PC.  It is a threat to freedom,
						security, and privacy that can't be ignored.
					</p>
					<p>
						Before version 6.0 (that is, on systems from 2008/2009 and earlier), the ME can
						be disabled by setting a couple of values in the SPI flash memory.  The ME
						firmware can then be removed entirely from the flash memory space.  libreboot <a
						href="../docs/hcl/gm45_remove_me.html">does this</a> on the Intel 4 Series
						systems that it supports, such as the <a
						href="../docs/install/x200_external.html">Libreboot X200</a> and <a
						href="../docs/install/t400_external.html">Libreboot T400</a>.  ME firmware
						versions 6.0 and later, which are found on all systems with an Intel Core
						i3/i5/i7 CPU and a PCH, include "ME Ingition" firmware that performs some
						hardware initialization and power management.  If the ME's boot ROM does not
						find in the SPI flash memory an ME firmware manifest with a valid Intel
						signature, the whole PC will shut down after 30 minutes.
					</p>
					<p>
						Due to the signature verification, developing free replacement firmware for the
						ME is basically impossible.  The only entity capable of replacing the ME
						firmware is Intel.  As previously stated, the ME firmware includes proprietary
						code licensed from third parties, so Intel couldn't release the source code even
						if they wanted to.  And even if they developed completely new ME firmware
						without third-party proprietary code and released its source code, the ME's boot
						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>
						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>
					<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
						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
						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="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,
						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 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
						is to be 100% <a href="https://www.gnu.org/philosophy/free-sw.html">free software</a>.
					</p>
					<p>
						On some older Intel CPUs, it is possible to exclude the microcode updates and not have any reliability issues in practise.
						All current libreboot systems work without microcode updates (otherwise, they wouldn't be supported in libreboot). However,
						all modern Intel CPUs require the microcode updates, otherwise the system will not boot at all, or it will be extremely
						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
						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="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)
						have been unable to persuade them.
					</p>
					<p>
						Even when Intel does cooperate, they still don't provide source code. They might provide limited information
						(datasheets) under strict corporate NDA (non-disclosure agreement), but even that is not guaranteed. Even ODMs and IBVs can't
						get source code from Intel, in most cases (they will just integrate the blobs that Intel provides).
					</p>
					<p>
						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 <a href="https://www.gnu.org/philosophy/free-sw.html">free software</a> 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>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="librem">Will the Purism Librem laptops be supported? <span class="r"><a href="#librem">#librem</a></span></h2>
				<p>
					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.
				</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>
				</p>

			<h2 id="thinkpads">Will the latest ThinkPad models be supported? <span class="r"><a href="#thinkpads">#thinkpads</a></span></h2>
				<p>
					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 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.
				</p>
				<p>
					Coreboot does have support for some more recent Lenovo laptops, but libreboot cannot support most of these.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="desktops">Will desktop/server hardware be supported? <span class="r"><a href="#desktops">#desktops</a></span></h2>
				<p>
					A common issue with desktop hardware is the Video BIOS. Libreboot has to initialize the graphics chipset,
					but most graphics cards lack a free Video BIOS for this purpose. Some desktop motherboards supported in
					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.
				</p>
				<p>
					Although not desktop hardware (it's a server board), libreboot does support
					the <a href="../docs/hcl/kfsn4-dre.html">ASUS KFSN4-DRE</a>, with more server hardware
					support on the horizon, as outlined in <a href="../docs/tasks.html">../docs/tasks.html</a>.
					These boards have onboard graphics chipsets for which free native graphics initialization code
					does exist (as well as free initialization code for everything else in the boot firmware).
					These systems can be used to build very high-powered workstations, though it will be quite a bit
					bigger (physically) and more expensive than a standard desktop computer. However, it is the best
					option currently available in libreboot for this purpose.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="randomhardware">Hi, I have &lt;insert random system here&gt;, is it supported? <span class="r"><a href="#randomhardware">#randomhardware</a></span></h2>
				<p>
					Most likely not. First, you must consult coreboot's own hardware compatibility list
					at <a href="http://www.coreboot.org/Supported_Motherboards">http://www.coreboot.org/Supported_Motherboards</a> and,
					if it is supported, check whether it can run without any proprietary blobs in the ROM image. If it can: wonderful! Libreboot
					can support it, and you can add support for it using the notes at <a href="../docs/maintain/index.html">../docs/maintain/index.html</a>.
					If not, then you will need to figure out how to reverse engineer and replace (or remove) those blobs that do still exist, in such a way
					where the system is still usable in some defined way.
				</p>
				<p>
					For those systems where no coreboot support exists, you must first port it to coreboot and,
					if it can then run without any blobs in the ROM image, it can be added to libreboot.
					See: <a href="http://www.coreboot.org/Motherboard_Porting_Guide">Motherboard Porting Guide</a> (this is just the tip of the iceberg!)
				</p>
				<p>
					Please note that board development should be done upstream (in coreboot) and merged downstream (into libreboot). This is
					the correct way to do it, and it is how the libreboot project is coordinated so as to avoid too much forking of the
					coreboot source code.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<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.
					Check the libreboot <a href="../docs/hcl/index.html#supported_list">hardware compatibility list</a>, for more information.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>
			<h2 id="amd">What about AMD? <span class="r"><a href="#amd">#amd</a></span></h2>
				<p>
					Libreboot has support for some AMD platforms, with more on the horizon.
					See <a href="../docs/hcl/index.html">../docs/hcl/index.html</a>.
				</p>
				<p>
					More AMD-related information will be added to this page at a later date.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>
	</div>

	<div>
		<h1>General questions</h1>

			<h2 id="install">How do I install libreboot? <span class="r"><a href="#install">#install</a></span></h2>
				<p>
					See <a href="../docs/install/index.html">../docs/install/index.html</a>
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="repugnantpi">How do I program an SPI flash chip with the Raspberry Pi? <span class="r"><a href="#repugnantpi">#repugnantpi</a></span></h2>
				<p>
					The RPi can be used to install libreboot onto a system that uses SPI flash, but libreboot intentionally doesn't document it.
					Why? Blobs. The RPi requires a blob for the integrated video chipset, in order to boot. This was true of the original RPi, and
					has continued to be true for all subsequent revisions of the hardware. The RPi people clearly don't give a damn about your freedom,
					so we don't give a damn about endorsing them.
				</p>
				<p>
					There are other, more freedom-friendly SPI programmers available, documented on <a href="../docs/install/index.html">../docs/install/index.html</a>.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="bootpassword">How do I set a boot password? <span class="r"><a href="#bootpassword">#bootpassword</a></span></h2>
				<p>
					If you are using the GRUB payload, you can add a username and password (salted, hashed)
					to your GRUB configuration that resides inside the flash chip. The following guides (which
					also cover full disk encryption, including the /boot/ directory) show how to set a boot password
					in GRUB: <a href="../docs/gnulinux/encrypted_trisquel.html">../docs/gnulinux/encrypted_trisquel.html</a> and <a href="../docs/gnulinux/encrypted_parabola.html">../docs/gnulinux/encrypted_parabola.html</a>
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="writeprotect">How do I write-protect the flash chip? <span class="r"><a href="#writeprotect">#writeprotect</a></span></h2>
				<p>
					By default, there is no write-protection on a libreboot system. This is for usability reasons,
					because most people do not have easy access to an external programmer for re-flashing their firmware,
					or they find it inconvenient to use an external programmer.
				</p>
				<p>
					On some systems, it is possible to write-protect the firmware, such that it is rendered read-only
					at the OS level (external flashing is still possible, using dedicated hardware). For example, on 
					current GM45 laptops (e.g. ThinkPad X200, T400), you can write-protect (see <a href="../docs/hcl/gm45_remove_me.html#ich9gen">../docs/hcl/gm45_remove_me.html#ich9gen</a>).
					Depending on your flash chip,
					you can also write-protect the i945 laptops, such as the ThinkPad X60 or T60 (see <a href="../docs/security/x60_security.html">../docs/security/x60_security.html</a>)
					and <a href="../docs/security/t60_security.html">../docs/security/t60_security.html</a> for links to a video explaining it).
				</p>
				<p>
					It's possible to write-protect on all libreboot systems, but the instructions need to be written.
					The documentation is in the main git repository, so you are welcome to submit patches adding these instructions.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>
			<h2 id="biossettings">How do I change the BIOS settings? <span class="r"><a href="#biossettings">#biossettings</a></span></h2>
				<p>
					Libreboot actually uses the <a href="http://www.coreboot.org/GRUB2">GRUB payload</a>.
					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.
				</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 nvramtool documentation on the coreboot wiki for more information.
				</p>
				<p>
					In practise, you don't need to change any of those settings, in most cases.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</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
					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>
				<p>
					This also means that even if you remove the HDD or SSD, you'll still have a functioning bootloader installed which
					could be used to boot a live GNU/Linux distribution installer from a USB flash drive.
					See <a href="../docs/gnulinux/grub_boot_installer.html">.../docs/gnulinux/grub_boot_installer.html</a>
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>
			<h2 id="reinstallos">Do I need to re-flash when I re-install GNU/Linux? <span class="r"><a href="#reinstallos">#reinstallos</a></span></h2>
				<p>
					Not anymore. Recent versions of libreboot (using the GRUB payload) will automatically
					switch to a GRUB configuration on the HDD or SSD, if it exists. You can also load a different
					GRUB configuration, from any kind of device that is supported in GRUB (such as a USB flash drive). For more information,
					see <a href="../docs/gnulinux/grub_cbfs.html">../docs/gnulinux/grub_cbfs.html</a>
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>
	</div>

	<div>

		<h1>Freedom questions</h1>

			<h2 id="external-gpu">Are external GPUs (e.g. PCI-E) OK? <span class="r"><a href="#external-gpu">#external-gpu</a></span></h2>

				<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.
				</p>
				<p>
					For integrated graphics, the VBIOS is usually embedded as an <i>option ROM</i> 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).
				</p>
				<p>
					We're going to tentatively say no, they're not OK. Unless you're actively working to replace the VBIOS, or find out how
					to get a visual display without it (possible in some cases, if the kernel driver can be modified to work without it,
					possibly only needing certain non-executable data).
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="otherfirmware">What other firmware exists outside of libreboot? <span class="r"><a href="#otherfirmware">#otherfirmware</a></span></h2>

				<p>
					The main freedom issue on any system, is the boot firmware (usually referred to as a BIOS or UEFI). Libreboot replaces the boot firmware
					with fully free code, but even with libreboot, there may still be other hardware components in the system (e.g. laptop) that run
					their own dedicated firmware, sometimes proprietary. These are on secondary processors, where the firmware is usually read-only, written for very specific tasks.
					While these are unrelated to libreboot, technically speaking, it makes sense to document some of the issues here.
				</p>
				<p>
					Note that these issues are not unique to libreboot systems. They apply universally, to most systems. The issues described below
					are the most common (or otherwise critical).
				</p>
				<p>
					Dealing with these problems will most likely be handled by a separate project.
				</p>

				<h3 id="firmware-ec">EC (embedded controller) firmware <span class="r"><a href="#firmware-ec">#firmware-ec</a></span></h3>
					<p>
						Most (all?) laptops have this. The EC (embedded controller) is a small, separate processor that basically processes inputs/outputs
						that are specific to laptops. For example:
					</p>
						<ul class="c">
							<li>
								When you flick the radio on/off switch, the EC will enable/disable the wireless devices (wifi, bluetooth, etc) and enable/disable
								an LED that indicates whether it's turned on or not
							</li>
							<li>
								Listen to another chip that produces temperature readings, adjusting fan speeds accordingly (or turning the fan(s) on/off).
							</li>
							<li>
								Takes certain inputs from the keyboard, e.g. brightness up/down, volume up/down.
							</li>
							<li>
								Detect when the lid is closed or opened, and send a signal indicating this.
							</li>
							<li>
								Etc.
							</li>
						</ul>
					<p>
						Alexander Couzens from coreboot (lynxis on coreboot IRC) is working on a free EC firmware replacement for the ThinkPads
						that are supported in libreboot. See: <a href="https://github.com/lynxis/h8s-ec">https://github.com/lynxis/h8s-ec</a> (not ready yet).
					</p>
					<p>
						Most (all?) chromebooks have free EC firmware. Libreboot is currently looking into supporting a few ARM-based chromebooks.
					</p>
					<p>
						EC is only present on laptops. On desktop/server boards it is absent (not required).
					</p>
					<p>
						<a href="#pagetop">Back to top of page</a>
					</p>

				<h3 id="firmware-hddssd">HDD/SSD firmware <span class="r"><a href="#firmware-hddssd">#firmware-hddssd</a></span></h3>
					<p>
						HDDs and SSDs have firmware in them, intended to handle the internal workings of the device while exposing a simple,
						standard interface (such as AHCI/SATA) that the OS software can use, generically. This firmware is transparent to the user
						of the drive.
					</p>
					<p>
						HDDs and SSDs are quite complex, and these days contain quite complex hardware which is even capable of running an entire
						operating system (by this, we mean that the drive itself is capable of running its own embedded OS), even GNU/Linux
						or BusyBox/Linux.
					</p>
					<p>
						SSDs and HDDs are a special case, since they are persistent storage devices as well as computers.
					</p>
					<p>
						Example attack that malicious firmware could do: substitute your SSH keys, allowing unauthorized remote access by an unknown
						adversary. Or maybe substitute your GPG keys. SATA drives can also have DMA (through the controller), which means that they could read
						from system memory; the drive can have its own hidden storage, theoretically, where it could read your LUKS keys and store them
						unencrypted for future retrieval by an adversary.
					</p>
					<p>
						With proper IOMMU and use of USB instead of SATA, it might be possible to mitigate any DMA-related issues that could arise.
					</p>
					<p>
						Some proof of concepts have been demonstrated. For HDDs:<br/>
						<a href="https://spritesmods.com/?art=hddhack&page=1">https://spritesmods.com/?art=hddhack&amp;page=1</a><br/>
						For SSDs:<br/>
						<a href="http://www.bunniestudios.com/blog/?p=3554">http://www.bunniestudios.com/blog/?p=3554</a>
					</p>
					<p>
						Viable free replacement firmware is currently unknown to exist. For SSDs, the <a href="http://www.openssd-project.org/wiki/The_OpenSSD_Project">OpenSSD</a> project may be interesting.
					</p>
					<p>
						Apparently, SATA drives themselves don't have DMA but can make use of it through the controller.
						This <a href="http://www.lttconn.com/res/lttconn/pdres/201005/20100521170123066.pdf">http://www.lttconn.com/res/lttconn/pdres/201005/20100521170123066.pdf</a> (pages
						388-414, 420-421, 427, 446-465, 492-522, 631-638) and this <a href="http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1_3.pdf">http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1_3.pdf</a> (pages 59, 67, 94, 99).
					</p>
					<p>
						The following is based on discussion with Peter Stuge (CareBear\) in the coreboot IRC channel on Friday, 18 September 2015,
						when investigating whether the SATA drive itself can make use of DMA. The following is based on the datasheets linked above:
					</p>
					<p>
						&lt;CareBear\&gt; francis7 : so FIS type 39h is "DMA Activate FIS - Device to Host", which sounds interesting<br/>
						&lt;CareBear\&gt; &quot;transfer of data from the host to the device&quot;<br/>
						&lt;CareBear\&gt; &quot;Upon receiving a DMA Activate, if the host adapter’s DMA controller has been programmed and armed, the host adapter shall initiate the transmission of a Data FIS and shall transmit in this FIS the data corresponding to the host memory regions indicated by the DMA controller’s context.&quot;<br/>
						&lt;CareBear\&gt; FIS is a protocol unit, frame information structure<br/>
						&lt;CareBear\&gt; so it seems that a drive can tell the host controller that it would like for DMA to happen, but actually unless the host software has already or will in the future set up this DMA transfer then nothing happens<br/>
						&lt;CareBear\&gt; oh, but the drive can also send DMA Setup<br/>
						&lt;CareBear\&gt;if a DMA Setup FIS is sent first, with the Auto-Activate bit set, then it is already set up, and the drive can initiate DMA<br/>
						&lt;CareBear\&gt; &quot;First party DMA is a superset capability not neccessarily supported by legacy mode devices or legacy mode device drivers but essential for accommodating future capabilities.&quot; translation: if the problem isn't already there it will be shortly<br/>
						&lt;CareBear\&gt; &quot;Upon receiving a DMA Setup, the receiver of the FIS shall validate the received DMA Setup request&quot; - ie. the host is supposed to validate, but hey, maybe there's a bug there..<br/>
						&lt;CareBear\&gt; &quot;The specific implementation of the buffer identifier and buffer/address validation is not specified.&quot; - so noone will actually bother<br/>
						&lt;Basstard`&gt; &quot;the receiver of the FIS&quot;<br/>
						&lt;CareBear\&gt; in the case we're considering that's the host controller hardware in the chipset and/or the kernel driver<br/>
						&lt;CareBear\&gt; most likely kernel driver<br/>
						&lt;CareBear\&gt; francis7 : all SATA devices have flash-upgradeable firmware<br/>
						That last part is important. The firmware can be upgraded from the OS.<br/>
						&lt;CareBear\&gt; the harddrive is a nice computer-in-the-computer because it also has persistent storage<br/>
						Regarding USB:<br/>
						&lt;CareBear\&gt; then the attack surface becomes much smaller, but assuming a malicious harddrive then it can still try to get angry with the operating system<br/>
						&lt;CareBear\&gt; a usb drive can e.g. send malformed USB descriptors (how the PS3 was broken)<br/>
						(he's talking about so-called 'fuzzing' attacks)
					</p>
					<p>
						Based on this, it's safe to say that use of USB instead of SATA is advisable if security is a concern. USB 2.0 has plenty of bandwidth for many HDDs (a few high-end ones
						can use more bandwidth than USB 2.0 is capable of),
						but for SSDs it might be problematic (unless you're using USB 3.0, which is not yet usable in freedom. See <a href="#firmware-usbhost">#firmware-usbhost</a>).
					</p>
					<p>
						Other links:
					</p>
						<ul class="c">
							<li><a href="http://motherboard.vice.com/read/the-nsas-undetectable-hard-drive-hack-was-first-demonstrated-a-year-ago">http://motherboard.vice.com/read/the-nsas-undetectable-hard-drive-hack-was-first-demonstrated-a-year-ago</a></li>
						</ul>
					<p>
						It is recommended that you use full disk encryption, on HDDs connected via USB. There are several adapters available
						online, that allow you to connect SATA HDDs via USB. Libreboot documents how to install several GNU/Linux distributions
						with full disk encryption. You can adapt these for use with USB drives:
					</p>
						<ul class="c">
							<li><a href="../docs/gnulinux/encrypted_trisquel.html">Full disk encryption with Trisquel GNU/Linux</a></li>
							<li><a href="../docs/gnulinux/encrypted_parabola.html">Full disk encryption with Parabola GNU/Linux</a></li>
						</ul>
					<p>
						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>
					</p>
					<p>
						<a href="#pagetop">Back to top of page</a>
					</p>

				<h3 id="firmware-nic">NIC (ethernet controller) <span class="r"><a href="#firmware-nic">#firmware-nic</a></span></h3>
					<p>
						Ethernet NICs will typically run firmware inside, which is responsible for initializing the device internally.
						Theoretically, it could be configured to drop packets, or even modify them.
					</p>
					<p>
						With proper IOMMU, it might be possible to mitigate the DMA-related issues.
						A USB NIC can also be used, which does not have DMA.
					</p>
					<p>
						<a href="#pagetop">Back to top of page</a>
					</p>

				<h3 id="firmware-cpu">CPU microcode <span class="r"><a href="#firmware-cpu">#firmware-cpu</a></span></h3>
					<p>
						Implements an instruction set. See <a href="#microcode">#microcode</a> for a brief description.
						Here we mean microcode built in to the CPU. We are not talking about the updates supplied by the boot firmware
						(libreboot does not include microcode updates, and only supports systems that will work without it)
						Microcode can be very powerful. No proof that it's malicious, but it could theoretically
					</p>
					<p>
						There isn't really a way to solve this, unless you use a CPU which does not have microcode.
						(ARM CPUs don't, but most ARM systems require blobs for the graphics hardware at present, and typically
						have other things like soldered wifi which might require blobs)
					</p>
					<p>
						CPUs often on modern systems have a processor inside it for things like power management.
						ARM for example, has lots of these.
					</p>
					<p>
						<a href="#pagetop">Back to top of page</a>
					</p>

				<h3 id="firmware-sound">Sound card <span class="r"><a href="#firmware-sound">#firmware-sound</a>)</h3>
					<p>
						Sound hardware (integrated or discrete) typically has firmware on it (DSP) for processing input/output.
						Again, a USB DAC is a good workaround.
					</p>
					<p>
						<a href="#pagetop">Back to top of page</a>
					</p>

				<h3 id="firmware-webcam">Web cam <span class="r"><a href="#firmware-webcam">#firmware-webcam</a></h3>
					<p>
						Webcams have firmware integrated into them that process the image input into the camera; adjusting focus,
						white balancing and so on. Can use USB webcam hardware, to work around potential DMA issues; integrated webcams
						(on laptops, for instance) are discouraged by the libreboot project.
					</p>
					<p>
						<a href="#pagetop">Back to top of page</a>
					</p>

				<h3 id="firmware-usbhost">USB host controller <span class="r"><a href="#firmware-usbhost">#firmware-usbhost</a></span></h3>
					<p>
						Doesn't really apply to current libreboot systems (none of them have USB 3.0 at the moment), but
						USB 3.0 host controllers typically rely on firmware to implement the XHCI specification. Some newer
						coreboot ports also require this blob, if you want to use USB 3.0.
					</p>
					<p>
						This doesn't affect libreboot at the moment, because all current systems that are supported only
						have older versions of USB available. USB devices also don't have DMA (but the USB host controller itself does).
					</p>
					<p>
						With proper IOMMU, it might be possible to mitigate the DMA-related issues (with the host controller).
					</p>
					<p>
						<a href="#pagetop">Back to top of page</a>
					</p>
				<h3 id="firmware-wwan">WWAN firmware <span class="r"><a href="#firmware-wwan">#firmware-wwan</a></span></h3>
					<p>
						Some laptops might have a simcard reader in them, with a card for handling WWAN, connecting to a 3g/4g (e.g. GSM) network.
						This is the same technology used in mobile phones, for remote network access (e.g. internet).
					</p>
					<p>
						NOTE: not to be confused with wifi. Wifi is a different technology, and entirely unrelated.
					</p>
					<p>
						The baseband processor inside the WWAN chip will have its own embedded operating system, most likely proprietary. Use of this
						technology also implies the same privacy issues as with mobile phones (remote tracking by the GSM network, by triangulating the signal).
					</p>
					<p>
						On some laptops, these cards use USB (internally), so won't have DMA, but it's still a massive freedom and privacy issue.
						If you have an internal WWAN chip/card, the libreboot project recommends that you disable and (ideally, if possible) physically
						remove the hardware. If you absolutely must use this technology, an external USB dongle is much better because it can be
						easily removed when you don't need it, thereby disabling any external entities from tracking your location.
					</p>
					<p>
						Use of ethernet or wifi is recommended, as opposed to mobile networks, as these are generally much safer.
					</p>
					<p>
						On all current libreboot laptops, it is possible to remove the WWAN card and sim card if it exists. The WWAN card is next to the wifi card, and the
						sim card (if installed) will be in a slot underneath the battery, or next to the RAM.
					</p>
					<p>
						<a href="#pagetop">Back to top of page</a>
					</p>

	</div>

	<div>
		<h1>Operating Systems</h1>
			<h2 id="gnulinux">Can I use GNU/Linux? <span class="r"><a href="#gnulinux">#gnulinux</a></span></h2>
				<p>
					Absolutely! GNU/Linux is well-tested in libreboot, and highly recommended.
					See <a href="../docs/gnulinux/grub_boot_installer.html">installing GNU/Linux</a> and <a href="../docs/gnulinux/grub_cbfs.html">booting GNU/Linux</a>.
				</p>
				<p>
					Any recent distribution should work, as long as it uses KMS (kernel mode setting) for the graphics.
				</p>
				<p>
					The <a href="https://fsf.org/">Free Software Foundation</a> maintains
					a <a href="https://gnu.org/distros/free-distros.html">list of free GNU/Linux distributions</a>, certified
					to distribute and endorse <a href="https://www.gnu.org/philosophy/free-sw.html">free software</a>, exclusively.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="gnuhurd">Can I use GNU/Hurd? <span class="r"><a href="#gnuhurd">#gnuhurd</a></span></h2>
				<p>
					Unknown. Probably not. Feel free to try it, and report your findings.
				</p>
				<p>
					<a href="https://www.gnu.org/software/hurd/hurd.html">GNU Hurd</a> is a microkernel developed by
					the <a href="https://gnu.org/">GNU project</a>, and was (still is) intended to be the kernel for the
					GNU operating system. For historical reasons, <a href="https://kernel.org/">Linux</a> became the primarily
					adopted kernel (the libreboot project urges everyone to install and use <a href="http://www.fsfla.org/ikiwiki/selibre/linux-libre/">linux-libre</a> on their GNU systems),
					and was adapted for use with the GNU system. This is <a href="https://www.gnu.org/gnu/why-gnu-linux.html">why</a> we
					say <a href="https://www.gnu.org/gnu/linux-and-gnu.en.html">GNU/Linux</a>. Read the <a href="https://www.gnu.org/gnu/gnu-linux-faq.html">GNU/Linux FAQ</a>.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="bsd">Can I use BSD? <span class="r"><a href="#bsd">#bsd</a></span></h2>
				<p>
					BSD systems require a full Video BIOS, which libreboot lacks (there is a free replacement
					on all current systems, but it lacks certain features that GNU/Linux doesn't require).
					Translation: X11 won't work in BSD.
				</p>
				<p>
					It may be possible to get a serial console, but beyond that, BSD is useless on libreboot systems.
				</p>
				<p>
					For the most part, BSD systems remain untested in libreboot.
					BSD systems <a href="https://www.gnu.org/distros/common-distros.html">contain blobs</a>, so do beware.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="windows">Can I use Windows? <span class="r"><a href="#windows">#windows</a></span></h2>
				<p>
					Windows is incompatible with libreboot, and will probably remain so. <a href="https://gnu.org/philosophy/malware-microsoft.html">Never use Windows</a>.
				</p>
				<p>
					Windows incompatibility is a feature, not a bug.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>

			<h2 id="otheros">Are other operating systems compatible? <span class="r"><a href="#otheros">#otheros</a></span></h2>
				<p>
					Unknown. Probably not.
				</p>
				<p>
					<a href="#pagetop">Back to top of page</a>
				</p>
	</div>

<?php
	include "../common/footer.php";
?>

</body>
</html>
<?php
	$strHtml = ob_get_clean();
	echo miniHtml($strHtml);
?>