Messages in this thread | | | From | "Cihula, Joseph" <> | Date | Fri, 4 Dec 2009 12:17:42 -0800 | Subject | RE: [PATCH] intel_txt: add s3 userspace memory integrity verification |
| |
> From: Andi Kleen [mailto:andi@firstfloor.org] > Sent: Friday, December 04, 2009 12:10 PM > > On Fri, Dec 04, 2009 at 09:41:24AM -0800, Cihula, Joseph wrote: > > > From: Andi Kleen [mailto:andi@firstfloor.org] > > > Sent: Friday, December 04, 2009 9:14 AM > > > > > > > "bad stuff" would be the execution of any code (or use of any data that affects > execution) > > > that was not verified by tboot. As long as panic() is within the code ranges MAC'ed by > tboot > > > (see above), it would be covered. Do you know of some panic() code paths that are outside > of > > > this? > > > > > > Not code path, but the code called by panic (console drivers, debuggers etc.) > > > can well use data that is stored >4GB > > > > > > This can include structures with indirect pointers, like notifier chains. > > > > > > Notifier chains have a special checker than can check > > > for <4GB, but there are other call vectors too. > > > > Since, as you pointed out in a previous email, it is doubtful that there will be any user- > visible output at this point, we can change this path to a tboot reset (which will give us > some serial output at least). Is it going to be similarly unsafe to do a printk()? > > Yes printk is similarly unsafe. It calls all the console machinery, > which has a lot of data. > > Perhaps early_printk(), that is relatively self contained, but doesn't > always work. > > Of course you would need to have a timeout before reset, and at this point the > delay loops are not calibrated yet, so you don't know how to wait.
I would expect that early_printk() coupled with tboot's serial output would be sufficient for a case such as this. If we've done our work correctly, loss of integrity should only occur when the system is attacked across the S3 transition--which should be fairly rare and which should place a premium on prevention of the attacked code from executing. Esp. on servers, there may not be anyone to see console output anyway. Does early_printk() and a tboot reset seem like a reasonable approach?
> > -Andi > > -- > ak@linux.intel.com -- Speaking for myself only.
| |