<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/lib/efi_loader/efi_variable_tee.c, branch v2024.10</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>efi_loader: enable QueryVariableInfo at runtime for file backed variables</title>
<updated>2024-05-01T05:40:05+00:00</updated>
<author>
<name>Ilias Apalodimas</name>
<email>ilias.apalodimas@linaro.org</email>
</author>
<published>2024-04-25T05:18:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9677192c145f2144592892f13de0e2069bcdf4ba'/>
<id>9677192c145f2144592892f13de0e2069bcdf4ba</id>
<content type='text'>
Since commit c28d32f946f0 ("efi_loader: conditionally enable SetvariableRT")
we are enabling the last bits of missing runtime services.
Add support for QueryVariableInfo which we already support at boottime
and we just need to mark some fucntions available at runtime and move
some checks around.

It's worth noting that pointer checks for maxmimum and remaining
variable storage aren't when we store variables on the RPMB, since the
Secure World backend is already performing them.

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since commit c28d32f946f0 ("efi_loader: conditionally enable SetvariableRT")
we are enabling the last bits of missing runtime services.
Add support for QueryVariableInfo which we already support at boottime
and we just need to mark some fucntions available at runtime and move
some checks around.

It's worth noting that pointer checks for maxmimum and remaining
variable storage aren't when we store variables on the RPMB, since the
Secure World backend is already performing them.

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: add an EFI variable with the file contents</title>
<updated>2024-04-20T06:22:24+00:00</updated>
<author>
<name>Ilias Apalodimas</name>
<email>ilias.apalodimas@linaro.org</email>
</author>
<published>2024-04-18T12:54:52+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=00da8d65a3baea8c3745367bea99b1d76f8f129c'/>
<id>00da8d65a3baea8c3745367bea99b1d76f8f129c</id>
<content type='text'>
Previous patches enabled SetVariableRT using a RAM backend.
Although EBBR [0] defines a variable format we can teach userspace tools
and write the altered variables, it's better if we skip the ABI
requirements completely.

So let's add a new variable, in its own namespace called "VarToFile"
which contains a binary dump of the updated RT, BS and, NV variables
and will be updated when GetVariable is called.

Some adjustments are needed to do that.
Currently we discard BS-only variables in EBS(). We need to preserve
those on the RAM backend that exposes the variables. Since BS-only
variables can't appear at runtime we need to move the memory masking
checks from efi_var_collect() to efi_get_next_variable_name_mem()/
efi_get_variable_mem() and do the filtering at runtime.

We also need an efi_var_collect() variant available at runtime, in order
to construct the "VarToFile" buffer on the fly.

All users and applications (for linux) have to do when updating a variable
is dd that variable in the file described by "RTStorageVolatile".

Linux efivarfs uses a first 4 bytes of the output to represent attributes
in little-endian format. So, storing variables works like this:

$~ efibootmgr -n 0001
$~ dd if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c of=/boot/efi/ubootefi.var skip=4 bs=1

[0] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage

Suggested-by: Ard Biesheuvel &lt;ardb@kernel.org&gt; # dumping all variables to a variable
Co-developed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt; # contributed on efi_var_collect_mem()
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previous patches enabled SetVariableRT using a RAM backend.
Although EBBR [0] defines a variable format we can teach userspace tools
and write the altered variables, it's better if we skip the ABI
requirements completely.

So let's add a new variable, in its own namespace called "VarToFile"
which contains a binary dump of the updated RT, BS and, NV variables
and will be updated when GetVariable is called.

Some adjustments are needed to do that.
Currently we discard BS-only variables in EBS(). We need to preserve
those on the RAM backend that exposes the variables. Since BS-only
variables can't appear at runtime we need to move the memory masking
checks from efi_var_collect() to efi_get_next_variable_name_mem()/
efi_get_variable_mem() and do the filtering at runtime.

We also need an efi_var_collect() variant available at runtime, in order
to construct the "VarToFile" buffer on the fly.

All users and applications (for linux) have to do when updating a variable
is dd that variable in the file described by "RTStorageVolatile".

