[coreboot] TXE and Descriptor bin management in Coreboot

Mon Jul 18 06:32:18 CEST 2016

Hello Brett and Coreboot community,

This'll be my last email in this particular thread (unless somebody asks me
a question). I'll try to be short and punctual, and try to cover the most
for BYT (considering Brett's last email), since I had some time to re-think
about BYT TXE and recall some things, not mentioned here.

[1] HW straps. HW straps are for schematic HW designers, highly classified
INTEL info, so I'll assume this is done correctly for the BYT boards (you
all should check with your BYT board designers);
[2] Yes, BYT could be brought up without TXE FW (not using TXE HW), but
then XDP will be disabled (maybe some other TXE related features);
[3] In order to make XDP to work, FW IOTG designers introduced so-called
slim TXE, which is real TXE reduced to 1,5MB, in nutshell this TXE allows
all the features, but disables main one: BIOS tampering;
[4] I remember one specific IOTG slim TXE: 1.1.1.1120 (it could be that
there is slim TXE 1.1.1.1127 and newer), you should go to INTEL VIP site
www.platformsw.intel.com to check/get them (you have to have access to it);
[5] Or you can also go here:
http://www.win-raid.com/t832f39-Intel-Engine-Firmware-Repositories.html and
try to find it;
[6] BYT Power Rails: there are 14 of them, if you reduce/not use Power
Management, number reduces (example, if you use only CPU's C0 and C1 ->
platform's S0, you need at most 5 main power rails (highly HW topic);

Lot of the decisions for the platform HW design are on your own perils,
please, never forget this. INTEL reference boards are HW and SW guidance,
not a must to follow up with them, but INTEL tries to comply with most
complex customer wishes (example: to show all the advantages for C0, C1...
C3, C6, C7, C8, C9 etc. PM CPU/SoC states in newest CPUs/SoCs, such as ATOM
APL-I).

It just depends what are the particular requirements (referring as example
to [6]). 14 Power Rails are there for BYT, but there are so handful to use,
depending upon HW PM design. :-)

Zoran
_______

On Sat, Jul 16, 2016 at 12:45 AM, Testerman, Brett (US COM) <
Brett.Testerman at cobham.com> wrote:

