(Created page with '{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To rea...') |
No edit summary |
||
| Line 1: | Line 1: | ||
= Feature Name = | = Feature Name = | ||
Trusted Boot | Trusted Boot | ||
| Line 20: | Line 13: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/ | * Targeted release: [[Releases/12 | 12 ]] | ||
* Last updated: | * Last updated: July 21, 2009 | ||
* Percentage of completion: 00% | * Percentage of completion: 00% | ||
Revision as of 22:35, 21 July 2009
Feature Name
Trusted Boot
Summary
Ability for users to configure their system to make use of the TPM and hardware support in order to verify that the machine is running the intended kernel.
Owner
- Name: Eric Paris
- email: eparis@redhat.com
Current status
- Targeted release: 12
- Last updated: July 21, 2009
- Percentage of completion: 00%
Detailed Description
Most of the support for trusted boot already exists in Fedora but all of the pieces have never been put together. The goal of this feature is to allow users to boot a kernel, and after it is booted to know that the kernel they are running is the kernel they expected to have running.
Benefit to Fedora
Security minded users have no way of knowing if their kernel is the expected kernel. They have no way of knowing if the system under them has been trojaned. The point of this feature is to give users a method to verify that the system that booted was the system they expected to boot.
Scope
Changes are expected to be needed in grub, tpmutils, trousers, and possibly in the kernel configuration.
How To Test
At the moment testing isn't well defined. Ultimately tests will involve users with TPM enabled hardware to be able to verify the same kernel booted they expected or a different kernel booted than they expected.
User Experience
Noone will notice a change unless they specifically configure their system. There are no planned default changes.
Dependencies
The grub changes, and possibly the intel TXT support are requirements which I may not be able to control but which may cause the feature to fail to complete.
Contingency Plan
None necessary, if it doesn't work, it wasn't going to be default anyway. Users just won't be able to use it.
Documentation
- Nothing et.
Release Notes
- No good note yet as there is no documentation. There is no upstream.