[GIT PULL] x86/txt for v2.6.32

[GIT PULL] x86/txt for v2.6.32

[H. Peter Anvin]

The following changes since commit 326ba5010a5429a5a528b268b36a5900d4ab0eba:
  Linus Torvalds (1):
        Linux 2.6.31-rc8

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-txt-for-linus

Arnaldo Carvalho de Melo (1):
      x86, intel_txt: Fix typos in Kconfig help

H. Peter Anvin (3):
      x86, intel_txt: tboot.c needs <asm/fixmap.h>
      x86, intel_txt: Factor out the code for S3 setup
      x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE

Ingo Molnar (1):
      Merge commit 'v2.6.31-rc8' into x86/txt

Joseph Cihula (4):
      x86, intel_txt: Intel TXT boot support
      x86, intel_txt: Intel TXT reboot/halt shutdown support
      x86, intel_txt: Intel TXT Sx shutdown support
      intel_txt: Force IOMMU on for Intel TXT launch

Shane Wang (1):
      x86, intel_txt: clean up the impact on generic code, unbreak non-x86

 Documentation/intel_txt.txt      |  210 ++++++++++++++++++
 Documentation/x86/zero-page.txt  |    1 +
 arch/x86/Kconfig                 |    4 +
 arch/x86/include/asm/bootparam.h |    3 +-
 arch/x86/include/asm/fixmap.h    |    3 +
 arch/x86/kernel/Makefile         |    1 +
 arch/x86/kernel/reboot.c         |    7 +
 arch/x86/kernel/setup.c          |    3 +
 arch/x86/kernel/smpboot.c        |    2 +
 arch/x86/kernel/tboot.c          |  447 ++++++++++++++++++++++++++++++++++++++
 drivers/acpi/acpica/hwsleep.c    |    3 +
 drivers/pci/dmar.c               |    7 +
 drivers/pci/intel-iommu.c        |   17 ++-
 include/linux/tboot.h            |  162 ++++++++++++++
 kernel/cpu.c                     |    1 +
 security/Kconfig                 |   30 +++
 16 files changed, 898 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/intel_txt.txt
 create mode 100644 arch/x86/kernel/tboot.c
 create mode 100644 include/linux/tboot.h

Re: [GIT PULL] x86/txt for v2.6.32

[Pavel Machek]

Hi!

>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-txt-for-linus
> 
> Arnaldo Carvalho de Melo (1):
>       x86, intel_txt: Fix typos in Kconfig help
> 
> H. Peter Anvin (3):
>       x86, intel_txt: Factor out the code for S3 setup
>       x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE

This went in despite my NAK/request for more info. It seems you are
simply ignoring feedback you don't like :-(

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [GIT PULL] x86/txt for v2.6.32

[Rafael J. Wysocki]

On Saturday 26 September 2009, Pavel Machek wrote:
> Hi!
> 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-txt-for-linus
> > 
> > Arnaldo Carvalho de Melo (1):
> >       x86, intel_txt: Fix typos in Kconfig help
> > 
> > H. Peter Anvin (3):
> >       x86, intel_txt: Factor out the code for S3 setup
> >       x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE
> 
> This went in despite my NAK/request for more info. It seems you are
> simply ignoring feedback you don't like :-(

The "x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE" commit looks
entirely correct to me.

I have no comments on "x86, intel_txt: Factor out the code for S3 setup" as
well, maybe except that the BUG() in tboot_setup_sleep() in the
!CONFIG_ACPI_SLEEP case is a bit unfortunate.

Thanks,
Rafael

Re: [GIT PULL] x86/txt for v2.6.32

[Pavel Machek]

On Sat 2009-09-26 23:44:21, Rafael J. Wysocki wrote:
> On Saturday 26 September 2009, Pavel Machek wrote:
> > Hi!
> > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-txt-for-linus
> > > 
> > > Arnaldo Carvalho de Melo (1):
> > >       x86, intel_txt: Fix typos in Kconfig help
> > > 
> > > H. Peter Anvin (3):
> > >       x86, intel_txt: Factor out the code for S3 setup
> > >       x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE
> > 
> > This went in despite my NAK/request for more info. It seems you are
> > simply ignoring feedback you don't like :-(
> 
> The "x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE" commit looks
> entirely correct to me.
> 
> I have no comments on "x86, intel_txt: Factor out the code for S3 setup" as
> well, maybe except that the BUG() in tboot_setup_sleep() in the
> !CONFIG_ACPI_SLEEP case is a bit unfortunate.