Linux efivarfs uses a first 4 bytes of the output to represent attributes
in little-endian format. So, storing variables works like this:

$~ efibootmgr -n 0001
$~ dd if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c of=/boot/efi/ubootefi.var skip=4 bs=1

[0] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage

Suggested-by: Ard Biesheuvel &lt;ardb@kernel.org&gt; # dumping all variables to a variable
Co-developed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt; # contributed on efi_var_collect_mem()
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Remove &lt;common.h&gt;</title>
<updated>2023-12-21T13:54:37+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2023-12-14T18:16:55+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c38cb227d39f8ce9983df8051f31dcc8466f311e'/>
<id>c38cb227d39f8ce9983df8051f31dcc8466f311e</id>
<content type='text'>
We largely do not need &lt;common.h&gt; in these files, so drop it. The only
exception here is that efi_freestanding.c needs &lt;linux/types.h&gt; and had
been getting that via &lt;common.h&gt;.

Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We largely do not need &lt;common.h&gt; in these files, so drop it. The only
exception here is that efi_freestanding.c needs &lt;linux/types.h&gt; and had
been getting that via &lt;common.h&gt;.

Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_ffa: efi: introduce FF-A MM communication</title>
<updated>2023-08-08T14:22:03+00:00</updated>
<author>
<name>Abdellatif El Khlifi</name>
<email>abdellatif.elkhlifi@arm.com</email>
</author>
<published>2023-08-04T13:33:44+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=218b062e8f20233181ecbcca1d627f5d44c4617d'/>
<id>218b062e8f20233181ecbcca1d627f5d44c4617d</id>
<content type='text'>
Add MM communication support using FF-A transport

This feature allows accessing MM partitions services through
EFI MM communication protocol. MM partitions such as StandAlonneMM
or smm-gateway secure partitions which reside in secure world.

An MM shared buffer and a door bell event are used to exchange
the data.

The data is used by EFI services such as GetVariable()/SetVariable()
and copied from the communication buffer to the MM shared buffer.

The secure partition is notified about availability of data in the
MM shared buffer by an FF-A message (door bell).

On such event, MM SP can read the data and updates the MM shared
buffer with the response data.

The response data is copied back to the communication buffer and
consumed by the EFI subsystem.

MM communication protocol supports FF-A 64-bit direct messaging.

We tested the FF-A MM communication on the Corstone-1000 platform.

We ran the UEFI SCT test suite containing EFI setVariable, getVariable and
getNextVariable tests which involve FF-A MM communication and all tests
are passing with the current changes.

We made the SCT test reports (part of the ACS results) public following the
latest Corstone-1000 platform software release. Please find the test
reports at [1].

[1]: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip

Signed-off-by: Abdellatif El Khlifi &lt;abdellatif.elkhlifi@arm.com&gt;
Tested-by: Gowtham Suresh Kumar &lt;gowtham.sureshkumar@arm.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Cc: Tom Rini &lt;trini@konsulko.com&gt;
Cc: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Cc: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add MM communication support using FF-A transport

This feature allows accessing MM partitions services through
EFI MM communication protocol. MM partitions such as StandAlonneMM
or smm-gateway secure partitions which reside in secure world.

An MM shared buffer and a door bell event are used to exchange
the data.

The data is used by EFI services such as GetVariable()/SetVariable()
and copied from the communication buffer to the MM shared buffer.

The secure partition is notified about availability of data in the
MM shared buffer by an FF-A message (door bell).

On such event, MM SP can read the data and updates the MM shared
buffer with the response data.

The response data is copied back to the communication buffer and
consumed by the EFI subsystem.

MM communication protocol supports FF-A 64-bit direct messaging.

We tested the FF-A MM communication on the Corstone-1000 platform.

We ran the UEFI SCT test suite containing EFI setVariable, getVariable and
getNextVariable tests which involve FF-A MM communication and all tests
are passing with the current changes.

We made the SCT test reports (part of the ACS results) public following the
latest Corstone-1000 platform software release. Please find the test
reports at [1].

