[RFC v2] Bootblock redundancy with coreboot

Hello coreboot community members,

This is a follow-up to my colleague Michał Żygowski's RFC concerning
redundancy of the bootblock, mainly on recent Intel-based platforms. 
We've
taken your feedback and would like to present another proposal to you.

The goal of this feature is to prevent accidental bricks caused by 
flashing a
bad firmware image, by providing a secondary copy of boot firmware that 
acts as
a fallback path for main firmware. The general idea is that if a user 
flashes
bad firmware or the update goes wrong, you can always restore 
functioning
firmware by resetting the CMOS.

On Intel, this is realized by the Top Swap mechanism, where the top 
range of
the flash (of configurable size, from 64K to more than 1M in latest 
chipsets)
can be swapped between two copies. At this point support for other
architectures has not been considered, so initially this would be an 
Intel-only
feature.

I find it easiest to show an example FMAP first and then describe 
what's going
on:

FLASH 32M {
 SI_ALL 10M {
  SI_DESC 16K
#if CONFIG_MAINBOARD_USES_IFD_GBE_REGION
  SI_GBE 8K
#endif
  SI_ME
 }
 RW_UNUSED 6M

 SI_BIOS {
  RW_MISC {
   RW_MRC_CACHE 64K
   SMMSTORE(PRESERVE) 256K
  }

  RW_PAD

  FW_MAIN_B(CBFS) 6M
  FW_MAIN_A(CBFS) 6M

  FMAP 2K

  TOPSWAP_B(CBFS) 512K
  TOPSWAP_A(CBFS) 512K
 }
}

In this example:
- The FMAP region is not redundant and it is suggested that this region 
not
  change for the lifetime of the platform, to make sure the redundancy 
code
  works properly.
- There are two bootblocks and two FW_MAIN sections which together 
establish
  Slot A and Slot B
- Topswap regions are CBFSes that contain the bootblocks and ACMs if 
used by
  the build
  - ACMs are also why their sizes in this example are configured to 512K
- SMMSTORE and MRC cache do not need to be and aren't covered by 
redundancy
- Initially, the platform boots from Slot A only
- Slot A firmware is unchanging and may be protected by chipset 
protection
  mechanisms (PRx registers on Intel based platforms)
- The update flow
  - User attempts to update slot B, e.g. by flashrom
  - User sets the Attempt Slot B flag e.g. by nvramtool
  - User reboots the platform
  - Slot A firmware sees the Attempt Slot B flag, sets the Top Swap bit 
in the
    PCH and resets the platform
  - Slot B firmware is booted
- Recovery flow
  - User resets the CMOS
    - alternatively: attempt counter in CMOS, or watchdog resets the 
flags
  - Slot A firmware boots

There is also an option to have an updatable Slot A.

- The modified update flow:
  - User initiates update of Slot B e.g. by flashrom
  - User sets the Attempt Slot B flag e.g. by nvramtool
  - User reboots the platform
  - Slot A firmware sees the Attempt Slot B flag and sets the Top Swap 
bit
  - Slot B proceeds to boot into the payload and assesses that the boot 
was
    successful as late as possible (e.g. by UEFI EBS) by setting the 
Slot B
    Successful flag in CMOS
  - User eventually reboots the platform
  - Slot B firmware sees the update successful flag and overwrites Slot 
A
    with contents of Slot B

Looking forward to your feedback on this proposal :)



_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]