Well, I worry that S3 support for TXT makes TXT completely useless. A
little liquid nitrogen, remove RAM, place it in another machine,
modify it in any way you want, more liquid nitrogen, place it back.

Oops, protection provided by TXT is lost.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [GIT PULL] x86/txt for v2.6.32

[Rafael J. Wysocki]

On Monday 28 September 2009, Pavel Machek wrote:
> On Sat 2009-09-26 23:44:21, Rafael J. Wysocki wrote:
> > On Saturday 26 September 2009, Pavel Machek wrote:
> > > Hi!
> > > 
> > > >   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-txt-for-linus
> > > > 
> > > > Arnaldo Carvalho de Melo (1):
> > > >       x86, intel_txt: Fix typos in Kconfig help
> > > > 
> > > > H. Peter Anvin (3):
> > > >       x86, intel_txt: Factor out the code for S3 setup
> > > >       x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE
> > > 
> > > This went in despite my NAK/request for more info. It seems you are
> > > simply ignoring feedback you don't like :-(
> > 
> > The "x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE" commit looks
> > entirely correct to me.
> > 
> > I have no comments on "x86, intel_txt: Factor out the code for S3 setup" as
> > well, maybe except that the BUG() in tboot_setup_sleep() in the
> > !CONFIG_ACPI_SLEEP case is a bit unfortunate.
> 
> Well, I worry that S3 support for TXT makes TXT completely useless. A
> little liquid nitrogen, remove RAM, place it in another machine,
> modify it in any way you want, more liquid nitrogen, place it back.
> 
> Oops, protection provided by TXT is lost.

Ah, I see your point now.

Thanks,
Rafael

Re: [GIT PULL] x86/txt for v2.6.32

[H. Peter Anvin]

On 09/28/2009 02:07 PM, Rafael J. Wysocki wrote:
>>
>> Well, I worry that S3 support for TXT makes TXT completely useless. A
>> little liquid nitrogen, remove RAM, place it in another machine,
>> modify it in any way you want, more liquid nitrogen, place it back.
>>
>> Oops, protection provided by TXT is lost.
> 
> Ah, I see your point now.
> 

Shane Wang sent me a patch for S3 support, but it missed the merge window:

	http://marc.info/?i=4A9CE0B2.5060608@intel.com

*As far as I understand* -- and I haven't looked into it in detail yet,
having just come back from Plumber's -- this provides integrity
protection, not content extraction protection.

Shane, could you please comment?

Thanks,

	-hpa

Re: [GIT PULL] x86/txt for v2.6.32

[Pavel Machek]

On Mon 2009-09-28 14:11:25, H. Peter Anvin wrote:
> On 09/28/2009 02:07 PM, Rafael J. Wysocki wrote:
> >>
> >> Well, I worry that S3 support for TXT makes TXT completely useless. A
> >> little liquid nitrogen, remove RAM, place it in another machine,
> >> modify it in any way you want, more liquid nitrogen, place it back.
> >>
> >> Oops, protection provided by TXT is lost.
> > 
> > Ah, I see your point now.
> > 
> 
> Shane Wang sent me a patch for S3 support, but it missed the merge window:
> 
> 	http://marc.info/?i=4A9CE0B2.5060608@intel.com
> 
> *As far as I understand* -- and I haven't looked into it in detail yet,
> having just come back from Plumber's -- this provides integrity
> protection, not content extraction protection.

How does it provide integrity protection? I'm free to modify RAM
content in the other machine....
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [GIT PULL] x86/txt for v2.6.32

[Shane Wang]

