[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091204171333.GS18989@one.firstfloor.org>
Date: Fri, 4 Dec 2009 18:13:33 +0100
From: Andi Kleen <andi@...stfloor.org>
To: "Cihula, Joseph" <joseph.cihula@...el.com>
Cc: 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>, "H. Peter Anvin" <hpa@...or.com>,
"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
"andi@...stfloor.org" <andi@...stfloor.org>,
"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
> "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.
> > > > checksummed by tboot, attacker may be able to hijack code execution
> > > > and bypass your protection, no?
> > > Yes, kernel code is audited by tboot before resume.
> >
> > So no, you did not audit do_suspend_lowlevel to make sure it does not
> > follow function pointers. Bad.
>
> We aren't aware of any code or data used by the resume path that is outside of the tboot-MAC'ed regions above--if you can point out any then we will gladly address them.
Code coverage is not enough, you need data coverage too. If someone
modifies kernel data it's typically easy to subvert code as a next step.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only.
--
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