flickertcb-devel — Development information

Re: [flickertcb-devel] Flicker unstable on most Linux/Intel machines?

[Steffen S. <pe...@gm...>]

Hi Justin,

On 120314 at 08:45, Justin King-Lacroix wrote:
> I've found that remounting the root filesystem read-only before the
> late-launch, and then remounting it read-write again afterwards, works
> around the filesystem corruption issue.

Can you do that in a standard installation? Maybe from within the
kernel? Here it aborts with "mount: / is busy", and other attempts like
xfs_freeze or hdparm -S did not help.

Disabling AHCI in the BIOS reduced the problem quite a bit, allowing us
to make many Flicker sessions before the system drops dead :-)

> On the network card issue, pulling the module before late-launch, and
> re-modprobing it after, achieves nothing.

Subjectively, problems with the e1000 got a lot better by upgrading to
the latest vanilla Linux. But working remotely (i.e.  having load on
the NIC) is still problematic, and wifi (iwlagn) will almost certainly
break after Flicker.

> whereas the network one feels like the IOMMU is left is a crazy state
> that blocks interrupts from the ethernet hardware.  (Of course,
> that's complete guesswork, so I could be totally off-base.)

Our NIC often continued to work a bit after Flicker if there was no
load on the interface, so I don't think its the IOMMU.

I found reports on improved libata error handling where they said that
ATA is very sensitive to synchronization problems.

Due to the load-dependency and randomness of errors, I think its
a general problem of not handling IRQs correctly and/or not properly
finishing ongoing DMA transactions.


I thought that S2RAM support in modern drivers and hardware should
address this problem, since similar things happen: The OS stops
operating for some time and has to put devices and drivers
in a state where they can be cleanly recovered from.

Looking at kernel/power/suspend.c, it looks like the right kind of
things are going on. CPUs are disabled, kernel threads halted, IRQs disabled.
Then there is an iterator over PCI devices that puts them to sleep, and
devices can ask their drivers to do some final cleanup work before
powering down.

However, I did not have the time to fully replicate that. Using that
PCI iterator appearantly correctly shut down PCI devices(screen blanked
out), but after wakeup the system was still borked. And we actually
needed to graphics card to do some work.. :-)

Here is a mostly still correct documentation of the suspend flow:
http://elinux.org/Pm_Sub_System#Internal_Sequence_of_System_PM

I also just saw that you can disable individual devices using that very
same PM facility, so that may be worth trying out:
http://elinux.org/Pm_Sub_System#Internal_Sequence_of_Device_PM



/steffen
-- 
System Security Lab                            web:  www.trust.cased.de
CASED / TU Darmstadt                           phone: +49 6151 16-75565
PGP Key Fingerprint = B805 57BE E4AF 0104 CC51 77A1 CE6F 8D46 A04D 7875

Re: [flickertcb-devel] help

[Bryan P. <pa...@mi...>]

Hi Justin,

If you connect a serial cable to your Flicker machine, you should be able to see some serial output from Flicker, if you’re making it there at all.  The code in asm.S outputs some (rather cryptic) characters over the serial port when Flicker first launches and when it’s resuming the kernel after running the app, so that might help you narrow down what’s causing the error.

You might also sanity check the kernel module output (e.g., via dmesg) to make sure nothing is going wrong during the preparation for the late launch.

-Bryan

From: Justin King-Lacroix [mailto:jus...@cs...]
Sent: Tuesday, March 06, 2012 10:31 AM
To: tbo...@li...; fli...@li...
Subject: [flickertcb-devel] help

Hi guys,

I want to write a Flicker application, but I'm finding that even the sample Flicker app causes a TXT-shutdown rather than running. I have no idea even how far it gets, though I'm fairly sure the MLE begins executing: TXT.ERRORCODE is 0x80000000, which is a processor-initiated #LegacyShutdown (a previous post on the Tboot mailing list suggests that this is indicative of an error occurring during MLE execution).
(TXT.ESTS is 1, which I believe means "TXT won't work again until a hardware reset".)

I'm using a vanilla Ubuntu 11.10 distribution on a Dell OptiPlex 780 (desktop-class C2Q system), with the latest SINIT module for this platform.

FWIW, I've previously used Tboot on this machine, and it worked flawlessly. (I'm not using Tboot currently, of course.)

Any ideas, pointers to useful debugging tools, or suggestions as to where to look would be greatly appreciated!

Regards,
Justin King-Lacroix
D.Phil student
Department of Computer Science
University of Oxford

Re: [flickertcb-devel] Flicker unstable on most Linux/Intel machines?