Pavel Machek wrote:
> On Mon 2009-09-28 14:11:25, H. Peter Anvin wrote:
>> On 09/28/2009 02:07 PM, Rafael J. Wysocki wrote:
>>>> Well, I worry that S3 support for TXT makes TXT completely useless. A
>>>> little liquid nitrogen, remove RAM, place it in another machine,
>>>> modify it in any way you want, more liquid nitrogen, place it back.
>>>>
>>>> Oops, protection provided by TXT is lost.
>>> Ah, I see your point now.
>>>
>> Shane Wang sent me a patch for S3 support, but it missed the merge window:
>>
>> 	http://marc.info/?i=4A9CE0B2.5060608@intel.com
>>
>> *As far as I understand* -- and I haven't looked into it in detail yet,
>> having just come back from Plumber's -- this provides integrity
>> protection, not content extraction protection.
> 
> How does it provide integrity protection? I'm free to modify RAM
> content in the other machine....
> 									Pavel

Hi Pavel,

Before S3 sleep, tboot patch will MAC the memory, and after S3 resume, the 
memory integrity will be verified according to the MAC value. So, you can't 
modify RAM, or else you will fail on S3 resume.

The current patch hpa mentioned is for userspace memory integrity. For kernel 
memory integrity, the code is already in with the previous txt patch.

Thanks.
Shane

Re: [GIT PULL] x86/txt for v2.6.32

[Pavel Machek]

On Tue 2009-09-29 14:34:09, Shane Wang wrote:
> Pavel Machek wrote:
>> On Mon 2009-09-28 14:11:25, H. Peter Anvin wrote:
>>> On 09/28/2009 02:07 PM, Rafael J. Wysocki wrote:
>>>>> Well, I worry that S3 support for TXT makes TXT completely useless. A
>>>>> little liquid nitrogen, remove RAM, place it in another machine,
>>>>> modify it in any way you want, more liquid nitrogen, place it back.
>>>>>
>>>>> Oops, protection provided by TXT is lost.
>>>> Ah, I see your point now.
>>>>
>>> Shane Wang sent me a patch for S3 support, but it missed the merge window:
>>>
>>> 	http://marc.info/?i=4A9CE0B2.5060608@intel.com
>>>
>>> *As far as I understand* -- and I haven't looked into it in detail yet,
>>> having just come back from Plumber's -- this provides integrity
>>> protection, not content extraction protection.

