On May 30, 12:46pm, Marco Vanotti wrote:
} Subject: Re: [tboot-devel] Questions about Launch Control Policies
> Hi Greg!
>
> Thank you very much for your answer. I hope you are doing well too.
Good morning Marco, I hope the end of the week is going well for you.
Sorry for the delay in responding but I needed to get some equipment
re-arranged in order to answer your e-mail.
> On Sat, May 27, 2017 at 9:16 AM, Dr. Greg Wettstein <g...@wind.enjellic.com>
> wrote:
>
> > On May 26, 3:27pm, Marco Vanotti wrote:
> > } Subject: Re: [tboot-devel] Questions about Launch Control Policies
> >
> > > Hi Ning,
> >
> > Hi Marco, I hope this note finds your weekend going well.
> >
> > I've been watching this thread go by but have been swamped with a
> > number of other issues and haven't been able to compose a reply.
> >
> > First a reflection from a 50K perspective.
> >
> > We have expended significant engineering time and resources on TPM2
> > based TXT systems in order to build trusted platforms for clients. We
> > have close to a year of engineering time into developing support and
> > infrastructure for next generation security systems based on TXT/TPM2,
> > at this point in time we still are struggling to address all of the
> > issues we have identified on these platforms.
> >
> > So don't feel like you are struggling inordinately.
> At first it was mostly fun, getting to learn this new technology :)
> Most of my problems were solved by reading the source code, specs,
> or by getting a better understanding of how everything worked. Right
> now I am starting to get frustrated by all the obstacles..
Indeed.
Given the spectrum of challenges from poor OEM support to hardware
issues and tooling it is difficult to understand how the industry
can move forward implementing getter security guarantees which appear
to be desperately needed.
Once again it appears to be a chicken and egg problem. There appears
to be little interest in supporting the technology secondary to
insufficient 'market pull/demand' yet it is difficult to understand
how markets can develop with the type of barriers associated with
development, particularly in the TPM2 era.
> > > After a bit of tinkering with the NUC, I've come to a problem with
> > > that attributes. As I mentioned in another email, I'm having trouble
> > > with an Invalid RSDP once I add files to multiboot in the NUC. A
> > > side effect of that problem + using 0x4000A for the PO LCP is that
> > > the TPM gets into lockout mode and I have to clear ownership in
> > > order to use the same index again.
> > >
> > > ... [ error codes and information removed ] ...
> > >
> > > So I believe using the NO_DA flag while defining the policy is a
> > > requirement. Maybe there's a problem with my bios or sinit module?
> > > Do you know how can I debug that problem?
> > >
> > > I have another system and the policy works there, it has
> > > tpm_nv_index_set = 0, and has the NO_DA attribute set (0x204000A)
> >
> > We identified and reported the specific problem you are facing with
> > the Broadwell NUC about 11 months ago.
> >
> > There appears to be an architecture specific issue with the Broadwell
> > TPM2/TXT platforms. If the PO NVram index is created with attributes
> > based on what is documented in the TXT Software Development Manual
> > (SDM) the SINIT AC module will issue a hardware reset after TBOOT
> > initiates GETSEC[SENTER] processing.
> >
> > We currently have our Broadwell NUC reference platforms (the same as
> > yours) executing a measured launch with a PO LCP_ANY policy but the
> > NO_DA bit must be cleared. I don't have one of those machines on the
> > bench right now, I am also a hundred miles away from our lab and can't
> > hook one up, but I will do so and dump out the attributes from one of
> > the machines after I get back into town after the weekend and send it
> > to you if you would like.
> I see. So it seems to be a problem with all Broadwell machines.
> Have you been able to launch a POLTYPE_LIST?
We couldn't get a Broadwell based machine to boot if the PO NVram
index location was created. Once we determined that there appears to
be an undocumented micro-architectural dependency we were able to get
Broadwell machines to boot with a simple LCP_ANY policy.
At that point we started focusing on Skylake platforms since Broadwell
was already 'old' at that time... :-)( We ran into OEM issues on
Skylake surrounding what appears to be issues with respect to whether
or not the motherboard OEM's are properly provisioning TXT based
platforms.
We shifted our attention to KabyLake and identified the S3 sleep state
problem. That issue is probably present on all TPM2 based TXT
implementations as well.
So if we move forward with TXT development we would return to
Broadwell to see whether or not the ACM can deal with anything more
advanced then a simple LCP_ANY policy.
> > I assume you are using the 'production' release of TBOOT? On TPM2
> > based systems there is a device initialization ordering problem which
> > causes TBOOT to de-reference a NULL pointer and essentially read
> > random memory when it populates the TPM information structure. This
> > will cause the first (pre-GETSEC[SENTER] phase) of TBOOT to use the
> > wrong NVram index locations.
> I am compiling directly from source, so I've got the latest
> version. I believe that issue has been patched already.
I believe it has if 'from source' implies you are working from the
head of the SVN repository.
> > We need to implement a PCR based LCP PO policy but we haven't tangled
> > with that can of worms yet. Given the problems of even getting basic
> > LCP_ANY working it will be interesting to see how the ACM's deal with
> > the TPMS quotes.
> >
> > In the FWIW department, for the benefit of the community, there is
> > also a probable hardware problem with TBOOT S3 sleep state processing.
> > At this time it isn't possible to enter and resume from S3 and have
> > TBOOT properly validate its protected memory regions.
> >
> > Until we can get this issue run down it is difficult to know how
> > Linux/TBOOT will deal with the TPM resource manager which has been
> > included in recent kernels.
> I haven not gotten that far yet. However, so far I have not got any
> problem with the TPM2.0-tools that intel provides.
The TPM2.0-tools issue is orthogonal from the resource manager.
The resource manager device driver in recent kernels is designed to
arbitrate access to a TPM2 implementation from multiple userspace
clients. It is currently unclear on whether or not it will
inter-operate with a TBOOT TXT implementation.
At the current time that can't be tested since it doesn't appear that
the S3 sleep state support works on TPM2 based systems. That issue
seems to be troublesome secondary to a naive assumption by TBOOT that
a handle slut can be trusted to exist once it has been populated.
> > With respect to the RSDP issue you are running into. I believe the
> > link you posted was part of a thread in which we were attempting to
> > address a problem which a young engineer from HP Enterprise was
> > working on which was probably a 'custom' hardware configuration. I
> > believe we got him pointed to someone inside Intel but never got any
> > feedback on how the problem got addressed.
> I see. In this case it is normal hardware. I am thinking on just
> returning the NUC and buying something else. Do you know of any
> system that actually works with TXT?
That is a significant problem in and of itself.
A recommendation was made to us to use a major motherboard
manufacturer but it appears that OEM ships vPro systems which are
unprepared to even work with TXT enabled.
We ran into similar issues with a second vendor.
Your best hope of trying to get a TPM2/TXT based system working is
probably with the Broadwell NUC.
Are you by chance using an EFI based boot? We are currently
suspicious that the RSDP issue may be secondary to EFI based boot. We
only use legacy boot since EFI is such a wildcard at this point in
time.
> > At the risk of editorializing a bit, it seems that Intel largely looks
> > upon TBOOT as a community project. Given the issues which we have run
> > into, its somewhat hard to believe that VMware and other commercial
> > vendors would be using this to supported trusted computing pools and
> > the like for commercial customers.
> >
> > I believe there is plenty of engineering talent circulating around
> > this technology, but quite frankly given the intent of the technology,
> > it is purposefully designed to be non-debuggable. If we are going to
> > treat this as a community project and fix bugs, the ACM code needs to
> > be available in source form. I'm not sure how any of this can be
> > effectively debugged in the current environment.
> Agree. Right now we have to blindly trust intel's ACM, without being
> able to read the source code.
This is a question to the larger TXT community, is there interest in
changing this situation?
There is nothing overtly mysterious about an ACM. It is simply a
piece of signed 32-bit real mode code which can be executed with
higher platform privilege (locality). There would be nothing which
would technically prevent an alternative implementation, other then
architecture specific errata.
It may not be possible to get all the security guarantees inherent in
the current ACM's but those security guarantees are technically in
question at this point anyway. If this is to be a community supported
technology I think the only way forward is to address the issue of
building an open source ACM or an approximate equivalent.
Thoughts?
> > At this point in time the jury is out as to whether or not we will be
> > proceeding forward with targeting TXT/TPM2 development in the future.
> > Given the utility of this technology and the desperate industry need
> > for better security guarantees the barriers associated with advancing
> > initiatives are decidedly perplexing.
> >
> > It is an amazing chicken and egg problem. There is no market to
> > consume this security technology so there appears to be little
> > incentive to invest resources in supporting it, thats certainly
> > understandable. Unfortunately, products are not going to emerge
> > unless they can be developed which is proving to be a challenge on
> > what will be the operative hardware platform for the foreseeable
> > future.
> It would be nice to have better tooling and documentation. Maybe
> even some reference LCPs (POLTYPE_ANY, MLE2)
The biggest issue on TXT/TPM2 platforms is a reference implementation
of tooling which can properly NVram provision a TPM2/TXT based
hardware platform.
There appears to be inconsistent support with respect to how vendors
are shipping vPro/TXT systems. It is extremely important that anyone
interested in this technology know how the vendor is setting up the
platform, otherwise there is little hope of getting anything working.
> > > Have a nice weekend!
> > >
> > > Best Regards,
> > > Marco
> >
> > Hopefully the above information and reference points are helpful. I
> > will get a dump of the LCP PO NVram attributes, which are working on
> > Broadwell NUC, off to you in case that would be helpful.
>
> Please, that would be really helpful :)
The following is a dump of the NVram PO indesx (0x1400001) from a
Broadwell NUC which is succesfully executing an MLE with a PO LCP_ANY
policy:
---------------------------------------------------------------------------
Attributes: 0x2004000a
OWNERWRITE
POLICYWRITE
AUTHREAD
WRITTEN
Contents of NVram index: 0x1400001/20971521
00000016: 00 03 0b 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00000032: 00 00 00 00 00 00 02 00 00 00 00 00 c8 00 08 30 ...............0
00000048: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000064: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070: 00 00 00 00 00 00 ................
---------------------------------------------------------------------------
Just to explain so there is no confusion. All of our TPM2 based
tooling is custom built from Ken Goldman's TSS2 library so you won't
find anything out there which produces an NVram index location dump
like this.
The NVram descriptions and the hexdump of the index location should be
self-explanatory.
If you convert the hexdump into binary and load it into an NVram index
location which has been configured with the noted attribute the system
should execute a measured launch using the following TBOOT
command line configuration:
kernel /boot/tboot.gz logging=serial,memory,vga vga_delay=1 serial=115200
extpol=sha256
Along with the following ACM:
/boot/5th_gen_i5_i7_SINIT_79.BIN
> Best Regards,
> Marco
Once again, apologies for the delay in getting back to you.
Good luck with your work.
Have a good weekend.
Greg
}-- End of excerpt from Marco Vanotti
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102 development.
PH: 701-281-1686
FAX: 701-281-3949 EMAIL: g...@enjellic.com
------------------------------------------------------------------------------
"Everything should be made as simple as possible, but not simpler."
-- Albert Einstein
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
