From: Cihula, J. <jos...@in...> - 2009-01-12 17:19:30
|
> From: Hal Finney [mailto:hal...@gm...] > Sent: Wednesday, January 07, 2009 2:49 PM > > >> From: Hal Finney [mailto:hal...@gm...] > >> Sent: Tuesday, January 06, 2009 7:26 PM > >> > >> There is one aspect of tboot security which I always wondered about. > >> Maybe someone could reassure me that it is OK. > >> > >> Shouldn't the MLE check to see that the page tables are/were set up > >> correctly? > > On Tue, Jan 6, 2009 at 11:25 PM, Cihula, Joseph <jos...@in...> wrote: > > > > This has been on my todo list for a while now but I haven't gotten to it yet (it *is* > covered in the MLE Developers Manual, however). Now that I just finished a few patches (and > one more to come that requires Xen support), I should be able to knock this out pretty soon. > > I would like to see a document which lists known security flaws like > this in tboot. It might help to reduce claims that "Intel TXT is > broken" and the like. Do you know of other security loopholes which > are planned for closure in future versions? I'll work on creating a TODO list for tboot, which will include the implications/impact of the items and also will include functional tasks. These are the TODO items that I know of that have security implications: 1. Verification of post-launch physical memory layout (see above). A patch is ready and being reviewed. 2. VT-d protections extended to all of usable memory. The current tboot setting for VT-d (PMR) DMA protection is just the tboot address range, which leaves out Xen, dom0, etc. as well as where they are relocated to before Xen enables VT-d DMA remapping. A patch is ready and being reviewed. 3. S3 memory integrity protection. The non-tboot TCB (and possibly more) needs to have its integrity measured before entering S3 and verified on resume. For Xen, this would be the hypervisor and that would be responsible for doing this for domains (including dom0). A patch is ready and being reviewed. 4. Validation of Sx addresses. We are adding GAS (generic address structure) support to tboot's Sx code. GAS allows for non-port -based Sx triggering (i.e. memory writes). This allows for the possibility that malicious ACPI code (or tampered with before tboot) could reference addresses within Xen or tboot and cause overwrites when a sleep state is entered. So the addresses should be checked against tboot/Xen/domain addr ranges before being used. This is part of the GAS support patch, which is ready and being reviewed. 5. Run tboot code through a static analysis checker. 6. Perform a thorough tboot code and design review on latest code. There are also some things that are not directly related to tboot, but are really only relevant if tboot is being used: 1. Review all Xen code for pre-launch dependencies. This would be things like the GAS issue mentioned above, BIOS calls (which should all be disabled when invoked by tboot), etc. 2. Ensure Xen fails secure. This would include things like the 'iommu=required' and 'ats' command line parameters that we had added. Joe |