Well, documentation seems to suggest it provides content protection,
too. If not, should that be clearly documented in Doc*/intel_txt?
[Also, I'd expect threat model aka "what does it protect against there"].

>> How does it provide integrity protection? I'm free to modify RAM
>> content in the other machine....

>
> Before S3 sleep, tboot patch will MAC the memory, and after S3 resume, 
> the memory integrity will be verified according to the MAC value. So, you 
> can't modify RAM, or else you will fail on S3 resume.
>
> The current patch hpa mentioned is for userspace memory integrity. For 
> kernel memory integrity, the code is already in with the previous txt 
> patch.

Ok, and what prevents me from commenting out the MAC checking code?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [GIT PULL] x86/txt for v2.6.32

[Arjan van de Ven]

On Tue, 29 Sep 2009 19:13:18 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> Ok, and what prevents me from commenting out the MAC checking code?
> 

because the bios verified some code that verified the kernel which
includes the MAC checking code .. as part of returning from S3 ?

> 							

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

RE: [GIT PULL] x86/txt for v2.6.32

[Wang, Shane]

Arjan van de Ven wrote:
> On Tue, 29 Sep 2009 19:13:18 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
>> Ok, and what prevents me from commenting out the MAC checking code?
>> 
> 
> because the bios verified some code that verified the kernel which
> includes the MAC checking code .. as part of returning from S3 ?

Yes, S3 sleep/resume cause another cycle to build the measured environment.
i.e. SINIT will verify tboot, tboot will verify kernel mem, kernel will verify userspace mem.
If you comment out the MAC checking code in any party, the chain will lost and S3 resume will fail.

Thanks.
Shane

Re: [GIT PULL] x86/txt for v2.6.32

[Pavel Machek]

On Wed 2009-09-30 10:16:55, Wang, Shane wrote:
> Arjan van de Ven wrote:
> > On Tue, 29 Sep 2009 19:13:18 +0200
> > Pavel Machek <pavel@ucw.cz> wrote:
> > 
> >> Ok, and what prevents me from commenting out the MAC checking code?
> >> 
> > 
> > because the bios verified some code that verified the kernel which
> > includes the MAC checking code .. as part of returning from S3 ?
> 
> Yes, S3 sleep/resume cause another cycle to build the measured environment.
> i.e. SINIT will verify tboot, tboot will verify kernel mem, kernel will verify userspace mem.
> If you comment out the MAC checking code in any party, the chain will lost and S3 resume will fail.
> 

Ok, that means that you are protecting integrity but not secrecy?
Should that be written down in documentation, along with threat model?

So I modify the RAM content so that BIOS does not think measured
environment existed before suspend?
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [GIT PULL] x86/txt for v2.6.32

[Wang, Shane]

> So I modify the RAM content so that BIOS does not think measured
> environment existed before suspend?
> 									Pavel

Hi Pavel, what do you mean on this question? 
When do you modify the RAM? before S3 sleep?

Thanks.
Shane

Re: [GIT PULL] x86/txt for v2.6.32

[H. Peter Anvin]

On 10/02/2009 10:02 AM, Wang, Shane wrote:
>> So I modify the RAM content so that BIOS does not think measured
>> environment existed before suspend?
>> 									Pavel
> 
> Hi Pavel, what do you mean on this question? 
> When do you modify the RAM? before S3 sleep?
> 

He was talking earlier about a liquid nitrogen freeze attack.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [GIT PULL] x86/txt for v2.6.32

[Henrique de Moraes Holschuh]

On Fri, 02 Oct 2009, H. Peter Anvin wrote:
> On 10/02/2009 10:02 AM, Wang, Shane wrote:
> >> So I modify the RAM content so that BIOS does not think measured
> >> environment existed before suspend?
> > 
> > Hi Pavel, what do you mean on this question? 
> > When do you modify the RAM? before S3 sleep?
> > 
> 
> He was talking earlier about a liquid nitrogen freeze attack.

You wish one would need liquid nitrogen for it... frozen CO2 (dry ice) is
more than cold enough for such an attack, and _MUCH_ easier to both acquire
and handle than liquid nitrogen.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [GIT PULL] x86/txt for v2.6.32

[Pavel Machek]

On Sat 2009-10-03 01:02:52, Wang, Shane wrote:
> > So I modify the RAM content so that BIOS does not think measured
> > environment existed before suspend?
> > 									Pavel
> 
> Hi Pavel, what do you mean on this question? 
> When do you modify the RAM? before S3 sleep?

During the sleep, using something cold and second machine.
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [GIT PULL] x86/txt for v2.6.32

[Henrique de Moraes Holschuh]

On Sat, 03 Oct 2009, Pavel Machek wrote:
> On Sat 2009-10-03 01:02:52, Wang, Shane wrote:
> > > So I modify the RAM content so that BIOS does not think measured
> > > environment existed before suspend?
> > > 									Pavel
> > 
> > Hi Pavel, what do you mean on this question? 
> > When do you modify the RAM? before S3 sleep?
> 
> During the sleep, using something cold and second machine.

And it is ridiculously easy to pull off, too:
http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-effective/

Shows the attack being used to read sensitive keys, but you can use it also
to *modify* system running state (it will be more difficult, as you need to
remove and replace the RAM while on S3 instead of S5, but it should be
doable by someone who knows what he is doing).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [GIT PULL] x86/txt for v2.6.32

[Roland Dreier]

 > > > So I modify the RAM content so that BIOS does not think measured
 > > > environment existed before suspend?

 > And it is ridiculously easy to pull off, too:
 > http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-effective/
 > 
 > Shows the attack being used to read sensitive keys, but you can use it also
 > to *modify* system running state (it will be more difficult, as you need to
 > remove and replace the RAM while on S3 instead of S5, but it should be
 > doable by someone who knows what he is doing).

I believe the whole point of this TXT / S3 handling is that the resume
from S3 will then be able to detect that the contents of RAM have been
modified while the system was asleep.

TXT simply produces a reasonably trustworthy measurement of system
state.  If you modify RAM while the system is asleep, then you will not
be able to produce a measurement showing an unmodified system state.

 - R.

Re: [GIT PULL] x86/txt for v2.6.32

[Arjan van de Ven]

On Sat, 3 Oct 2009 17:36:20 -0300
Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:

> On Sat, 03 Oct 2009, Pavel Machek wrote:
> > On Sat 2009-10-03 01:02:52, Wang, Shane wrote:
> > > > So I modify the RAM content so that BIOS does not think measured
> > > > environment existed before suspend?
> > > > 									Pavel
> > > 
> > > Hi Pavel, what do you mean on this question? 
> > > When do you modify the RAM? before S3 sleep?
> > 
> > During the sleep, using something cold and second machine.
> 
> And it is ridiculously easy to pull off, too:
> http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-effective/
> 
> Shows the attack being used to read sensitive keys, but you can use
> it also to *modify* system running state (it will be more difficult,
> as you need to remove and replace the RAM while on S3 instead of S5,
> but it should be doable by someone who knows what he is doing).
> 

that assumes all state is in ram, and not some bit in the TPM..

(and as for that "we can steal the content"... that's confusing DRM
with TXT. TXT is integrity, DRM is. well evil ;-)


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [GIT PULL] x86/txt for v2.6.32

[Henrique de Moraes Holschuh]

On Sat, 03 Oct 2009, Arjan van de Ven wrote:
> On Sat, 3 Oct 2009 17:36:20 -0300
> Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> > On Sat, 03 Oct 2009, Pavel Machek wrote:
> > > On Sat 2009-10-03 01:02:52, Wang, Shane wrote:
> > > > > So I modify the RAM content so that BIOS does not think measured
> > > > > environment existed before suspend?
> > > > > 									Pavel
> > > > 
> > > > Hi Pavel, what do you mean on this question? 
> > > > When do you modify the RAM? before S3 sleep?
> > > 
> > > During the sleep, using something cold and second machine.
> > 
> > And it is ridiculously easy to pull off, too:
> > http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-effective/
> > 
> > Shows the attack being used to read sensitive keys, but you can use
> > it also to *modify* system running state (it will be more difficult,
> > as you need to remove and replace the RAM while on S3 instead of S5,
> > but it should be doable by someone who knows what he is doing).
> 
> that assumes all state is in ram, and not some bit in the TPM..

Indeed, it does.

> (and as for that "we can steal the content"... that's confusing DRM
> with TXT. TXT is integrity, DRM is. well evil ;-)

Agreed :)  But TXT itself (or the BIOS, but not the kernel) needs to recheck
RAM content signatures on resume.  Does it?  If it doesn't, it is easy to
"fix" too, just drop all previous atestation before suspend/restart/shutdown
:P

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [GIT PULL] x86/txt for v2.6.32