> Hi Zoran,
>
>
>
> I am running a Bay Trail-I processor, an E3815 to be specific, and really
> had to jump through a lot of hoops to initially bring it up. I did
> everything I could think of from a software standpoint, including creating
> signed images and a manifest table. I sought support on the Intel forums
> and it was there that I was shown I could boot that processor without the
> TXE. We are using the processor in an embedded device where things like
> preventing BIOS tampering just gets in the way as we are not running Linux
> or Windows, and even if we did there is no network connectivity or any
> other reason for anyone to hack into it. Thankfully it seems for the E3800
> family  Intel does not strictly enforce security. I do not have experience
> with the other CPU family members to know if that is true across the board.
>
>
>
> So empirically I found that yes, I can boot coreboot without the TXE
> binary in flash. However when I attached the XDP probe I could only see the
> boundary scan device. The CPU device had an address of all 0’s and the
> probe could not attach to it. I did not change any of the soft straps nor
> am I asserting the Security Flash Descriptors override hardware strap. All
> I did was remove the TXE from the boot flash.
>
>
>
> I also found that I don’t have to generate hashes on my binaries or a
> manifest table in order for it to boot. There is supposed to be a secure
> boot fuse to force that but we obviously are not setting it.
>
>
>
> Documents I reviewed to get to the point I am:
>
> 540009 Intel® Atom™ Processor E3800 Product Family – Intel® Trusted
> Execution Engine (Intel® TXE) Firmware    Bring-Up Guide
>
> 528703 Secure Boot Implementation in the Sample Boot Loader using Intel®
> FSP for Bay Trail Platforms README
>
> 539374 Secure Boot Sample Implementation for Intel® Atom™ Processor E3800
> Product Family README
>
> Among others.  I haven’t look at this for over a year
>
>
>
>
>
> As for the soft straps, the document I referenced originally:
>
> 514482 Bay Trail-T/I SoC SPI Flash Programming Guide - Application Note
>
> covers them along with the layout of the descriptor table. I did just do a
> quick web search and it looks like Intel has locked down that document. I
> am sorry to see that. The last time I check it was unlocked.
>
>
>
> As frustrating it has been bringing up this processor I will say it has
> worked solid once we got through all the hardware design issues. I think
> the HW engineer said there are 27 different power rails. I am still booting
> the version of coreboot I used to bring the chip up a year ago and we have
> done all of our application design as a payload to it. I just saw that
> Intel released a reference coreboot for the Bayley Bay platform, which is
> chip-down Bay Trail, in March of this year so I will probably migrate to it
> and lock it there.
>
>
>
> I will say if anyone needs help with bringing up a design the embedded
> community forums should be the place to start:
>
> https://embedded.communities.intel.com/community/en
>
>
>
> Sorry for the long email. If my experiences can help others I will try to
> respond, time permitting. My way of thanking B.O. and others who helped me
> when I was in the same position.
>
>
>
> Brett
>
>
>
>
>
>
>
>
>
> *From:* Zoran Stojsavljevic [mailto:zoran.stojsavljevic at gmail.com]
> *Sent:* Thursday, July 14, 2016 10:06 PM
> *To:* Testerman, Brett (US COM)
> *Cc:* coreboot; Martin Roth; Mayuri Tendulkar; Stefan Reinauer
>
> *Subject:* Re: [coreboot] TXE and Descriptor bin management in Coreboot
>
>
>
> *** Please note that the Sender of this email is from outside the Cobham
> NA IT Hub ** *
>
> Hello Brett,
>
>
>
> Having overall experience with INTEL, I should say that the Truth is a bit
> more complicated. ;-)
>
>
>
> In the simplified view, there are two points when bringing any INTEL CPU
> from reset, i should say. The first is: HW strap conditions, and these need
> to be set appropriately, depending upon what the HW config will be. This
> point I mentioned since I am not sure if XDP port only depends upon TXE, I
> do not really know with certainty for BYT, but I do know for some other
> families HW straps also need to be set properly for XDP to be enabled.
> Maybe there are two requirements for XDP to be enabled, so I am really not
> sure about this, this is why I am writing this email.
>
>
>
> So, the question I have here is: does BYT have to have one of the HW
> straps properly set (maybe it is already set by default design) for XDP to
> be enabled?
>
>
>
> The another point why TXE HW/FW engine is mainly used is the following:  TXE
> Firmware, the Trusted eXecution Engine, provide features to prevent BIOS
> tampering, however information about TXE is considered Intel Confidential
> and require that you have CNDA account.
>
>
>
> Usually, FSP + Coreboot (as you have mention already), is built on the top
> of normal BIOS (last 2M, maybe these days 3M, since FSP and Coreboot are
> growing) , since normal BIOS includes SW straps (second point), which are
> also set by default (in BIOS). In this scenario, FIT (formerly FITC) tool
> is not required (if satisfied with default SW straps, which 99% developers
> are).
>
>
>
> Here is INTEL site where there are overall set of BYT documents, but many
> of them are locked (as well as 514482):
>
>
>
> [image: Inline image 1]
>
>
>
>
> http://www.intel.com/content/www/us/en/embedded/products/bay-trail/software-and-drivers.html
>
>
>
> Hope this helps also,
>
>
>
> Zoran
>
>
>
>
>
>
>
> On Thu, Jul 14, 2016 at 9:51 PM, Testerman, Brett (US COM) <
> Brett.Testerman at cobham.com> wrote:
>
> Mayuri,
>
>
>
> Your best bet with all of this is to contact Intel and get a privileged
> access account. If that is not possible or practical then you need to do
> some reverse engineering.
>
>
>
> First of all, go get this document from Intel’s web site:
>
>
>
> 514482_ByTti_SoC_SPIFlashProgGuide_Rev1p0.pdf
>
>
>
> I don’t have a specific link to it but I know it is publically accessible.
> Search on the leading 6 digit number or “SPI Flash Programming Guide”. This
> document fully describes the descriptor tables and how to use them. The
> FITC tool is the preferred way but you can bit-bang them with the info
> provided in that doc.
>
>
>
> As for the TXE you will need to get that from Intel – it is not publically
> available. But I can say if you are running on the E3800 family (Bay Trail)
> then you don’t need it. The chip will boot without it but the XDP port will
> be locked out. You can also use the information from the programming guide
> to locate a TXE image in a 3rd party boot image and extract it out of
> that. I think that is what the idftool does.
>
>
>
> The coreboot image will need to be located at the very end of flash
> because that is where the hardware reset vector is. The nice thing about
> that is once you have set up the descriptors you don’t have to
> rebuild/reprogram the entire flash image every time. For example, if your
> coreboot image is only 1MB in size then you only need to reprogram the last
> 1 megabyte of flash and leave the rest alone. Saves a ton of time.
>
>
>
> There has been a lot of talk about this issue on Intel’s embedded
> communities forums. Check out this thread:
>
> https://embedded.communities.intel.com/thread/12354
>
>
>
> Hope this helps!
>
>
>
> Brett
>
>
>
>
>
>
>
> *From:* coreboot [mailto:coreboot-bounces at coreboot.org] *On Behalf Of *Stefan
> Reinauer
> *Sent:* Wednesday, July 13, 2016 4:30 PM
> *To:* Mayuri Tendulkar
> *Cc:* Martin Roth; coreboot
> *Subject:* Re: [coreboot] TXE and Descriptor bin management in Coreboot
>
>
>
> *** Please note that the Sender of this email is from outside the Cobham
> NA IT Hub ** *
>
> * Mayuri Tendulkar <mayuri.tendulkar at aricent.com> [160714 00:50]:
> > Ok, so do we need to ask Intel if we use Intel baytrail processor? How
> we can create this descriptor.bin?
>
> Please have a look at util/ifdtool and util/ifdfake for our tools
> dealing with Intel Firmware Descriptors. The most comprehensive way of
> producing the information you need is by using Intel's fitc tool,
> however.
>
> If you are willing to put some development effort into this, we could
> use help, merging ifdtool and ifdfake, as well as incorporating more
> fitc like capabilities into the tool.
>
> Stefan
>
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160718/645d333d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 32339 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160718/645d333d/attachment-0001.png>