[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B197ED3.9060003@zytor.com>
Date: Fri, 04 Dec 2009 13:27:47 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: "Cihula, Joseph" <joseph.cihula@...el.com>
CC: Andi Kleen <andi@...stfloor.org>, Pavel Machek <pavel@....cz>,
"Wang, Shane" <shane.wang@...el.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
"chrisw@...s-sol.org" <chrisw@...s-sol.org>,
"jmorris@...ei.org" <jmorris@...ei.org>,
"jbeulich@...ell.com" <jbeulich@...ell.com>,
"peterm@...hat.com" <peterm@...hat.com>
Subject: Re: [PATCH] intel_txt: add s3 userspace memory integrity verification
On 12/04/2009 12:17 PM, Cihula, Joseph wrote:
>
> 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?
>
The zeroeth-order thing is you should reliably crash and reboot. This
is pretty normal for most S3 resume failures anyway, so although it is
somewhat unfortunate for debugging, it is isn't exactly an unreasonable
thing to do.
Getting a message out is a nice plus, but not a requirement.
Guaranteeing the integrity is an absolute requirement.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists