MBR vs GPT, BIOS and UEFI, Secureboot...what's "the best" combo for a Linux only box?

[Feathers McGraw]

A new laptop is on the way. I'm planning on completely removing Windows 8 and having a GNU/Linux only machine.

So, I'll have the luxury of choosing my setup. Most of the Ubuntu documentation on UEFI focuses on working around what's already there... but there's no discussion of what's best if you can choose.

GPT seems to be better than MBR for large disks and multiple partitions, but i'm not sure about the rest.

E.g. is secureboot actually useful, or is it just a PITA with Linux?

Please share your nuggets of wisdom!

Thanks,

Feathers

[richb]

I did the same wiped Windows and installed Kubuntu on my laptop. I disabled secure boot, in which I could see no useful value.

[SteveRiley]

My suggestions.

• Keep your firmware in UEFI mode. Take the time to learn it. UEFI is the future; the more people who know this, the better off everyone will be. UEFI has many advantages over BIOS.
• Use GPT rather than MBR. The distinction between primary and extended partitions goes away, and partition/drive size limits are practically non-problems now.
• Disable Secure Boot. It creates a complex layer of hardware-software integration that is cumbersome to maintain and does very little to protect J. Random PCUser from the kinds of attacks s/he is likely to see.
• Install the EFI shell into /boot/efi/EFI/boot. Google for the latest EFI shell version 2. The shell exposes the full miniature operating system that is UEFI. Very cool.

[woodsmoke]

This is a VERY interesting thread Feathers! I hope that others will contribute!

woodsmoke

[Feathers McGraw]

Thanks guys, some useful suggestions and info.

Install the EFI shell into /boot/efi/EFI/boot. Google for the latest EFI shell version 2. The shell exposes the full miniature operating system that is UEFI. Very cool.

Pretty much all I can find on the EFI shell is this:

UEFI Shell

The UEFI Shell is a shell/terminal for the firmware which allows launching UEFI applications which include UEFI bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), running partitioning programs (diskpart), loading UEFI drivers, editing text files (edit), hexedit etc. You can download a BSD licensed UEFI Shell from Intel's Tianocore EDK2 Sourceforge.net project.

x86_64 UEFI Shell (Beta)

x86_64 UEFI Shell (Old)

i386 UEFI Shell (Beta)

i386 UEFI Shell (Old)

Use the Beta Shell. If it doesn't work use the Old shell. Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called Launch EFI Shell from filesystem device . For those motherboards, download the x86_64 UEFI Shell and copy it to you EFI SYSTEM PARTITION as <EFI_SYSTEM_PARTITION>/shellx64.efi (mostly /boot/efi/shellx64.efi) .

What's the benefit of using UEFI shell rather than the standard Linux utilities to get system information and partition disks?

Is the UEFI shell something that you add after installation, or so you specify some specific options during installation?

Feathers

[SteveRiley]

Unlike BIOS, UEFI is a complete pre-boot environment. The UEFI shell presents a command line that allows you to directly explore and manipulate the firmware. It is completely independent of any installed operating system. If you like to tinker with your PC, the UEFI shell is a good thing to have.

I'd also strongly encourage you to ditch GRUB and use rEFInd as your boot manager. Rod Smith, the rEFInd maintainer, has written extensively about UEFI and also provided a copy of a recently-compiled UEFI 2.0 shell that works on machines with UEFI versions earlier than 2.3.1. I needed this because my laptop is UEFI 2.0.1. The existing binary shells are all too old. You'll want to use this one, too.

[Buddlespit]

I've yet to see a benefit to using rEFInd over GRUB2-EFI. Both are boot managers, GRUB2 is also a boot loader. Both can boot multiple OS's. Both can use really pretty graphical boot menus. GRUB2 also has a GUI config installed in my System Settings.

I had installed and used rEFInd for about a month before I decided that GRUB2 did everything I could do with rEFInd.

[SteveRiley]