[1]: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip

Signed-off-by: Abdellatif El Khlifi &lt;abdellatif.elkhlifi@arm.com&gt;
Tested-by: Gowtham Suresh Kumar &lt;gowtham.sureshkumar@arm.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Cc: Tom Rini &lt;trini@konsulko.com&gt;
Cc: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Cc: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "Merge branch '2023-07-24-introduce-FF-A-suppport'"</title>
<updated>2023-07-24T23:51:05+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2023-07-24T23:51:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=94e7cb181ad6bd25d36a11c58e0df64e9f815888'/>
<id>94e7cb181ad6bd25d36a11c58e0df64e9f815888</id>
<content type='text'>
This reverts commit d927d1a80843e1c3e2a3f0b8f6150790bef83da1, reversing
changes made to c07ad9520c6190070513016fdb495d4703a4a853.

These changes do not pass CI currently.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit d927d1a80843e1c3e2a3f0b8f6150790bef83da1, reversing
changes made to c07ad9520c6190070513016fdb495d4703a4a853.

These changes do not pass CI currently.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_ffa: efi: introduce FF-A MM communication</title>
<updated>2023-07-24T19:30:03+00:00</updated>
<author>
<name>Abdellatif El Khlifi</name>
<email>abdellatif.elkhlifi@arm.com</email>
</author>
<published>2023-07-13T13:28:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=aabbc2f8b2a4e1a458a34b9ff5becb997c6157ff'/>
<id>aabbc2f8b2a4e1a458a34b9ff5becb997c6157ff</id>
<content type='text'>
Add MM communication support using FF-A transport

This feature allows accessing MM partitions services through
EFI MM communication protocol. MM partitions such as StandAlonneMM
or smm-gateway secure partitions which reside in secure world.

An MM shared buffer and a door bell event are used to exchange
the data.

The data is used by EFI services such as GetVariable()/SetVariable()
and copied from the communication buffer to the MM shared buffer.

The secure partition is notified about availability of data in the
MM shared buffer by an FF-A message (door bell).

On such event, MM SP can read the data and updates the MM shared
buffer with the response data.

The response data is copied back to the communication buffer and
consumed by the EFI subsystem.

MM communication protocol supports FF-A 64-bit direct messaging.

Signed-off-by: Abdellatif El Khlifi &lt;abdellatif.elkhlifi@arm.com&gt;
Tested-by: Gowtham Suresh Kumar &lt;gowtham.sureshkumar@arm.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Cc: Tom Rini &lt;trini@konsulko.com&gt;
Cc: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Cc: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add MM communication support using FF-A transport

This feature allows accessing MM partitions services through
EFI MM communication protocol. MM partitions such as StandAlonneMM
or smm-gateway secure partitions which reside in secure world.

An MM shared buffer and a door bell event are used to exchange
the data.

The data is used by EFI services such as GetVariable()/SetVariable()
and copied from the communication buffer to the MM shared buffer.

The secure partition is notified about availability of data in the
MM shared buffer by an FF-A message (door bell).

On such event, MM SP can read the data and updates the MM shared
buffer with the response data.

The response data is copied back to the communication buffer and
consumed by the EFI subsystem.

MM communication protocol supports FF-A 64-bit direct messaging.

Signed-off-by: Abdellatif El Khlifi &lt;abdellatif.elkhlifi@arm.com&gt;
Tested-by: Gowtham Suresh Kumar &lt;gowtham.sureshkumar@arm.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Cc: Tom Rini &lt;trini@konsulko.com&gt;
Cc: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Cc: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Set variable attributes when EFI_BUFFER_TOO_SMALL is returned</title>
<updated>2022-03-20T10:03:06+00:00</updated>
<author>
<name>Ilias Apalodimas</name>
<email>ilias.apalodimas@linaro.org</email>
</author>
<published>2022-03-16T15:13:37+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ff6af6eede200503c58250821d1285f94039eef7'/>
<id>ff6af6eede200503c58250821d1285f94039eef7</id>
<content type='text'>
Starting UEFI Spec 2.8 we must fill in the variable attributes when
GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL.

