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
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
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
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
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
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/[email protected]
*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
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/[email protected]
>
> *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
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/[email protected]
>>
>> *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
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/[email protected]
>>>
>>> *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
On Tue, 29 Sep 2009 19:13:18 +0200
Pavel Machek <[email protected]> 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
Arjan van de Ven wrote:
> On Tue, 29 Sep 2009 19:13:18 +0200
> Pavel Machek <[email protected]> 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
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 <[email protected]> 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
> 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-
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.
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
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
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
> > > 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.
On Sat, 3 Oct 2009 17:36:20 -0300
Henrique de Moraes Holschuh <[email protected]> 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
On Sat, 03 Oct 2009, Arjan van de Ven wrote:
> On Sat, 3 Oct 2009 17:36:20 -0300
> Henrique de Moraes Holschuh <[email protected]> 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
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
> From: Pavel Machek [mailto:[email protected]]
> 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
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