Secure boot and opensuse
There has been some discussion of secure boot in various forums on the internet. The basic idea is that newer hardware, with UEFI partition, allows secure boot. With secure boot, an operating system will not be allowed to boot unless it has a verifiable digital signature.
Related to this, Microsoft has insisted that it won’t certify hardware for use with Window 8, unless it supports secure boot. Some have seen this as a diabolical scheme by microsoft to assert monopoly control and lockout the use of linux. Other, calmer minds, have suggested that maybe secure boot is actually a good idea, even for linux. And that open source software users should be looking for ways to use secure boot instead of opening up a new front in the operating system religious wars.
In the unix world, Ubuntu and Fedora both have announced plans on how they intend handling the situation. And now SuSE has stepped up and announced its plans. It looks like the best plan yet, and will probably apply to both opensuse and enterprise SUSE.
The SUSE blog announcement: SUSE and Secure Boot: The Details
The opensuse forum announcement and discussion: SUSE details its Secure Boot plans
A quick overview
This may be a little oversimplified.
The secure boot operations in the computer would load a signed shim. Here a shim is, in essence, a small preloader which means that it is a program that runs before the operating system loader.
The shim in turn will verify the signature on the grub2 loader, then start grub2.
Next, grub2 will access additional signing keys on disk, and use those to verify the signature on the kernel that it loads to start linux.
With this arrangement, only the shim needs to be signed with a key known to the computer hardware/firmware. In the SUSE plans, SUSE will take care of getting the shim suitably signed. The shim will itself then recognize signing keys built into the shim, and use those to verify the grub2 loader. The next step, where grub2 accesses a pool of signing keys on disk, is what gives the system its flexibility. If you want to compile your own kernel, you can create your own signing key and add it to that disk pool of signing keys.
At least, that is my current understanding.