On 06/22/2011 03:02 PM, Matthew Garrett wrote: > http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed > feature for F16. We've traditionally had a hard objection to the > functionality because it required either the distribution or downloading > of binary code that ran on the host CPU, but it seems that there'll > shortly be systems that incorporate the appropriate sinit blob in their > BIOS, which is a boundary we've traditionally been fine with. Such systems supposedly exist today. I haven't tested them, but I believe a number of the newer Dell systems already have the required northbridge code in flash. tboot will use the binary northbridge setup blob that may be passed to it or it will try to use any blobs built into the flash if it isn't given a blob by grub. In the case that it doesn't have the magic blob needed to set up the CPU and northbridge it just won't execute the magic SENTER instruction. magic! > However, this is the kind of feature that has a pretty significant > impact on the distribution as a whole. I actually think this is completely wrong. It shouldn't have ANY distro wide impact at all. > Fesco decided that we should > probably have a broader discussion about the topic. The most obvious > issues are finding a sensible way to incorporate this into Anaconda, but > it's also then necessary to make sure that bootloader configuration is > updated appropriately. Agreed. These are exactly the parts that they need to do development. Anaconda shouldn't really need changes, tboot is just a package that needs installed. I'm not sure why that's even a part of the feature request. If anaconda creates the initial grub.conf it might need some work but that is the same issue as the next question. Grubby is what needs discussion and new code. It will need to detect tboot is installed and handle new grub type entries correctly. I haven't seen any code for this, but handling new formats of grub entries is what is really needed here. > Outside that, is there any other impact? There shouldn't be. Mind you if you want this to be useful for something it's going to take more steps and layers on top, but just booting into a measured launch environment should require no other steps. > Does tboot perform any > verification of the kernels, and if so how is that configured? tboot does no such thing. By default tboot and the Intel Trusted Execution Technology do nothing but measure and record information in a reliable, immutable, verifiable way. If one were to create and install a launch control policy into their own TPM (using the lcp tools) then that policy would be enforced at boot. But this is not and should not be a part of this feature request. The TPM key management required to update the lcp on kernel update just doesn't exist today in a practical way. Instead what we get from this is that tboot will 'measure', aka take a cryptographic hash of the kernel and initrd, and put those into the TPM before it launches the kernel. Thus after the kernel starts there is a method to verify that the hardware was in a known safe state and to verify what the kernel's hash was at launched. > Is the > expectation that an install configured with TXT will only boot trusted > kernels, NO NO NO NO NO. ANY mechanism that prevents users from using their own system will require MANUAL intervention on the part of the user. It's possible to build such a box yourself, but If such a change is ever suggested it should (and will be immediately by me) rejected. > and if so what mechanism is used to verify the kernel? tboot + the Intel Trusted Execution Technology hardware are what's used to measure and launch the kernel. If a launch control policy is configured it will be used to decide if such a kernel should be launched. But there is NO way we should (or even could) EVER automatically create an lcp. > Is there > any further integration work that has to be performed for this to be > useful? So much you cannot imagine :) At the moment they are just try to get a system which is capable of measuring itself. We already have kernel functionality which can measure any files being accessed, but we have no way to know what kernel was launched? What good is a list of files if you can't trust the guy creating that list? This gets us that last step, we have a way to know the state of the system and the cryptographic hash representing the contents of the kernel (and initrd) which was launched. We don't have a way to USE this data. Red Hat has some long term goals on how to use this functionality in the enterprise and the gov't has some ideas how to use it in their super secret intelligence world. Nothing about this should be a default. Nothing about this should affect users who don't turn it on. Nothing about this should lock people out of their own computers. Does this help? -Eric -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
