OFW XO-1.75 - auto-reflash support for EC code

[wmb@…]

Now that the EC code is separate from the OFW image, we need a secure way to automatically update the EC code, similar to the way we auto-update OFW code.

This will affect both OFW and the OS build procedures.

[wmb@…]

As a corollary, we also need a lockout mechanism to protect the EC code. That will require hardware support plus OFW code to use it.

[wmb@…]

Implemented by svn 2265. Reassigning to pgf in case he wants to do the up-to-date check on version numbers instead of build dates. Such a change would require

* Definition of the version number format * Definition of the rules for valid version sequencing * Definition of the storage location of the version string in the image * Implementation of an EC command to return the version string, including the EC code and the OFW access word. * Reimplementation of the word ec-up-to-date? in cpu/x86/pc/olpc/security.fth to compare version numbers instead of build dates.

When done with these tasks, please reassign the ticket to someone for testing.

[pgf]

the EC command for returning the version is already implemented (4a), and the OFW code seems to exist as well, though it's referred to as "ec-name$". i'm not sure whether that's a bug or not.

the location of the version string in the image is already defined (3rd space-separated field at 0x7f00), though as discussed on IRC, it might be preferable to make that more robust, perhaps with null separation, instead. not strictly necessary, however.

what's really missing is strict definition of the EC version number sequence, which should allow for debug/development version names which don't supercede the natural collating sequence. (currently non-release versions have the developer's username in the version field -- these may well (do) sort after valid versions, and would prevent the auto-updater from replacing them.

[wmb@…]

I guess what confused me was the "version" string value "rsmith" in the ecimage.bin that I was inspecting. That led me to think that the string in question was really some other identifier.

Okay, so if we pin down the naming rules for development versions to ensure out-of-sequence collation, I guess we are okay.

[wmb@…]

If we use the existing version number, we'll need a comparison function that handles structured numbers so that, for example, 4.0.11 > 4.0.2 .

The version can be parsed from the version&date$ with something like:

  bl left-parse-string  " XO-EC" $=  0=  if  2drop true exit  then  ( rem$ )
  bl left-parse-string  " 4" $=  0=  if  2drop true exit  then  ( rem$ )
  bl left-parse-string  2nip  ( version$ )
  ec-version@  compare-ec-versions  0<=  ( flag )

Also we need to s/ec-name/ec-version/ in eccmd.fth and devices.fth

[Quozl]

Also need:

• ec-1.75 signing process, the file is to be data.img in ecfw.zip with a signature data.sig, using the OLPC firmware signing key,
• two non-development releases of ec-1.75 in both .img and ecfw.zip formats, for testing the auto-reflash.

[wmb@…]

For testing stuff like this, I usually either build a test OFW with a custom keypair, or keyject an alternate key.

[rsmith]

Paul and I chatted today and our proposal for the version scheme is the same as it currently is with the requirement that the final number is always 2 digits.

ie: x.x.xx

So the next release will be 0.1.00 and the point release after that would be 0.0.01

In addition to the version number there is also a platform identifier. Thats the XO-EC part of the string. The platform identifier is what allows one platform to reject code from a different platform even though they may be very similar. (same EC chip, same crc, etc )

So a full version string is:

XO-EC <platform> x.x.xx

The next planned release would be:

XO-EC 4 0.1.00

A developer build would be prefaced with a '+' and then the user name of the account used to build the firmware.

So a developer build would look like

XO-EC 4 +rsmith

[rsmith]

Replying to rsmith:

ie: x.x.xx So the next release will be 0.1.00 and the point release after that would be 0.0.01

oops. Typo. Point release would be 0.1.01

[Quozl]

Is fixed, was observed in Q4B01, closing.