phrostbyte wrote:well, for me, that's the whole issue. my computer came with windows 8 pre-installed (new toshiba satellite). that means that uefi and secureboot are enabled by default. I know how ubuntu handles secureboot, but I'd like to find out how the next version of LM will handle it. I'd prefer to install LM and keep secureboot enabled, but obviously I'll use whatever method works best
I don't know what the Mint architects have planned in that respect. At the moment, there seems to be some limited "piggybacking" off of Ubuntu's Secure Boot support, which follows a shim->GRUB->kernel authentication path, by using Ubuntu's kernels. Most users, however, disable Secure Boot entirely when installing Mint, since what Mint does seems to work poorly in practice.
More broadly speaking, to the best of my knowledge, only GRUB 2 and rEFInd fully support Secure Boot, in that they both work as follow-on boot programs from shim and they both honor Secure Boot limitations in launching kernels. This is valuable if you care about having the kernel continue to extend the chain of trust, which is something that Fedora is pushing heavily but that most other distributions (including Ubuntu) are less concerned about doing. If you don't care about extending the chain of trust up through the kernel, you could use shim to launch ELILO, GRUB Legacy, SYSLINUX, or something else and have it work, in the sense that the kernel would boot. The kernel would be unable to verify the authenticity of kernel modules, though. As a practical matter, I know of no actual exploits that involve malware masquerading as Linux kernel modules, but such an attack is theoretically possible, so there is merit to what Fedora is doing along these lines.
A special case in all this is gummiboot. Like rEFInd, gummiboot relies on the EFI to launch follow-on programs; but unlike rEFInd, gummiboot includes no explicit code to link in to the shim authentication services. This means that you can't use gummiboot with shim; if you try, your signed gummiboot will launch, but it in turn won't launch anything that isn't signed with a key that's built into the firmware, so it won't launch most Linux kernels. You can, however, use gummiboot with PreLoader, which provides its authentication tools by linking to the EFI so that PreLoader gets called as part of the standard Secure Boot checks. (This contrasts with shim, which requires that follow-on programs explicitly support it.) PreLoader is easier to set up than shim if you're starting from scratch, and some smaller and less-well-funded distributions (like Arch) use it; but it requires user action to register each boot loader (and sometimes each kernel), so it's more hassle for end users than if the distribution pays the $99 so that it can get its own customized version of shim to be signed.
This can be a lot to take in and there are a lot of subtleties involved, but I hope that this helps to introduce you to how different boot loaders and boot managers interact with Secure Boot.