From 8aab755c31672c224bc1f628599c828a6075f247 Mon Sep 17 00:00:00 2001 From: Krystian Hebel Date: Fri, 28 Jun 2024 18:47:21 +0200 Subject: [PATCH] Documentation/drivers/smmstorev2.md: describe capsule update API 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 --- Documentation/drivers/smmstorev2.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/Documentation/drivers/smmstorev2.md b/Documentation/drivers/smmstorev2.md index 6956cd49e1..816f917dc1 100644 --- a/Documentation/drivers/smmstorev2.md +++ b/Documentation/drivers/smmstorev2.md @@ -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)