Messages in this thread | | | Subject | RE: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted ExecutionTechnologysupport for Linux - Overview | Date | Thu, 9 Oct 2008 14:16:14 -0700 | From | "Cihula, Joseph" <> |
| |
> From: Pavel Machek [mailto:pavel@suse.cz] > Sent: Thursday, October 09, 2008 11:46 AM > > > > > > You exit/reenter the trusted mode accross sleep... so any guarantees > > > > > "trusted" mode does are void, right? > > > > > > > > You exit from kernel to tboot on any shutdown, which handles the proper > > > > teardown of the measured env (meaning you also come back on via tboot). > > > > So things like saving tpm state, scrubbing secrets from memory, etc. > > > > > > Aha, so instead sleep mode is useless because I'll have to remount all > > > the crypto filesystems and restart all the apps... > > > > Sleep mode works the same as it does today (caveat S4 issue which we > > will fix), it just goes through the tboot code before putting the > > platform HW into the appropriate state. What this process is adding is > > that on resume, tboot will get control from BIOS instead of the kernel. > > Then tboot will re-launch the TXT environment before going back to the > > kernel at the kernel's expected S3 resume vector. The re-establishing > > of the protected environment won't disrupt the subsequent kernel resume > > process. > > No, I don't get it. So presumably useful thing to do is to seal my > crypto partition so that only known-good kernel can access it? > > But then, the crypto keys will be in ram during suspend/resume > (because I have the filesystem mounted) => I loose any guarantees?
This goes to the threat model for S3. The current code assumes that the S3 resume process is trusted. That is, the memory image will not be compromised between the time tboot turns off TXT in order to put the platform into S3 and the time TXT is re-launched. For this model, the purpose of re-launching is to re-establish the original PCR values and the reset protection.
If stronger protection is desired, the apps that manage keys would need to seal the keys to the current DRTM PCRs and then clear the plaintext copies, before the system enters S3. The tboot and Linux code would also need to put a (U)MAC over all of the image (the kernel could UMAC userspace and tboot would UMAC the kernel). The UMAC that tboot calculates would get sealed before entry into S3 and then unsealed and validated upon resume. OF course this adds time to both entry and resume.
Joe
| |