[Justin King-L. <jus...@cs...>]

Hi Steffen,

I'm getting this as well -- the Dell OptiPlex 780 I'm using has
serious disk and network stability issues: after a Flicker session,
the root filesystem driver gets very upset and remounts read-only (a
reboot reveals rampant, if minor, filesystem corruption, mostly
related to files written to immediately pre-late-launch); the ethernet
driver (e1000e) loses the ability to do useful work.

I've found that remounting the root filesystem read-only before the
late-launch, and then remounting it read-write again afterwards, works
around the filesystem corruption issue.
On the network card issue, pulling the module before late-launch, and
re-modprobing it after, achieves nothing.

My gut feeling says that they're related, but separate issues: the
disk one sounds like dropped interrupts resulting in disk write
transactions not completing correctly, whereas the network one feels
like the IOMMU is left is a crazy state that blocks interrupts from
the ethernet hardware.
(Of course, that's complete guesswork, so I could be totally off-base.)

My original feeling for working around the networking issue was to
somehow force Linux to take control of the IOMMU after the late
launch, and then release it again; basically the same idea as using
CPU hotplug to disable CPUs on the system and then re-enable them.
I can't work out how to do this though; the only method I've seen for
controlling Linux's use of the IOMMU is to pass intel_iommu=on on the
boot command line, which tells it to take control now and forever, and
of course makes TXT unusable.

</$0.02>

Justin King-Lacroix
D.Phil student
Department of Computer Science
University of Oxford



On Tue, Mar 13, 2012 at 11:31 PM, Steffen Schulz <pe...@gm...> wrote:
> On 120307 at 16:30, Steffen Schulz wrote:
>> While working on a research prototype based on Flicker, we noticed that
>> Flicker seems to unstable on most of the Laptops and PCs we tested.
>>
>> [..]
>>
>> Did anyone else observe this or are we doing something wrong?
>
>
> Is there nobody who has had some experience with hardware/driver
> hickups after returning from a Flicker PAL? No ideas how to fix this?
>
>
> /steffen
> --
> System Security Lab                            web:  www.trust.cased.de
> CASED / TU Darmstadt                           phone: +49 6151 16-75565
> PGP Key Fingerprint = B805 57BE E4AF 0104 CC51 77A1 CE6F 8D46 A04D 7875
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> flickertcb-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flickertcb-devel

Re: [flickertcb-devel] Flicker unstable on most Linux/Intel machines?

[Jonathan M. <jon...@cm...>]

Hi Steffen,

> Is there nobody who has had some experience with hardware/driver
> hickups after returning from a Flicker PAL? No ideas how to fix this?

I'm aware of the problem and beginning to bring some resources to bear
on it.  It's challenging for me to predict a completion time, but I at
least expect to generate a lot more chatter on this list regarding the
problems.

Best,
-Jon

Re: [flickertcb-devel] Flicker unstable on most Linux/Intel machines?

[Steffen S. <pe...@gm...>]

On 120307 at 16:30, Steffen Schulz wrote:
> While working on a research prototype based on Flicker, we noticed that
> Flicker seems to unstable on most of the Laptops and PCs we tested.
>
> [..]
> 
> Did anyone else observe this or are we doing something wrong?


Is there nobody who has had some experience with hardware/driver
hickups after returning from a Flicker PAL? No ideas how to fix this?


/steffen
-- 
System Security Lab                            web:  www.trust.cased.de
CASED / TU Darmstadt                           phone: +49 6151 16-75565
PGP Key Fingerprint = B805 57BE E4AF 0104 CC51 77A1 CE6F 8D46 A04D 7875

[flickertcb-devel] Flicker unstable on most Linux/Intel machines?

[Steffen S. <pe...@gm...>]

Hi,


While working on a research prototype based on Flicker, we noticed that
Flicker seems to unstable on most of the Laptops and PCs we tested.

We tested different Dell Optiplex and Lenovo Laptops and found only one
particular Intel machine, a Lenovo T420 4180-N92, to work flawlessly.
Unless Wifi is active during the Flicker session..

The errors we observe on all platforms all appear to follow the same
pattern: After returning from the Flicker session, the Linux drivers or
even hardware subsystems seem to be in an inconsistent state. The LAN
and WLAN drivers print error messages and either fail or manage to
recover after some time. Most critical are the ATA drivers, which
report read errors or inconsistent device state and usually fail after
some time. In some cases the FS also becomes damaged, ext4 often beyond
repair.


Did anyone else observe this or are we doing something wrong?

Are there any ideas on how to solve these issues or who to talk to?


I was thinking about using the suspend-to-ram functionality of most
recent platforms to put drivers and hardware to sleep during the Flicker
session. Did anyone try this?


Thanks,
Steffen
-- 
System Security Lab                            web:  www.trust.cased.de
CASED / TU Darmstadt                           phone: +49 6151 16-75565
PGP Key Fingerprint = B805 57BE E4AF 0104 CC51 77A1 CE6F 8D46 A04D 7875

[flickertcb-devel] help

[Justin King-L. <jus...@cs...>]

Hi guys,

I want to write a Flicker application, but I'm finding that even the sample
Flicker app causes a TXT-shutdown rather than running. I have no idea even
how far it gets, though I'm fairly sure the MLE begins executing:
TXT.ERRORCODE is 0x80000000, which is a processor-initiated #LegacyShutdown
(a previous post on the Tboot mailing list suggests that this is indicative
of an error occurring during MLE execution).
(TXT.ESTS is 1, which I believe means "TXT won't work again until a
hardware reset".)

I'm using a vanilla Ubuntu 11.10 distribution on a Dell OptiPlex 780
(desktop-class C2Q system), with the latest SINIT module for this platform.

FWIW, I've previously used Tboot on this machine, and it worked flawlessly.
(I'm not using Tboot currently, of course.)

Any ideas, pointers to useful debugging tools, or suggestions as to where
to look would be greatly appreciated!

Regards,
Justin King-Lacroix
D.Phil student
Department of Computer Science
University of Oxford

Re: [flickertcb-devel] PAL size

[Bryan P. <pa...@mi...>]

Hi Steve,

If you take a look at kmod/flicker.h, there are constants defining the maximum size of the PAL, inputs, and outputs.  At the moment, you get 128 4K pages for the PAL, a bit less than 29 pages for input and 28 pages for output.  You can adjust these a bit, but you need to understand what you're doing, since there are some non-obvious dependencies.  The Flicker code already takes care of hashing the rest the code and data, but if you're worried about DMA attacks, then you may need to extend the device exclusion vector yourself -- we currently rely on the protections that are setup by the late launch.

Hope this helps!

-Bryan

> -----Original Message-----
> From: Steve Johnston [mailto:ste...@ad...]
> Sent: Thursday, February 23, 2012 12:57 PM
> To: fli...@li...
> Subject: [flickertcb-devel] PAL size
> 
> Hi all,
> 
> Are there any bounds of how big (or small) pal.bin must be?  I would
> like to play around and try adding functionality and am curious if there
> are size constraints I must consider.
> 
> Steve
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> flickertcb-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flickertcb-devel

[flickertcb-devel] PAL size

[Steve J. <ste...@ad...>]

Hi all,

Are there any bounds of how big (or small) pal.bin must be?  I would
like to play around and try adding functionality and am curious if there
are size constraints I must consider.

Steve

Re: [flickertcb-devel] Flicker Freezes After Running PAL

[Jonathan M. <jon...@cm...>]

Hi David,

> Since my original message, we added some more printk calls to our module to
> see if we could trace the problem.  Interestingly, it did not freeze.  The
> only change was to add those printk calls -- the other functionality is
> unchanged.  We then ran our earlier code that was freezing before, and it
> still froze.  So now we have two copies, they differ only in their number of
> printk calls -- the one with more printk calls works, the other does not.

Hmm.  Two possibilities that come to mind are: (1) some kind of memory
corruption bug that ends up doing damage in one case, but not the
other; and (2) some kind of race with a device interrupt that the OS
kernel / device driver is not handling gracefully.

Unfortunately case (2) is still a reality with the current code base.
No effort is currently made to "quiesce" devices, and all
devices/drivers are not created equal when it comes to tolerating what
amounts to strange freezes on the main processor.  At the moment I
don't have a work-around for this, though it is something we're
planning to address in the future.  It is hard for me to give a
timeline any more fine-grained than "a year or so".

> I also took note of the "gibberish" you pointed out. It  was identical to
> the version that froze.  I also looked at that some line from our demo PAL
> module, and it was also identical.  So all three modules have the same
> "gibberish".

Well, that's a necessary but not sufficient condition for success. :-/

> Finally, from tracing the debug statements in the flicker kernel module
> output, it appears the computer is freezing near where the module is
> supposed to be unloaded.

I've seen this before, but so far we haven't had time to debug it.  If
you or anybody else is an expert on the Linux scheduler, I'd love to
chat.

Regards,
-Jon

Re: [flickertcb-devel] Flicker Freezes After Running PAL

[David W. <dpw...@nc...>]

Dr. Jonathan McCune,

Thanks for the reply.

Since my original message, we added some more printk calls to our module to
see if we could trace the problem.  Interestingly, it did not freeze.  The
only change was to add those printk calls -- the other functionality is
unchanged.  We then ran our earlier code that was freezing before, and it
still froze.  So now we have two copies, they differ only in their number
of printk calls -- the one with more printk calls works, the other does not.

I also took note of the "gibberish" you pointed out. It  was identical to
the version that froze.  I also looked at that some line from our demo PAL
module, and it was also identical.  So all three modules have the same
"gibberish".

Finally, from tracing the debug statements in the flicker kernel module
output, it appears the computer is freezing near where the module is
supposed to be unloaded.

Thank you for all your help.

Dave

On Wed, Feb 22, 2012 at 12:48 PM, Jonathan McCune <jon...@cm...> wrote:

> >     FLI: returning from rsa_public.c:pal_main()
> >     FLI: Successfully extended measurement PCR with zero.
> >     FLI: TPM: deactivate_all_localities()
> >     FLI: esp: 0x0000ff2c
> >     @??@?@_@@
>
> So that "gibberish" at the end is there to help chase down where in
> the assembly code things may have gone wrong.
>
> > The first line is printed by my code at the end of pal_main(). The
> others I
> > believe are printed by Flicker itself after pal_main() has returned.
> (Please
> > correct me if I'm wrong.)
>
> That's right.
>
> > Finally, I was actually able to run this module previously. Then I
> changed
> > size of the buffer in printk() to 512 bytes (from 256) and ran into the
> > issue I've described. I switched the size back to 256, but the errors
> > continue. Subsequently, I compiled and successfully ran a "hello world"
> > flicker module which worked fine.
>
> I would say something is overflowing the stack, or there is some other
> kind of memory corruption.  Unfortunately at present there's no clean
> way to detect that.  My approach is usually to use git for version
> control and commit often, so I can roll back changes in small
> increments.
>
> > Has anyone had similar problems? Do you have any suggestions for
> > investigating this bug? Do you have any suggestions that may help fix it?
>
> You could try to dig into the assembly code and really understand
> exactly what value(s) has been clobbered.
>
> > Also, is there any way to use Flicker from user space?  Perhaps in a
> sort of
> > "debug" mode?
>
> For the Memoir project we produced "FlickSim", which you may find
> valuable / interesting.  Note that it's covered by the MSR-LA and not
> a BSD-style license.
>
> http://research.microsoft.com/en-us/projects/memoir/
>
> ... and actually it looks like some MSR folks may have further
> enhanced it.  I'm not personally familiar with its details.
>
> > I am using a Dell Optiplex 755 workstation, which is one of the machines
> > suggested on http://sparrow.ece.cmu.edu/group/flicker.html.
>
> Good choice.
>
> -Jon
>

Re: [flickertcb-devel] Flicker Freezes After Running PAL

[Jonathan M. <jon...@cm...>]

>     FLI: returning from rsa_public.c:pal_main()
>     FLI: Successfully extended measurement PCR with zero.
>     FLI: TPM: deactivate_all_localities()
>     FLI: esp: 0x0000ff2c
>     @??@?@_@@

So that "gibberish" at the end is there to help chase down where in
the assembly code things may have gone wrong.

> The first line is printed by my code at the end of pal_main(). The others I
> believe are printed by Flicker itself after pal_main() has returned. (Please
> correct me if I'm wrong.)

That's right.

> Finally, I was actually able to run this module previously. Then I changed
> size of the buffer in printk() to 512 bytes (from 256) and ran into the
> issue I've described. I switched the size back to 256, but the errors
> continue. Subsequently, I compiled and successfully ran a "hello world"
> flicker module which worked fine.

I would say something is overflowing the stack, or there is some other
kind of memory corruption.  Unfortunately at present there's no clean
way to detect that.  My approach is usually to use git for version
control and commit often, so I can roll back changes in small
increments.

> Has anyone had similar problems? Do you have any suggestions for
> investigating this bug? Do you have any suggestions that may help fix it?

You could try to dig into the assembly code and really understand
exactly what value(s) has been clobbered.

> Also, is there any way to use Flicker from user space?  Perhaps in a sort of
> "debug" mode?

For the Memoir project we produced "FlickSim", which you may find
valuable / interesting.  Note that it's covered by the MSR-LA and not
a BSD-style license.

http://research.microsoft.com/en-us/projects/memoir/

... and actually it looks like some MSR folks may have further
enhanced it.  I'm not personally familiar with its details.

> I am using a Dell Optiplex 755 workstation, which is one of the machines
> suggested on http://sparrow.ece.cmu.edu/group/flicker.html.

Good choice.

-Jon

[flickertcb-devel] Flicker Freezes After Running PAL

[David W. <dpw...@nc...>]

Hello folks,

I have created a Flicker PAL, but am having problems with it freezing my
machine. It appears to stop *after* my PAL has completed, but before
control returns from Flicker. At least that's my interpretation of the
output. I have another machine connected by serial cable and am able to
read the output.  The following is the end of the output as seen by the
connected machine:

    FLI: returning from rsa_public.c:pal_main()
    FLI: Successfully extended measurement PCR with zero.
    FLI: TPM: deactivate_all_localities()
    FLI: esp: 0x0000ff2c
    @??@?@_@@

The first line is printed by my code at the end of pal_main(). The others I
believe are printed by Flicker itself after pal_main() has returned.
(Please correct me if I'm wrong.)

Finally, I was actually able to run this module previously. Then I changed
size of the buffer in printk() to 512 bytes (from 256) and ran into the
issue I've described. I switched the size back to 256, but the errors
continue. Subsequently, I compiled and successfully ran a "hello world"
flicker module which worked fine.

Has anyone had similar problems? Do you have any suggestions for
investigating this bug? Do you have any suggestions that may help fix it?

Also, is there any way to use Flicker from user space?  Perhaps in a sort
of "debug" mode?

I am using a Dell Optiplex 755 workstation, which is one of the machines
suggested on http://sparrow.ece.cmu.edu/group/flicker.html.

Thanks for your help,
David

Re: [flickertcb-devel] Flicker session crashes and restart the system

[Jonathan M. <jon...@cm...>]

Hi Imran,

tboot and Flicker do not currently mix.  You must boot without tboot
for Flicker to work.  If you try that and are still having problems,
please also collect the serial port output.

Regards,
-Jon


On Thu, Jan 26, 2012 at 5:37 PM, imran khan <imr...@gm...> wrote:
> Hi,
>
> When I run a Flicker session it crashes in the middle and restart the
> system.
>
> I am getting the following output when I run a Flicker session:
>
> Output:
>
> ---------------------------------------------------------------------
>
>  # ./go.sh
>
> Inserting flicker.ko module
>
> Disabling cpu 1
>
> Disabling cpu 2
>
> Disabling cpu 3
>
> Found SINIT /boot/2nd_gen_i5_i7_SINIT_51.BIN
>
> ACmod Loaded
>
> Loading PAL…
>
> Retrieving outputs from flicker-session
>
> 00000000 00 00 00 00 00 00  (………………)
>
> *
>
> 0001C000
>
> pcrs found at /sys/devices/pnp0/00:04/pcrs
>
>  ----------------------------------------------------------------------
>
>
>
> I am using HP Elitebook 8560p, ubuntu 11.10 with kernel 3.0.0-15. I booted
> the system through tboot.
>
>
> Thanks,
>
> Imran Khan
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> flickertcb-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flickertcb-devel
>

[flickertcb-devel] Flicker session crashes and restart the system

[imran k. <imr...@gm...>]

Hi,

When I run a Flicker session it crashes in the middle and restart the
system.

I am getting the following output when I run a Flicker session:

Output:

---------------------------------------------------------------------

 # ./go.sh

Inserting flicker.ko module

Disabling cpu 1

Disabling cpu 2

Disabling cpu 3

Found SINIT /boot/2nd_gen_i5_i7_SINIT_51.BIN

ACmod Loaded

Loading PAL…

Retrieving outputs from flicker-session

00000000 00 00 00 00 00 00  (………………)

*

0001C000

pcrs found at /sys/devices/pnp0/00:04/pcrs

 ----------------------------------------------------------------------



I am using HP Elitebook 8560p, ubuntu 11.10 with kernel 3.0.0-15. I booted
the system through tboot.


Thanks,

Imran Khan

Re: [flickertcb-devel] PAL max size + max input size

[Jonathan M. <jon...@cm...>]

Hello,

> Is there a constraint in Flicker's architecture on the pal's size and/or
> input size?

Regarding basic functionality:

There are some pre-defined limits in the existing source code, but
those can be expanded if need be.  I'm not sure that the code is clean
enough for there to be a single location to make such a change, but it
shouldn't be too bad.  The main obstacle is getting the OS to give you
a large enough physically contiguous chunk of memory.

Regarding security:

The main issue is that DMA protections are only automatically
installed to cover the SLB (in the case of an AMD processor) or MLE
(in the case of an Intel processor).  This is a known issue in the
existing code release, and thus changing the size of the high region
(the subject of this post) doesn't actually make the existing issue
any worse, expect that more code is exposed.

To use a larger PAL and do it "right", it is necessary to extend the
relevant protections, and then re-measure and re-extend the portions
of your PAL that were originally outside of the DMA-protected region,
since those addresses were exposed to potentially malicious DMA
activity.  Obviously it is necessary to ensure that no code is
executed out of the unprotected regions until protections are
established.

The existing code (flicker-0.5) takes care in the linker script to
distinguish between these two regions, and to measure (hash and then
PCR-Extend) the higher region.  We've called this the "hash trick" in
the past since it actually has a tendency to improve performance on
some hardware as well.

However, the existing code does NOT extend DMA protections to this
higher region.  Intel enables configurable MLE sizes and thus it is
fairly straightforward to ensure that the entire region is covered,
but AMD's SLB has a permanent maximum size of 64 KB.  It is necessary
to program AMD's IOMMU to get the extra protection.

Hope this helps,
-Jon

[flickertcb-devel] PAL max size + max input size

[hilfi a. <hil...@be...>]

Hi,

Is there a constraint in Flicker's architecture on the pal's size and/or
input size?

Thanks,
Hilfi Alkaff

Re: [flickertcb-devel] NV Write/Read

[Steve J. <ste...@ad...>]

Yes, tpm_nv_write_value within Flicker.  I don't need to protect the NV
space with an auth value, I just need to be able to store the data.  But
since TrouSerS (command tpmnv_defindex) prompted me to use a password I
went that route.

I created a NV Index that does not require authorization and can
successfully read/write to this location.

Thanks for the info and a push in the right direction!

Steve


On 11/17/2011 01:24 PM, Bryan Parno wrote:
> Hi Steve,
> 
> You're talking about tpm_nv_write_value inside Flicker, right?  At the moment, it assumes that you're protecting the NV space via PCR-based restrictions, rather than auth values.  In other words, the way we've been using the NV space is to define the space such that it can only be read or written when the TPM's PCRs match those we expect for Flicker plus our PAL.  That way, we don't need to provide an auth value for the write.  
> 
> If your application needs to protect the NV space with an auth value, you'll need to modify tpm_nv_write_value.  It shouldn't be too bad if you follow the code in seal or unseal.
> 
> Cheers,
> -Bryan
> 
> 
>> -----Original Message-----
>> From: Steve Johnston [mailto:ste...@ad...]
>> Sent: Thursday, November 17, 2011 9:42 AM
>> To: Bryan Parno
>> Cc: fli...@li...
>> Subject: Re: [flickertcb-devel] NV Write/Read
>>
>> Thanks Bryan.
>>
>> I've successfully created a NV Index with TrouSerS and using the
>> tpm_nv_read_value function have been able to confirm the existence of
>> this index with Flicker.
>>
>> My next question is how do I pass through authorization so I can write
>> to this location?  The function tpm_nv_write_value returns a 0x3B
>> (TPM_AUTH_CONFLICT) value.  The only place I see an authorization input
>> is when sealing/unsealing.
>>
>> I do have ownership of the TPM and have an owner and SRK password.
>>
>> Steve
>>
>>
>>
>> On 11/14/2011 03:55 PM, Bryan Parno wrote:
>>> Hi Steve,
>>>
>>>
>>>
>>> To keep the Flicker code base small, the NV code expects you to define
>>> the NV space outside of the Flicker session and then checks that it was
>>> setup correctly.  You can define an NV space using TrouSerS or the
>>> jTpmTools.
>>>
>>>
>>>
>>> -Bryan
>>>
>>>
>>>
>>> *From:*Steve Johnston [mailto:ste...@ad...]
>>> *Sent:* Monday, November 14, 2011 12:26 PM
>>> *To:* fli...@li...
>>> *Subject:* [flickertcb-devel] NV Write/Read
>>>
>>>
>>>
>>> Hi All,
>>>
>>>
>>>
>>> I'm trying the read and write from the TPM NV.  Using the
>>> tpm_nv_write_value/tpm_nv_read_value functions in tpm_extra.c
>> returns
>>> TPM_BADINDEX (0x02).  Is Flicker capable of defining this index or is
>>> that something that needs to be setup using TrouSerS?
>>>
>>>
>>>
>>> Steve
>>>
>>
> 
> 

Re: [flickertcb-devel] WB caching mode for PAL

[Jonathan M. <jon...@cm...>]

Hello,

> Is there a patch available that sets the MTRRs covering PAL
> memory region to WB caching mode.

Unfortunately I do not have such a patch readily available at the
moment, though some other folks on here may.

The existing code for doing this took the MTRR settings from the
untrusted world and did not sanitize them at all, making this a fairly
large attack surface (I haven't personally tried to implement an
attack, but these kinds of things have lead to attacks on SMM, Xen,
and other fairly critical components of a system (see, e.g., some of
the attacks published by Rutkowska et al.)).  To do it "right" it
would be much better if the code in the PAL built up the appropriate
settings from "first principles", without relying on any information
from the untrusted OS.  Unfortunately "first principles" usually means
some memory layout information gleaned from other firmware on the
system, which is difficult to verify.  A practical alternative might
be to at least come up with some sanity checks / constraints on the
values provided from the OS.

To date, I have not tried to find a concrete solution to this problem.
 In the coming months, that may change, and I will certainly make an
announcement here if that turns out to be the case (actually, that
would be a nice enough feature to release a new version).

> I was able to enable WB caching for Flicker-0.2 but the same
> code snippet seems to cause Flicker-0.5 to hang.

This is likely just a bug in the porting effort or misconfiguration /
misunderstanding.  I don't think there's anything fundamental that
should prevent it from working.  If you're willing to share some of
these snippets then it may be easier for myself or others to try to
help.

Best,
-Jon

Re: [flickertcb-devel] PALs source codes?

[Jonathan M. <jon...@cm...>]

Hello,

> Is it possible if I could take a look at the source code of the PALs that
> are mentioned in the eurosys paper (rootkit detector + BOINC modifications)?

I'm sorry, but I can't justify the effort to clean these up and make
sure they work with the released versions of the Flicker code.

> I'm currently doing research along the same lines for cloud computing and it
> would be very nice if I could compare the different approaches.

The designs are pretty simple.  Let me attempt to summarize them here
(caveat: I'm depending on my memory, which is now stale by years):

Rootkit detector:
* Configure the PAL such that it may access all memory (by making
changes to at least one segment descriptor in its GDT; iirc we used FS
so as to minimize impact on any other existing PAL code), and accept
as input parameters a set of address ranges to hash.  Run sha1 over
each of these address ranges, extending the aggregate result into a
specified PCR (iirc we used 18 or 19).

* This makes the hard / interesting part of the problem not running
the "rootkit detector", but coming up with the right input parameters
to give this PAL so that it will indeed hash all of the expected
invariant parts of the Linux kernel's executable in-memory image.  The
module loader makes this somewhat interesting, as do the possible
things a rooted kernel could do to try to relocate itself while
leaving a benign / expected copy in-place.

BOINC:
* BOINC (in at least some configurations that were current when we
wrote the paper) ships the work-unit as a relatively self-contained
executable (it may have even been statically linked), some inputs, and
some glue code (scripts?) to assimilate and transmit results.  We were
able to simply provide our own executable that invoked a Flicker
session to do some computation, making the relationship with BOINC a
fairly clean interface.  Generating an attestation from outside of the
PAL was more challenging than setting up an appropriate PAL, for us.
This means having some untrusted code request a TPM Quote from outside
of the PAL, once the PAL has completed.  IIRC, this wasn't too
difficult either, since there's already some client-side logic in
BOINC for assembling / compressing / etc the results for transmission
back to the central controller.

My point in both of these cases is that the PAL is not the most
interesting / challenging part.  More thought needs to go into how the
PAL is interfaced with the rest of the system.  For example, a rooted
OS has the opportunity to uninstall the rootkit before running the
detector PAL.

Hope this helps,
-Jon

[flickertcb-devel] PALs source codes?

[hilfi a. <hil...@be...>]

Hi,

Is it possible if I could take a look at the source code of the PALs that
are mentioned in the eurosys paper (rootkit detector + BOINC
modifications)? I'm currently doing research along the same lines for cloud
computing and it would be very nice if I could compare the different
approaches.

Best,
Hilfi Alkaff

Re: [flickertcb-devel] NV Write/Read

[Bryan P. <pa...@mi...>]

Hi Steve,

You're talking about tpm_nv_write_value inside Flicker, right?  At the moment, it assumes that you're protecting the NV space via PCR-based restrictions, rather than auth values.  In other words, the way we've been using the NV space is to define the space such that it can only be read or written when the TPM's PCRs match those we expect for Flicker plus our PAL.  That way, we don't need to provide an auth value for the write.  

If your application needs to protect the NV space with an auth value, you'll need to modify tpm_nv_write_value.  It shouldn't be too bad if you follow the code in seal or unseal.

Cheers,
-Bryan


> -----Original Message-----
> From: Steve Johnston [mailto:ste...@ad...]
> Sent: Thursday, November 17, 2011 9:42 AM
> To: Bryan Parno
> Cc: fli...@li...
> Subject: Re: [flickertcb-devel] NV Write/Read
> 
> Thanks Bryan.
> 
> I've successfully created a NV Index with TrouSerS and using the
> tpm_nv_read_value function have been able to confirm the existence of
> this index with Flicker.
> 
> My next question is how do I pass through authorization so I can write
> to this location?  The function tpm_nv_write_value returns a 0x3B
> (TPM_AUTH_CONFLICT) value.  The only place I see an authorization input
> is when sealing/unsealing.
> 
> I do have ownership of the TPM and have an owner and SRK password.
> 
> Steve
> 
> 
> 
> On 11/14/2011 03:55 PM, Bryan Parno wrote:
> > Hi Steve,
> >
> >
> >
> > To keep the Flicker code base small, the NV code expects you to define
> > the NV space outside of the Flicker session and then checks that it was
> > setup correctly.  You can define an NV space using TrouSerS or the
> > jTpmTools.
> >
> >
> >
> > -Bryan
> >
> >
> >
> > *From:*Steve Johnston [mailto:ste...@ad...]
> > *Sent:* Monday, November 14, 2011 12:26 PM
> > *To:* fli...@li...
> > *Subject:* [flickertcb-devel] NV Write/Read
> >
> >
> >
> > Hi All,
> >
> >
> >
> > I'm trying the read and write from the TPM NV.  Using the
> > tpm_nv_write_value/tpm_nv_read_value functions in tpm_extra.c
> returns
> > TPM_BADINDEX (0x02).  Is Flicker capable of defining this index or is
> > that something that needs to be setup using TrouSerS?
> >
> >
> >
> > Steve
> >
> 

Re: [flickertcb-devel] NV Write/Read

[Steve J. <ste...@ad...>]

Thanks Bryan.

I've successfully created a NV Index with TrouSerS and using the
tpm_nv_read_value function have been able to confirm the existence of
this index with Flicker.

My next question is how do I pass through authorization so I can write
to this location?  The function tpm_nv_write_value returns a 0x3B
(TPM_AUTH_CONFLICT) value.  The only place I see an authorization input
is when sealing/unsealing.

I do have ownership of the TPM and have an owner and SRK password.

Steve



On 11/14/2011 03:55 PM, Bryan Parno wrote:
> Hi Steve,
> 
>  
> 
> To keep the Flicker code base small, the NV code expects you to define
> the NV space outside of the Flicker session and then checks that it was
> setup correctly.  You can define an NV space using TrouSerS or the
> jTpmTools.
> 
>  
> 
> -Bryan
> 
>  
> 
> *From:*Steve Johnston [mailto:ste...@ad...]
> *Sent:* Monday, November 14, 2011 12:26 PM
> *To:* fli...@li...
> *Subject:* [flickertcb-devel] NV Write/Read
> 
>  
> 
> Hi All,
> 
>  
> 
> I'm trying the read and write from the TPM NV.  Using the
> tpm_nv_write_value/tpm_nv_read_value functions in tpm_extra.c returns
> TPM_BADINDEX (0x02).  Is Flicker capable of defining this index or is
> that something that needs to be setup using TrouSerS? 
> 
>  
> 
> Steve
> 

[flickertcb-devel] WB caching mode for PAL

[Asim <aja...@nd...>]

Hi,

Is there a patch available that sets the MTRRs covering PAL
memory region to WB caching mode.

I was able to enable WB caching for Flicker-0.2 but the same
code snippet seems to cause Flicker-0.5 to hang.

--Asim

Re: [flickertcb-devel] NV Write/Read

[Bryan P. <pa...@mi...>]

Hi Steve,

To keep the Flicker code base small, the NV code expects you to define the NV space outside of the Flicker session and then checks that it was setup correctly.  You can define an NV space using TrouSerS or the jTpmTools.

-Bryan

From: Steve Johnston [mailto:ste...@ad...]
Sent: Monday, November 14, 2011 12:26 PM
To: fli...@li...
Subject: [flickertcb-devel] NV Write/Read

Hi All,

I'm trying the read and write from the TPM NV.  Using the tpm_nv_write_value/tpm_nv_read_value functions in tpm_extra.c returns TPM_BADINDEX (0x02).  Is Flicker capable of defining this index or is that something that needs to be setup using TrouSerS?

Steve