[Pavel Machek]

On Sat 2009-10-03 13:44:22, Roland Dreier wrote:
> 
>  > > > So I modify the RAM content so that BIOS does not think measured
>  > > > environment existed before suspend?
> 
>  > And it is ridiculously easy to pull off, too:
>  > http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-effective/
>  > 
>  > Shows the attack being used to read sensitive keys, but you can use it also
>  > to *modify* system running state (it will be more difficult, as you need to
>  > remove and replace the RAM while on S3 instead of S5, but it should be
>  > doable by someone who knows what he is doing).
> 
> I believe the whole point of this TXT / S3 handling is that the resume
> from S3 will then be able to detect that the contents of RAM have been
> modified while the system was asleep.

...and you are able to read out any keys, etc. Maybe that's expected &
ok, but Doc*/intel_txt.txt does not actually tell me what it protects
against and is pretty much useless... making patches impossible to
review.

So... what does txt protect?

Data integrity only?

Data privacy, too?

Who is it designed to protect against?

Remote attacker?

Local user trying to subvert it?

...and has soldering iron he's willing to use?

...and has soldering iron, osciloscope and PCI analyzer he's willing to use?

> TXT simply produces a reasonably trustworthy measurement of system
> state.  If you modify RAM while the system is asleep, then you will not
> be able to produce a measurement showing an unmodified system state.

Well, actually I see some auditing to be done in proposed patches.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [GIT PULL] x86/txt for v2.6.32

[Cihula, Joseph]

