All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: "Cihula, Joseph" <joseph.cihula@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>, Pavel Machek <pavel@ucw.cz>,
	"Wang, Shane" <shane.wang@intel.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
	"arjan@linux.intel.com" <arjan@linux.intel.com>,
	"chrisw@sous-sol.org" <chrisw@sous-sol.org>,
	"jmorris@namei.org" <jmorris@namei.org>,
	"jbeulich@novell.com" <jbeulich@novell.com>,
	"peterm@redhat.com" <peterm@redhat.com>
Subject: Re: [PATCH] intel_txt: add s3 userspace memory integrity verification
Date: Fri, 4 Dec 2009 21:31:43 +0100	[thread overview]
Message-ID: <20091204203143.GC741@basil.fritz.box> (raw)
In-Reply-To: <4F65016F6CB04E49BFFA15D4F7B798D9AEDDD710@orsmsx506.amr.corp.intel.com>

> > 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.

That was actually wrong, since you're coming back from S3
udelay should work. nm.

> 
> 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?

At least classical vga/serial early_printk should be safe, I'm not sure
about the early USB code recently added though, some auditing on that
first would be good.

early_printk defaults to VGA text output, so if you do a reset you would
need a delay first, otherwise noone can see it ever. But one could be
done with udelay()

It'll be also invisible with frame buffer active, which is the common
case for distributions.  So basically in most cases the message would be
invisible.

(not that panic is much better by default in this regard though,
at least not without Jesse's recent frame buffer work ...)

-Andi


-- 
ak@linux.intel.com -- Speaking for myself only.

  reply	other threads:[~2009-12-04 20:31 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-01  8:52 [PATCH] intel_txt: fix the build errors of intel_txt patch on non-X86 platforms (resend) Shane Wang
2009-09-27  9:07 ` [PATCH] intel_txt: add s3 userspace memory integrity verification Shane Wang
2009-09-29  2:27   ` [PATCH] intel_txt: fix the buggy timeout warning logic in tboot Shane Wang
2009-10-04 18:58   ` [PATCH] intel_txt: add s3 userspace memory integrity verification Pavel Machek
2009-10-04 23:26     ` Andi Kleen
2009-10-15  7:57     ` Wang, Shane
2009-12-04  9:07     ` Wang, Shane
2009-12-04  8:19       ` Pavel Machek
2009-12-04 16:46         ` Cihula, Joseph
2009-12-04 17:13           ` Andi Kleen
2009-12-04 17:41             ` Cihula, Joseph
2009-12-04 20:09               ` Andi Kleen
2009-12-04 20:17                 ` Cihula, Joseph
2009-12-04 20:31                   ` Andi Kleen [this message]
2009-12-04 21:27                   ` H. Peter Anvin
2009-12-04 17:53             ` H. Peter Anvin
2009-12-04 20:10               ` Andi Kleen
2009-12-04 22:25               ` Pavel Machek
2009-12-04 22:15           ` Pavel Machek
2009-12-04 22:24             ` H. Peter Anvin
2009-12-04 22:39               ` Pavel Machek
2009-12-04 22:46                 ` H. Peter Anvin
2010-03-09  8:52     ` [PATCH v2] intel_txt: add support for S3 memory integrity protection within Intel(R) TXT launched kernel Wang, Shane
2010-03-09  9:06       ` Pavel Machek
2010-03-09  9:06       ` Pavel Machek
2010-03-10  6:36       ` [PATCH v3] " Shane Wang
2010-03-10  6:36         ` Shane Wang
2010-03-10 20:31         ` Rafael J. Wysocki
2010-03-10 20:31         ` Rafael J. Wysocki
2010-03-19 21:18         ` [tip:x86/txt] x86, tboot: Add support for S3 memory integrity protection tip-bot for Shane Wang
2010-03-09  8:52     ` [PATCH v2] intel_txt: add support for S3 memory integrity protection within Intel(R) TXT launched kernel Wang, Shane
  -- strict thread matches above, loose matches on Subject: below --
2009-12-04  9:12 [PATCH] intel_txt: add s3 userspace memory integrity verification Shane Wang
2009-12-04  8:29 ` Pavel Machek
2009-12-04  8:29 ` Pavel Machek
2009-12-04 16:52   ` Cihula, Joseph
2009-12-04 16:52   ` Cihula, Joseph
2009-12-04 22:20     ` Pavel Machek
2009-12-04 22:20     ` Pavel Machek
2009-12-04 11:05 ` Andi Kleen
2009-12-04 11:05 ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091204203143.GC741@basil.fritz.box \
    --to=andi@firstfloor.org \
    --cc=arjan@linux.intel.com \
    --cc=chrisw@sous-sol.org \
    --cc=hpa@zytor.com \
    --cc=jbeulich@novell.com \
    --cc=jmorris@namei.org \
    --cc=joseph.cihula@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --cc=peterm@redhat.com \
    --cc=rjw@sisk.pl \
    --cc=shane.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.