This code was written with 2.7 in mind so let's move the code around a
bit and fill in the attributes EFI_BUFFER_TOO_SMALL is returned

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Starting UEFI Spec 2.8 we must fill in the variable attributes when
GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL.

This code was written with 2.7 in mind so let's move the code around a
bit and fill in the attributes EFI_BUFFER_TOO_SMALL is returned

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Reviewed-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Use 16-bit unicode strings</title>
<updated>2022-02-03T17:16:01+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2022-01-23T19:55:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=156ccbc3c4581a1e6d29c51f4af4e120e30a2ef0'/>
<id>156ccbc3c4581a1e6d29c51f4af4e120e30a2ef0</id>
<content type='text'>
At present we use wide characters for unicode but this is not necessary.
Change the code to use the 'u' literal instead. This helps to fix build
warnings for sandbox on rpi.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Suggested-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
At present we use wide characters for unicode but this is not necessary.
Change the code to use the 'u' literal instead. This helps to fix build
warnings for sandbox on rpi.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Suggested-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: Don't limit the StMM buffer size explicitly</title>
<updated>2021-12-26T05:49:14+00:00</updated>
<author>
<name>Ilias Apalodimas</name>
<email>apalos@gmail.com</email>
</author>
<published>2021-12-24T08:08:41+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2b18d95d91c8d52a1971f93202c6b8212fa4f27e'/>
<id>2b18d95d91c8d52a1971f93202c6b8212fa4f27e</id>
<content type='text'>
Currently we allow and explicitly check a single shared page with
StandAloneMM.  This is dictated by OP-TEE which runs the application.
However there's no way for us dynamically discover the number of pages we
are allowed to use.  Since writing big EFI signature list variable
requires more than a page, OP-TEE has bumped the number of shared pages to
four.

Let's remove our explicit check and allow the request to reach OP-TEE even
if it's bigger than what it supports.  There's no need to sanitize the
number of pages internally.  OP-TEE will fail if we try to write more
than it's allowed. The error will just trigger later on,  during the
StMM access.

While at it add an error message to help users figure out what failed.

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Tested-by: Ying-Chun Liu (PaulLiu) &lt;paul.liu@linaro.org&gt;

Signed-off-by: Ilias Apalodimas &lt;apalos@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently we allow and explicitly check a single shared page with
StandAloneMM.  This is dictated by OP-TEE which runs the application.
However there's no way for us dynamically discover the number of pages we
are allowed to use.  Since writing big EFI signature list variable
requires more than a page, OP-TEE has bumped the number of shared pages to
four.

Let's remove our explicit check and allow the request to reach OP-TEE even
if it's bigger than what it supports.  There's no need to sanitize the
number of pages internally.  OP-TEE will fail if we try to write more
than it's allowed. The error will just trigger later on,  during the
StMM access.

While at it add an error message to help users figure out what failed.

Signed-off-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Tested-by: Ying-Chun Liu (PaulLiu) &lt;paul.liu@linaro.org&gt;

Signed-off-by: Ilias Apalodimas &lt;apalos@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi_loader: treat UEFI variable name as const</title>
<updated>2021-10-25T19:13:06+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2021-09-09T05:12:14+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d47671c631c3f3f3bbf0a33f6bf8afeebfe8c091'/>
<id>d47671c631c3f3f3bbf0a33f6bf8afeebfe8c091</id>
<content type='text'>
UEFI variable names are typically constants and hence should be defined as
const. Unfortunately some of our API functions do not define the parameters
for UEFI variable names as const. This requires unnecessary conversions.

Adjust parameters of several internal functions to tre UEFI variable names
as const.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
UEFI variable names are typically constants and hence should be defined as
const. Unfortunately some of our API functions do not define the parameters
for UEFI variable names as const. This requires unnecessary conversions.

Adjust parameters of several internal functions to tre UEFI variable names
as const.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