> From: Pavel Machek [mailto:pavel@ucw.cz]
> Sent: Tuesday, October 06, 2009 1:13 AM
>
> On Sat 2009-10-03 13:44:22, Roland Dreier wrote:
> >
> >  > > > So I modify the RAM content so that BIOS does not think measured
> >  > > > environment existed before suspend?
> >
> >  > And it is ridiculously easy to pull off, too:
> >  > http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-
> effective/
> >  >
> >  > Shows the attack being used to read sensitive keys, but you can use it also
> >  > to *modify* system running state (it will be more difficult, as you need to
> >  > remove and replace the RAM while on S3 instead of S5, but it should be
> >  > doable by someone who knows what he is doing).
> >
> > I believe the whole point of this TXT / S3 handling is that the resume
> > from S3 will then be able to detect that the contents of RAM have been
> > modified while the system was asleep.
>
> ...and you are able to read out any keys, etc. Maybe that's expected &
> ok, but Doc*/intel_txt.txt does not actually tell me what it protects
> against and is pretty much useless... making patches impossible to
> review.
>
> So... what does txt protect?

>From Documentation/intel_txt.txt:
        Intel TXT in Brief:
        o  Provides dynamic root of trust for measurement (DRTM)
        o  Data protection in case of improper shutdown
        o  Measurement and verification of launched environment

Intel TXT doesn't protect anything itself--it provides a foundation for software to provide protections and security.  tboot and the associated Linux patches do this.  The section of intel_txt.txt titled "Value Proposition for Linux or "Why should you care?"" tries to describe what is provided.

> Data integrity only?

Data integrity, yes, but not only.  The code also provides for DRTM-based measurements, data protection in case of improper shutdown, etc.

> Data privacy, too?

No.

> Who is it designed to protect against?
>
> Remote attacker?

Yes.

> Local user trying to subvert it?

No.

> ...and has soldering iron he's willing to use?
>
> ...and has soldering iron, osciloscope and PCI analyzer he's willing to use?

No and no.

> > TXT simply produces a reasonably trustworthy measurement of system
> > state.  If you modify RAM while the system is asleep, then you will not
> > be able to produce a measurement showing an unmodified system state.
>
> Well, actually I see some auditing to be done in proposed patches.

All comments are welcome.

Joe

Re: [GIT PULL] x86/txt for v2.6.32

[Pavel Machek]

Hi!

> > >  > Shows the attack being used to read sensitive keys, but you can use it also
> > >  > to *modify* system running state (it will be more difficult, as you need to
> > >  > remove and replace the RAM while on S3 instead of S5, but it should be
> > >  > doable by someone who knows what he is doing).
> > >
> > > I believe the whole point of this TXT / S3 handling is that the resume
> > > from S3 will then be able to detect that the contents of RAM have been
> > > modified while the system was asleep.
> >
> > ...and you are able to read out any keys, etc. Maybe that's expected &
> > ok, but Doc*/intel_txt.txt does not actually tell me what it protects
> > against and is pretty much useless... making patches impossible to
> > review.
> >
> > So... what does txt protect?
> 
> >From Documentation/intel_txt.txt:
>         Intel TXT in Brief:
>         o  Provides dynamic root of trust for measurement (DRTM)
>         o  Data protection in case of improper shutdown
>         o  Measurement and verification of launched environment
> 
> Intel TXT doesn't protect anything itself--it provides a foundation for software to provide protections and security.  tboot and the associated Linux patches do this.  The section of intel_txt.txt titled "Value Proposition for Linux or "Why should you care?"" tries to describe what is provided.
> 
> > Data integrity only?
> 
> Data integrity, yes, but not only.  The code also provides for DRTM-based measurements, data protection in case of improper shutdown, etc.
> 
> > Data privacy, too?
> 
> No.

So why does it protect data "in case of improper shutdown"?

> > Who is it designed to protect against?
> >
> > Remote attacker?
> 
> Yes.

Existing mechanisms should be adequate to protect against then.

> > Local user trying to subvert it?
> 
> No.

Then again, why does it protect data "in case of improper shutdown"?

> > > TXT simply produces a reasonably trustworthy measurement of system
> > > state.  If you modify RAM while the system is asleep, then you will not
> > > be able to produce a measurement showing an unmodified system state.
> >
> > Well, actually I see some auditing to be done in proposed patches.
> 
> All comments are welcome.

Well, without detailed design goals, comments are pretty much
impossible. Please improve Documentation/intel_txt.txt to explain what
it protects, and against who.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html