dasharo/coreboot
0
0
Fork 0
mirror of https://github.com/Dasharo/coreboot.git synced 2026-06-13 10:16:48 -07:00
Code Issues Packages Projects Releases Wiki Activity

Documentation/drivers/smmstorev2.md: describe capsule update API

Browse Source 
This commit adds a description of capsule update commands implemented
in SMMSTORE in previous patches.

Upstream-Status: Submitted [CB:83426]
Change-Id: I94761d18be567e5302d1a836f09f0a7eecb4fb00
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
This commit is contained in:
Krystian Hebel
2025-03-26 20:19:02 +02:00
committed by Sergii Dmytruk
parent 375d0a6d6e
commit 8aab755c31
1 changed files with 25 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/drivers/smmstorev2.md
+25
View File
@@ -197,6 +197,31 @@ coreboot tables, there's no risk that a malicious application capable
of issuing SMIs could extract arbitrary data or modify the currently
running kernel.
## Capsule update API
To allow updating full flash content (except if locked at hardware
level), few new calls were added. They reuse communication buffer, SMI
command, return values and calling arguments of SMMSTORE commands listed
above, with the exception of subcommand passed via `%ah`. If the
subcommand is to operate on full flash size, it has the highest bit set,
e.g. it is `0x85` for `SMMSTORE_CMD_RAW_READ` and `0x86` for
`SMMSTORE_CMD_RAW_WRITE`. Every `block_id` describes block relative to
beginning of a flash, maximum value depends on its size.
In addition, there is one new subcommand that must be called before any
other subcommands with highest bit set can be used.
#### - SMMSTORE_CMD_USE_FULL_FLASH = 0x80
This command can only be executed once and is done by the firmware.
Calling this function at runtime has no effect. It takes one additional
parameter that, contrary to other commands, isn't a pointer. Instead,
`%ebx` indicates requested state of full flash access. If it equals 0,
commands for accessing full flash are permanently disabled, otherwise
they are permanently enabled until next boot. It is expected that the
payload won't allow regular OS to boot if the handler is enabled without
rebooting first.
## External links
* [A Tour Beyond BIOS Implementing UEFI Authenticated Variables in SMM with EDKI](https://software.intel.com/sites/default/files/managed/cf/ea/a_tour_beyond_bios_implementing_uefi_authenticated_variables_in_smm_with_edkii.pdf)