Opened 3 years ago

Closed 3 years ago

#11061 closed defect (fixed)

OFW XO-1.75 - implement firmware update security

Reported by: wmb@… Owned by: greenfeld
Priority: blocker Milestone: 1.75-firmware
Component: ofw - open firmware Version: Development firmware
Keywords: Cc:
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

Need to implement SPI FLASH locking in OFW.

Also lock down CForth when in secure mode.

Change History (12)

comment:1 Changed 3 years ago by wmb@…

  • Status changed from new to assigned

Quozl did the first part (OFW SPI FLASH locking) tracked as #11228.

svn 2575 fixes enable-security to work correctly on XO-1.75.

It remains to modify CForth to lock the SPI FLASH when the interactive prompt is obtained in secure mode.

comment:2 Changed 3 years ago by Quozl

  • Owner changed from wmb@… to Quozl
  • Status changed from assigned to new

Test code for checking the wp tag and locking the SPI FLASH has been pushed to cforth git.

comment:3 Changed 3 years ago by martin.langhoff

  • Priority changed from normal to blocker

We will need this soonish for MP -- next steps?

comment:4 Changed 3 years ago by wmb@…

Fixed by git 4579eb0

comment:5 Changed 3 years ago by Quozl

  • Action Needed changed from code to add to build
  • Version changed from 1.75-A3 to Development firmware

Reviewed code.

comment:6 Changed 3 years ago by martin.langhoff

  • Action Needed changed from add to build to test in build

Test in OS27 / Q4D03

comment:7 Changed 3 years ago by Quozl

  • Owner changed from Quozl to greenfeld

Please test, and write up a test case on the Wiki so we can more regularly test this. I've no idea how to test the security system as a whole. Reuben may be able to advise, I think he did the last one.

comment:8 Changed 3 years ago by greenfeld

In order to fully test this change, is a signed OFW and/or EC update required?

I have upgraded a locked XO with Q4D01 to a deployment-signed Q4D03 build with EC changes, but since Q4D02 there have been no EC changes to test upgrades from.

comment:9 Changed 3 years ago by wmb@…

I'm not sure I understand the question. It seems that you have tested the OFW update; is that correct? If so, is the issue that EC update needs to be separately tested?

One way to do that would be to use "flash-ec" to downgrade the EC code to the next lowest version, then sign the latest version with a test key.

comment:10 Changed 3 years ago by greenfeld

I think a simpler question is what needs to be tested (and written up as a testcase per Quozl) to verify this ticket?

I do not know much about the low-level security architecture besides:

  1. There is a hardware write lock of some sort.
  2. On 1.75, the EC and OFW EEPROMs are separated.
  3. I can downgrade OFW and/or the EC of a locked XO using a developer key to force said XO to process a signed update to the same on the next reboot.

comment:11 Changed 3 years ago by wmb@…

A complete security test would take pretty close to forever.

Maybe it is good enough to verify that signed EC update works and that corrupting the file doesn't work.

comment:12 Changed 3 years ago by greenfeld

  • Action Needed changed from test in build to no action
  • Resolution set to fixed
  • Status changed from new to closed

Tested EC & OFW firmware update security with 11.3.1 os28 & 29, Q4D04 & Q4D05 on XO-1.75 C2 laptops secured with the Nic image.

Upgrades could proceed normally while in secure mode, and working with Mitch, the points we could get into CForth or early OFW could not be used to reflash a laptop we accidentally quasi-bricked while testing this.

Note: See TracTickets for help on using tickets.