The advantage is that it just works straight away. GRUB 2 is complex, finicky, and prone to packaging errors. Many of the dual-boot problems that plague several Linux distributions are related in some way to weird GRUB configurations. Rod discusses these problems on his site.

The Linux kernel is now a self-contained boot loader, as is the Windows kernel. Thus, no separate boot loaders are required. One only needs a boot manager to select from the multiple boot-loadable kernels present on the machine. GRUB tries to do too much: it implements its own boot loader, controlled by its own boot manager. It has a partition addressing scheme that is not like Linux or Windows. It has its own graphics driver modes that sometimes fail on certain UEFI-based hardware. It doesn't boot other operating systems but instead chain loads the boot loader of your chosen operating system. It relies on a pile of scripts that require per-distribution customization to work. GRUB is a great big hack that was necessary in the days of BIOS and non-boot-loadable kernels. Those days are over.

rEFInd automatically locates all bootable kernels for Linux, Mac, and Windows on all available partitions and presents them in a menu. You pick the one you want, and UEFI boots the chosen operating system directly. You can control the menu appearance and OS detection logic via /boot/efi/EFI/refind/refind.conf, but there's likely no reason to change things unless you want to, say, switch from graphical to text mode boot (I do this). You can pass kernel parameters in /boot/refind_linux.conf. And that's all you need to do. Quite elegant, really.

[Snowhog]

Too bad that rEFInd is written/works only on machines the have UEFI hardware. Could it be 'ported' to non-UEFI PCs?

[SteveRiley]

Alas, no. The entire point of rEFInd is to offer a simplified boot manager that relies on UEFI's ability to directly start an operating system's boot loader. BIOS-based machines have no similar capability, that's why these machines need an intermediate boot loader step provided by the likes of GRUB, LILO, etc.

[GreyGeek]

rEFInd sounds intriguing, Steve, but the UEFI part still concerns me. Matthew Garrat wrote, a couple years ago, that

Matthew Garrett ... believes that Intel's UEFI reference implementation, codenamed Tiano and upon which hardware vendors' UEFI implementations will be based, is bloated and buggy.
...
Some vendors' UEFI implementations have bugs that are so bad that they won't even install Windows via UEFI, let alone Linux.
"It indicates that nobody ever tested this code at all, ever," Garrett said.
...
UEFI doesn't specify the format the keys have to be in, nor the naming convention or the firmware's under interface.
"A vendor could require that [the keys] be in ROT-13 Base-64 ... To get into secure boot [and disable it] you need to get into your firmware, which requires you to hit a key on your keyboard, we're not sure which," Garrett said.
"Once you've done that and got into your firmware you're then going to need to find a menu which might be called 'Security', which might be called 'Boot', which might be called 'Advanced', which might be called 'Beware of the leopard'."


And apart form that, turning off secure boot defeats one of UEFI's primary goals: making bootkit malware impossible.

It turns out that even with Secure Boot turned on bootkits are possible because of how different vendors implement UEFI specifications differently. It seems vendors are doing sloppy work, which is why a German agency sees security problems because:

In addition, there is collaboration between Microsoft and antimalware software vendors at an “early launch antimalware” (ELAM) stage of the boot process that enables antimalware vendors to check the boot loader firmware.
...
Microsoft has denied that it provides back-door access to the U.S. government via its software. It claims to only respond to requests for specific data via legal demand. However, Snowden has asserted that NSA analysts require no legal process to tap Internet traffic using PRISM, contradicting Microsoft’s claims. Snowden’s leaked documents showed that Microsoft was the very first service provider to sign up for participation in the NSA’s PRISM program.

A couple months before it purchased Skype Microsoft patented its "Legal Intercept" software, which it later deployed on the Linux server farms it created to replace the Skype p2p "supernodes" that were previously used to serve traffic. "Legal Intercept" allows someone at or connected to the servers in the farm to monitor Skype communications. Apparently the encryption is placed on the traffic after the interception.

