Opened 3 years ago

Closed 3 years ago

#10951 closed defect (fixed)

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

Reported by: wmb@… Owned by: Quozl
Priority: high Milestone: 1.75-firmware
Component: ofw - open firmware Version: 1.75-A3
Keywords: Cc: rsmith, quozl
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

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.

Change History (11)

comment:1 Changed 3 years ago by wmb@…

  • Status changed from new to assigned

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.

comment:2 Changed 3 years ago by wmb@…

  • Priority changed from normal to high

comment:3 Changed 3 years ago by wmb@…

  • Action Needed changed from design to review
  • Owner changed from wmb@… to pgf
  • Status changed from assigned to new

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.

comment:4 Changed 3 years ago by pgf

  • Cc rsmith quozl added

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.

comment:5 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by wmb@…

  • Owner changed from pgf to Quozl

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

comment:7 Changed 3 years ago by Quozl

  • Status changed from new to assigned

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.

comment:8 Changed 3 years ago by wmb@…

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

comment:9 follow-up: Changed 3 years ago by 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


comment:10 in reply to: ↑ 9 Changed 3 years ago by 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

comment:11 Changed 3 years ago by Quozl

  • Action Needed changed from review to no action
  • Resolution set to fixed
  • Status changed from assigned to closed

Is fixed, was observed in Q4B01, closing.

Note: See TracTickets for help on using tickets.