The recently released information also contained details that Microsoft cooperated with the FBI in providing insights on how to undercut the e-mail alias feature in Outlook.com.


The Guardian also reported that the integration of the Skype voice-over-IP telephony service into the Prism program started as far back as November 2010, before Microsoft's acquisition of the Luxembourg-based company. In February 2011, Skype received a signed directive from the attorney general to comply. Microsoft announced its plans to purchase of Skype in May 2011.


Speaking on the issue of consumer privacy, ACLU technology expert Chris Soghoian told the Guardian that Microsoft's involvement with Prism directly goes against its commitment to user privacy made on the Skype Web site. "In the past, Skype made affirmative promises to users about their inability to perform wiretaps," said Soghoian to the newspaper. "It's hard to square Microsoft's secret collaboration with the NSA with its high-profile efforts to compete on privacy with Google."

The person speaking for the German Agency referred to the TPM on Win8 as an "NSA Wet Dream". Indeed.

AG Holder directed Skype to comply with NSA requests. Pres. Obama defended NSA spying on Americans.

So, basically, because EUFI implementation is so vendor dependent, and the vendors appear to be extremely careless, using UEFI appears to be a hit or miss affair. Sort of like Linux back in 1992!

And if that isn't enough, consider that two years ago a Chinese tech company bragged:

The claim was made at a conference held in Dubai in February by officials with the Chinese firm Huawei Technologies Co. Ltd., and left specialists who attended the seminar alarmed.
They told WND that’s because while Huawei may consider the data “malicious,” the act of intercepting and extracting data means the Chinese company also could steal sensitive information or even alter the function of computer systems where the company’s products are installed.

Huawei, which is tied to the Chinese People’s Liberation Army, displayed in a PowerPoint-type presentation that it had capabilities in “in-depth traffic analysis to enhance network control,” which a source to WND who attended the conference said meant that it could intercept data and collect it.

[SteveRiley]

I hope you realize that BIOS is no longer used on machines these days. Everything comes with UEFI. You can push most of this into the background by running in BIOS compatibility mode, which results in a non-UEFI-aware operating system installation. But you can't completely eliminate UEFI unless you're willing to reprogram the firmware on your motherboard.

UEFI has come a long way since Garrett's video. No soft|firmware is ever bug-free, of course. Legacy BIOS had its share of bugs. UEFI will also have bugs. This is no reason to stick one's head in the sand

UEFI has many advantages over BIOS, as I've chronicled variously here at KFN. Remember, too, that I also advocate disabling Secure Boot. I recognize I'm in the minority by taking this position, and it's one of the few points of disagreement I have with Garrett. I just don't think Secure Boot is a necessary technology to protect home and small business users from the kinds of attacks they're most likely to encounter.

[Feathers McGraw]

I've done some reading on rEFInd and it looks elegant, I'd definitely like to try it.

The installation instructions are written for systems with an OS already installed. Should I use a live USB to install rEFInd, then install Kubuntu, or do a normal install (which will probably install GRUB) and then install rEFInd and remove GRUB?

[SteveRiley]

Do a normal install. Then install rEFInd. After that, remove all traces of GRUB. Finally, you'll need to tell APT to ignore all boot managers. The Ubuntu kernels are packaged such that GRUB and/or LILO are recommended dependencies. If GRUB is not on your system, future updates will bring it back. To prevent this, create the file /etc/apt/preferences.d/no-boot-loaders:

Package: grub*
Pin: version 0.0
Pin-Priority: -1

Package: grub*:i386
Pin: version 0.0
Pin-Priority: -1

Package: lilo
Pin: version 0.0
Pin-Priority: -1

Package: lilo:i386
Pin: version 0.0
Pin-Priority: -1

Package: os-prober
Pin: version 0.0
Pin-Priority: -1

Package: os-prober:i386
Pin: version 0.0
Pin-Priority: -1

[Feathers McGraw]

Thanks! I'll let you know how that goes when I get the laptop