Hi Heinrich,
>
> Hello Ilias, hello Ard,
>
> please, have a look at this patch:
>
> efi_loader: update virtual address in efi_mem_carve_out
> https://lists.denx.de/pipermail/u-boot/2019-April/364937.html
>
> Possibly the bug reported here could have contributed the Linux crash
> you
Hi Ard,
> >
> > This loads the fdt on c7ef4000 (which is more than a page). Changing
> > the address from 0x7f0 to 7EFF000, on the original code, works as
> > well
> >
> > Kernel's EFI map (with the patch) :
> > [0.00] efi: Processing EFI memory map:
> > [0.00] efi:
Following Ard's suggestion:
Runtime data sections are intended for data that is used by the runtime
services implementations.
Let's change they type to EFI_ACPI_RECLAIM_MEMORY
Suggested-by: Ard Biesheuvel
Signed-off-by: Ilias Apalodimas
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions
Hi Ard,
> On Thu, 11 Apr 2019 at 11:39, Ilias Apalodimas
> wrote:
> >
> > Following Ard's suggestion:
> > Runtime data sections are intended for data that is used by the runtime
> > services implementations.
> > Let's change they type to EFI_ACPI_RECL
Following Ard's suggestion:
Runtime data sections are intended for data that is used by the runtime
services implementation.
Let's change the type to EFI_BOOT_SERVICES_DATA
This also fixes booting of armv7 using efi and fdtcontroladdr
Suggested-by: Ard Biesheuvel
Signed-off-by: Ilias Apalodimas
> + ("Device tree not marked as boot services data\n");
> return EFI_ST_FAILURE;
> }
> return EFI_ST_SUCCESS;
> --
> 2.20.1
>
I probably should have updated that myself. Thanks for catching this
Reviewed-by: Ilias Apalodimas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Heinrich,
> On 4/11/19 8:39 PM, Ilias Apalodimas wrote:
> >Following Ard's suggestion:
> >Runtime data sections are intended for data that is used by the runtime
> >services implementations.
> >Let's change they type to EFI_ACPI_RECLAIM_MEMORY
> >
> >Sugg
flag,
>
> guid = efi_global_variable_guid;
> ret = EFI_CALL(RT->set_variable(L"BootOrder", ,
> + EFI_VARIABLE_NON_VOLATILE |
> EFI_VARIABLE_BOOTSERVICE_ACCESS |
>
oad BootNext */
> if (ret == EFI_SUCCESS) {
Acked-by: Ilias Apalodimas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Akashi-san
Thanks for doing this!
[...]
> + return 0;
> +}
> +
> +int env_efi_save(void)
> +{
> +#ifdef CONFIG_ENV_IS_NOWHERE
One of the 'features' we discussed is the ability to have CONFIG_ENV_IS_NOWHERE
set (not allowing users to change the U-Boot ENV) and still be able to store
UEFI
Heinrich,
[...]
> > Unfortunately, this is not practical right now because there is
> > already some sort of assumption (and consensus) that we would re-use
> > "Standalone MM services", which is already there in EDK2, as
> > secure storage for UEFI variables.
> > In the case,
Dear Wolfgang,
> >
> > thanks a lot for the good online meeting this morning together with your
> > colleague Suggan where we discussed the requirements for the
> > implementation of non-volatile variables in U-Boot.
> >
> > Currently UEFI variables are stored in U-Boot variables. Saving the
> >
Hi Heinrich,
(+ Sughosh and Francois)
On Thu, 20 Jun 2019 at 11:06, Heinrich Schuchardt wrote:
>
> Hello Ilias,
>
> thanks a lot for the good online meeting this morning together with your
> colleague Suggan where we discussed the requirements for the
> implementation of non-volatile variables
Hi all,
[...]
> > >>I think one version of the functions serving at runtime and boottime is
> > >>enough.
> > >>
> > >>The cache should be used both at runtime and at boottime.
> > >
> > >So do you mean that we should replace the existing "boottime" version
> > >of get/set_variable with my code
Hi Tom,
> > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > Hello Wolfgang,
> >
> > Thanks for taking the time with this
> > > >
> > > > There is LibreSSL as well which is a fork of openssl. Guess that too
> > > > should
> > > > be fine. What would be the more preferred
On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
Hello Wolfgang,
Thanks for taking the time with this
> >
> > There is LibreSSL as well which is a fork of openssl. Guess that too should
> > be fine. What would be the more preferred solution here. The relevant bits
> > can be
Hello Heinrich,
>
> @Simon, @Alex
> Why did we ever introduce this value?
> 127 MB in baf70c02107 ("efi: Relocate FDT to 127MB instead of 128MB")
> 128 MB in ad0c1a3d2ce ("efi_loader: Put fdt into convenient location")
>
> baf70c02107 says that the Sandbox has only 128 MiB. But why should we
>
Hi Alexander, Heinrich,
(Resending since i was too quick on the trigger forgot to cc the public
mailing list. Sorry for the mess)
I can't get an armv7 board (STM32MP157C-DK2) to boot with bootefi on
specific kernel/uboot configurations.
u-boot version: U-Boot 2019.04-rc3
kernel version:
> On 4/10/19 6:57 PM, Ilias Apalodimas wrote:
> >Hi Alexander, Heinrich,
> >
> >(Resending since i was too quick on the trigger forgot to cc the public
> >mailing list. Sorry for the mess)
> >
> >I can't get an armv7 board (STM32MP157C-DK2) to boot w
Dear Wolfgang,
On Tue, 25 Jun 2019 at 12:27, Wolfgang Denk wrote:
>
> Dear Ilias,
>
> In message <20190625091140.GA19606@apalos> you wrote:
> >
> > > > Currently UEFI variables are stored in U-Boot variables. Saving the
> > > > U-Boot variables will persist all UEFI variables in the environment
Dear Wolfgang, Akashi-san,
On Thu, Jun 27, 2019 at 02:15:19PM +0900, AKASHI Takahiro wrote:
> Wolfgang,
>
> I think that we are getting much closer than a few days ago,
> but first let me explain one point that I'm afraid that you
> might misunderstand somehow:
>
> On Wed, Jun 26, 2019 at
1 /* virtio net */
> #define VIRTIO_ID_BLOCK 2 /* virtio block */
> -#define VIRTIO_ID_MAX_NUM3
> +#define VIRTIO_ID_RNG4 /* virtio rng */
> +#define VIRTIO_ID_MAX_NUM5
>
> #define VIRTIO_NET_DRV_NAME "virtio-net"
> #define VIRTIO_BLK_DRV_NAME "virtio-blk"
> +#define VIRTIO_RNG_DRV_NAME "virtio-rng"
>
> /* Status byte for guest to report progress, and synchronize features */
>
> --
> 2.7.4
>
Tested-by: Ilias Apalodimas
> + * dm_rng_read() - read a random number seed from the rng device
> + * @buffer: input buffer to put the read random seed into
> + * @size:number of bytes of random seed read
> + *
> + */
> +int dm_rng_read(struct udevice *dev, void *buffer, size_t size);
> +
> +/* struct dm_rng_ops - Operations for the hwrng uclass */
> +struct dm_rng_ops {
> + /**
> + * @read() - read a random number seed
> + *
> + * @data: input buffer to read the random seed
> + * @max:total number of bytes to read
> + */
> + int (*read)(struct udevice *dev, void *data, size_t max);
> +};
> +
> +#endif /* _RNG_H_ */
> --
> 2.7.4
>
Tested-by: Ilias Apalodimas
[...]
> + /* verify signature */
> + /* against digest */
> + c = 0x31;
> + regtmp[0].data =
> + regtmp[0].size = 1;
Is there a reason for '1' instea of sizeof(c)?
> + regtmp[1].data = ps_info->authattrs;
> +
conftest.py| 151 +++
> test/py/tests/test_efi_secboot/defs.py| 21 +
> .../py/tests/test_efi_secboot/test_authvar.py | 282 ++
> test/py/tests/test_efi_secboot/test_signed.py | 99 ++
> .../tests/test_efi_secboot/test_unsigned.py | 103 ++
> 21 files changed, 3032 insertions(+), 128 deletions(-)
> create mode 100644 lib/efi_loader/efi_signature.c
> create mode 100644 test/py/tests/test_efi_secboot/conftest.py
> create mode 100644 test/py/tests/test_efi_secboot/defs.py
> create mode 100644 test/py/tests/test_efi_secboot/test_authvar.py
> create mode 100644 test/py/tests/test_efi_secboot/test_signed.py
> create mode 100644 test/py/tests/test_efi_secboot/test_unsigned.py
>
> --
> 2.24.0
>
I managed to test the functionality using SHA256 in 'db'.
For that part
Tested-by: Ilias Apalodimas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Akashi-san,
On Tue, Nov 26, 2019 at 09:51:08AM +0900, AKASHI Takahiro wrote:
> efi_signature_parse_sigdb() is a helper function will be used to parse
> signature database variable and instantiate a signature store structure
> in later patches.
>
> Signed-off-by: AKASHI Takahiro
> ---
>
On Thu, Nov 28, 2019 at 04:21:01PM +0200, Ilias Apalodimas wrote:
> Akashi-san,
>
> On Tue, Nov 26, 2019 at 09:51:08AM +0900, AKASHI Takahiro wrote:
> > efi_signature_parse_sigdb() is a helper function will be used to parse
> > signature database variable and instanti
On Fri, Sep 06, 2019 at 04:08:07PM +0900, AKASHI Takahiro wrote:
> In the current implementation of FIT_SIGNATURE, five parameters for
> a RSA public key are required while only two of them are essential.
> (See rsa-mod-exp.h and uImage.FIT/signature.txt)
> This is a result of considering
d
> >>> EFI boot manager: Cannot load any image
> >>>
> >>> How to define BootOrder?
> >>>
> >>> Thanks,
> >>> Michal
> >>
> >> # Booting via boot manager
> >>
> >> U-Boot currently has no runtime sup
eters on your board::
> +
> +==> efidebug boot add 1 HELLO mmc 0:1 /helloworld.efi.signed ""
> +
> +Then your board runs that image from Boot manager (See below).
> +You can also try this sequence by running Pytest, test_efi_secboot,
> +on sandbox::
> +
> +$ cd
> +$ pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox
> +
> Executing the boot manager
> ~~
>
> --
> 2.24.0
>
Acked-by: Ilias Apalodimas
g up 'load initrd'
Setting up 'load initrd' succeeded
Executing 'load initrd'
Loaded 12378613 bytes
CRC32 2997478465
Executing 'load initrd' succeeded
Now the size and CRC32 can be compared to the provided file.
Signed-off-by: Ilias Apalodimas
Signed-off-by: Heinrich Schuchardt
in the future if needed and configure that via ENV
or UEFI variable.
[1]
https://lore.kernel.org/linux-efi/20200207202637.ga3464...@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f
Signed-off-by: Ilias Apalodimas
Signed-off-by: Heinrich Schuchardt
---
cmd/efidebug.c
On Thu, Jan 09, 2020 at 01:08:35AM +0100, Heinrich Schuchardt wrote:
> On 12/18/19 1:44 AM, AKASHI Takahiro wrote:
> > One of major missing features in current UEFI implementation is "secure
> > boot."
> > The ultimate goal of my attempt is to implement image authentication based
> > on signature
[...]
> > > If we implement secure boot according the UEFI specification, one option
> > > would be to package the device tree as a UEFI driver image and let the
> > > stub install it as a configuration table. The unload callback could be
> > > used to remove the device tree.
> > >
> >
> >
On Thu, Jan 09, 2020 at 08:09:27PM +0100, Heinrich Schuchardt wrote:
> On 1/9/20 9:02 AM, Ilias Apalodimas wrote:
> > On Thu, Jan 09, 2020 at 01:08:35AM +0100, Heinrich Schuchardt wrote:
> > > On 12/18/19 1:44 AM, AKASHI Takahiro wrote:
> > > > One of major mi
Akashi-san,
On Thu, Mar 12, 2020 at 02:28:45PM +0900, AKASHI Takahiro wrote:
> Ilias,
>
> I haven't followed this thread.
>
> On Fri, Feb 21, 2020 at 09:55:45AM +0200, Ilias Apalodimas wrote:
> > Following kernel's proposal for an arch-agnostic initrd loading
> > me
On Thu, Mar 12, 2020 at 03:58:03PM +0900, AKASHI Takahiro wrote:
> On Thu, Mar 12, 2020 at 08:29:38AM +0200, Ilias Apalodimas wrote:
> > Akashi-san,
> >
> > On Thu, Mar 12, 2020 at 02:28:45PM +0900, AKASHI Takahiro wrote:
> > > Ilias,
> > >
On Fri, Mar 27, 2020 at 11:30:47AM +0100, Heinrich Schuchardt wrote:
> On 3/27/20 9:07 AM, Punit Agrawal wrote:
> > Heinrich Schuchardt writes:
> >
> > > Persist non-volatile UEFI variables in a file on the EFI system partition.
> > >
> > > The file is written:
> > >
> > > * whenever a
On Wed, Apr 01, 2020 at 04:04:04PM +0900, AKASHI Takahiro wrote:
> >
[...]
> > Yes, we may add further stores later on.
>
> Why not now?
> How will you generalize it?
>
> > Ilias wants to use the RPMB
> > area of eMMC devices.
>
> I think that he plans to use RPMB as secure storage for
ps
> diff --git a/doc/index.rst b/doc/index.rst
> index cd98be6cc5..fd9f10f28e 100644
> --- a/doc/index.rst
> +++ b/doc/index.rst
> @@ -26,6 +26,17 @@ trying to get it to work optimally on a given system.
>
> build/index
>
> +Developer-oriented documentation
> +
> +
> +The following manuals are written for *developers* of the U-Boot - those who
> +want to contribute to U-Boot.
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + develop/index
> +
> Unified Extensible Firmware (UEFI)
> --
>
> --
> 2.26.2
>
Acked-by: Ilias Apalodimas
>
> %s/SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE/SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE./
>
> > + * @size: vendor GUID
[...]
> > + * @name_size: size of the name of the variable
> > + * @name: variable name
> > + *
> > + * Defined in EDK2 as
On Mon, May 11, 2020 at 08:54:04PM +0200, Heinrich Schuchardt wrote:
> On 5/11/20 8:14 PM, Ilias Apalodimas wrote:
> > With the previous patches that use OP-TEE and StandAloneMM for UEFI
> > variable storage we've added functionality for efi_query_variable_info.
> > So l
Hi Heinrich
On Mon, May 11, 2020 at 09:39:51PM +0200, Heinrich Schuchardt wrote:
> On 5/11/20 8:13 PM, Ilias Apalodimas wrote:
> > +
[...]
> > +/*
> > + * Interface to the pseudo TA, which provides a communication channel with
>
> U-Boot developers might not know t
On Wed, May 13, 2020 at 08:14:19AM +0200, Heinrich Schuchardt wrote:
> On 5/11/20 8:14 PM, Ilias Apalodimas wrote:
> > In OP-TEE we can run EDK2's StandAloneMM on a secure partition.
> > StandAloneMM is responsible for the UEFI variable support. In
> > +
[...]
> > +
ed-off-by: Ilias Apalodimas
Reviewed-by: Heinrich Schuchardt
---
include/mm_communication.h | 208 +
1 file changed, 208 insertions(+)
create mode 100644 include/mm_communication.h
diff --git a/include/mm_communication.h b/include/mm_communication.h
new fil
Previous patches allow UEFI secure variables to be stored in an RPMB
device using OPTEE. Add a config for the lx2160a hardware so the feature
gets at least compiled.
Signed-off-by: Ilias Apalodimas
---
board/freescale/lx2160a/MAINTAINERS | 1 +
configs/lx2160ardb_tfa_stmm_defconfig | 85
With the previous patches that use OP-TEE and StandAloneMM for UEFI
variable storage we've added functionality for efi_query_variable_info.
So let's add the relevant command to efidebug and retrieve information
about the container used to store UEFI variables
Signed-off-by: Ilias Apalodimas
Add myself as maintainer for the OP-TEE related UEFI variable storage.
Signed-off-by: Ilias Apalodimas
Reviewed-by: Heinrich Schuchardt
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d67112479700..8add9d4c2ae9 100644
--- a/MAINTAINERS
in U-Boot implementing the necessary
calls to OP-TEE for the variable management.
Signed-off-by: Ilias Apalodimas
Signed-off-by: Pipat Methavanitpong
Signed-off-by: Sughosh Ganu
Reviewed-by: Heinrich Schuchardt
---
lib/efi_loader/Kconfig| 9 +
lib/efi_loader/Makefile
A defconfig is added on lx2160ardb which allows UEFI variable management
via OP-TEE. Enable the the node in the relevant DTS file.
Signed-off-by: Ilias Apalodimas
---
arch/arm/dts/fsl-lx2160a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm
.html
Ilias Apalodimas (6):
efi_loader: Implement EFI variable handling via OP-TEE
cmd: efidebug: Add support for querying UEFI variable storage
MAINTAINERS: Add maintainer for EFI variables via OP-TEE
doc: uefi.rst: Add OP-TEE variable storage config options
configs: lx2160a: Add default
If OP-TEE is compiled with an EDK2 application running in secure world
it can process and store UEFI variables in an RPMB.
Add documentation for the config options enabling this.
Signed-off-by: Ilias Apalodimas
Reviewed-by: Heinrich Schuchardt
---
doc/uefi/uefi.rst | 17 +
1
ed-off-by: Ilias Apalodimas
---
include/mm_communication.h | 28 ++
include/mm_variable.h | 78 ++
2 files changed, 106 insertions(+)
create mode 100644 include/mm_communication.h
create mode 100644 include/mm_variable.h
diff --git a/i
in U-Boot implementing the necessary
calls to OP-TEE for the variable management.
Signed-off-by: Ilias Apalodimas
Signed-off-by: Pipat Methavanitpong
Signed-off-by: Sughosh Ganu
---
lib/efi_loader/Kconfig| 9 +
lib/efi_loader/Makefile | 4 +
lib/efi_loader
If OP-TEE is compiled with an EDK2 application running in secure world
it can process and store UEFI variables in an RPMB.
Add documentation for the config options enabling this
Signed-off-by: Ilias Apalodimas
---
doc/uefi/uefi.rst | 10 ++
1 file changed, 10 insertions(+)
diff --git
n U-Boot and OP-TEE and StandAloneMM
to perform the variable storage.
[1] https://github.com/apalos/optee_os/tree/stmm_upstream_03_clean
[2]
https://git.linaro.org/people/ilias.apalodimas/edk2-platforms.git/log/?h=patch_pcd
Ilias Apalodimas (4):
efi_loader: Implement EFI variable handling via OP-TEE
From: Sughosh Ganu
The current code uses 'u16_strlen(x) + 1) * sizeof(u16)' in various
places to calculate the number of bytes occupied by a u16 string.
Let's introduce a wrapper around this. This wrapper is used on following
patches
Signed-off-by: Sughosh Ganu
---
include/charset.h | 11
Add myself as maintainer for the OP-TEE related UEFI variable storage
and add the headers files on the existing EFI list
Signed-off-by: Ilias Apalodimas
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ec59ce8b8802..f33fd74b330b 100644
With the previous patches that use OP-TEE and StandAloneMM for UEFI
variable storage we've added functionality for efi_query_variable_info.
So let's add the relevant command to efidebug and retrieve information
about the container used to store UEFI variables
Signed-off-by: Ilias Apalodimas
Hi Heinrich,
On Sat, May 09, 2020 at 11:14:51AM +0200, Heinrich Schuchardt wrote:
> On 5/6/20 9:12 PM, Ilias Apalodimas wrote:
> > In OP-TEE we can run EDK2's StandAloneMM on a secure partition.
> > StandAloneMM is responsible for the UEFI variable support. In
> > combination
On Sat, May 09, 2020 at 11:17:59AM +0200, Heinrich Schuchardt wrote:
> On 5/6/20 9:12 PM, Ilias Apalodimas wrote:
> > Add myself as maintainer for the OP-TEE related UEFI variable storage
> > and add the headers files on the existing EFI list
> >
> > Sign
On Sat, May 09, 2020 at 11:14:51AM +0200, Heinrich Schuchardt wrote:
> > + in_name_size = u16_strsize(variable_name);
[...]
>
> The UEFI spec requires: "The size must be large enough to fit input
> string supplied in VariableName buffer."
>
> Further it is required to return
On Sat, May 09, 2020 at 10:12:25AM +0200, Heinrich Schuchardt wrote:
> On 5/6/20 9:12 PM, Ilias Apalodimas wrote:
> > From: Sughosh Ganu
> >
> > In Arm devices OP-TEE has the ability to run StandAloneMM (from EDK2)
> > in a separate partition and handle UEFI varia
On Sat, May 09, 2020 at 11:58:17AM +0200, Heinrich Schuchardt wrote:
> On 5/6/20 9:12 PM, Ilias Apalodimas wrote:
> > +
[...]
> > + printf("%.*s \n", EFI_HANDLE_WIDTH, sep);
>
> We are not printing handles. Please remove the line.
>
Ok
On Sat, May 09, 2020 at 11:51:48AM +0200, Heinrich Schuchardt wrote:
> On 5/6/20 9:12 PM, Ilias Apalodimas wrote:
> > If OP-TEE is compiled with an EDK2 application running in secure world
> > it can process and store UEFI variables in an RPMB.
> > Add documentation for the co
On Fri, May 15, 2020 at 01:55:35PM +0200, Heinrich Schuchardt wrote:
> On 11.05.20 20:14, Ilias Apalodimas wrote:
> > In OP-TEE we can run EDK2's StandAloneMM on a secure partition.
> > StandAloneMM is responsible for the UEFI variable support. In
> > combination with O
arguments to define attributes for
efidebug query command
[1] https://lists.denx.de/pipermail/u-boot/2020-May/410772.html
[2] https://lists.denx.de/pipermail/u-boot/2020-May/411603.html
Ilias Apalodimas (5):
efi_loader: Implement EFI variable handling via OP-TEE
cmd: efidebug: Add
With the previous patches that use OP-TEE and StandAloneMM for UEFI
variable storage we've added functionality for efi_query_variable_info.
So let's add the relevant command to efidebug and retrieve information
about the container used to store UEFI variables
Signed-off-by: Ilias Apalodimas
ed-off-by: Ilias Apalodimas
Reviewed-by: Heinrich Schuchardt
---
include/mm_communication.h | 208 +
1 file changed, 208 insertions(+)
create mode 100644 include/mm_communication.h
diff --git a/include/mm_communication.h b/include/mm_communication.h
new fil
Add myself as maintainer for the OP-TEE related UEFI variable storage.
Signed-off-by: Ilias Apalodimas
Reviewed-by: Heinrich Schuchardt
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ec59ce8b8802..0c38890be09c 100644
--- a/MAINTAINERS
in U-Boot implementing the necessary
calls to OP-TEE for the variable management.
Signed-off-by: Ilias Apalodimas
Signed-off-by: Pipat Methavanitpong
Signed-off-by: Sughosh Ganu
---
lib/efi_loader/Kconfig| 9 +
lib/efi_loader/Makefile | 4 +
lib/efi_loader
Previous patches allow UEFI secure variables to be stored in an RPMB
device using OPTEE. Add a config for the lx2160a hardware so the feature
gets at least compiled.
Signed-off-by: Ilias Apalodimas
---
configs/lx2160ardb_tfa_stmm_defconfig | 78 +++
1 file changed, 78
If OP-TEE is compiled with an EDK2 application running in secure world
it can process and store UEFI variables in an RPMB.
Add documentation for the config options enabling this.
Signed-off-by: Ilias Apalodimas
Reviewed-by: Heinrich Schuchardt
---
doc/uefi/uefi.rst | 17 +
1
If OP-TEE is compiled with an EDK2 application running in secure world
it can process and store UEFI variables in an RPMB.
Add documentation for the config options enabling this
Signed-off-by: Ilias Apalodimas
---
doc/uefi/uefi.rst | 17 +
1 file changed, 17 insertions(+)
diff
With the previous patches that use OP-TEE and StandAloneMM for UEFI
variable storage we've added functionality for efi_query_variable_info.
So let's add the relevant command to efidebug and retrieve information
about the container used to store UEFI variables
Signed-off-by: Ilias Apalodimas
in U-Boot implementing the necessary
calls to OP-TEE for the variable management.
Signed-off-by: Ilias Apalodimas
Signed-off-by: Pipat Methavanitpong
Signed-off-by: Sughosh Ganu
---
lib/efi_loader/Kconfig| 9 +
lib/efi_loader/Makefile | 4 +
lib/efi_loader
'efidebug query' help message
* patch #5
- Move mm_communication.h maintenership
* patch #6
- Heinrich's suggestion, on the help file, was a lot cleaner and easier
to understand. Using it as-is
[1] https://lists.denx.de/pipermail/u-boot/2020-May/410772.html
Ilias Apalodimas (4
ed-off-by: Ilias Apalodimas
---
include/mm_communication.h | 207 +
1 file changed, 207 insertions(+)
create mode 100644 include/mm_communication.h
diff --git a/include/mm_communication.h b/include/mm_communication.h
new file mode 100644
index 00
Add myself as maintainer for the OP-TEE related UEFI variable storage
and add the headers file on the existing EFI list
Signed-off-by: Ilias Apalodimas
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ec59ce8b8802..0c38890be09c 100644
Akashi-san,
On Wed, Mar 18, 2020 at 10:53:45AM +0900, AKASHI Takahiro wrote:
> On Tue, Mar 17, 2020 at 08:37:47AM +0100, Heinrich Schuchardt wrote:
> > On 3/17/20 3:12 AM, AKASHI Takahiro wrote:
> > > There are platforms on which OS's won't be able to access UEFI variables
> > > at runtime (i.e.
On Wed, Mar 18, 2020 at 10:32:38AM +0900, AKASHI Takahiro wrote:
> On Tue, Mar 17, 2020 at 08:58:55AM +0100, Heinrich Schuchardt wrote:
> > On 3/17/20 3:12 AM, AKASHI Takahiro wrote:
> > > This is a utility mainly for test purpose.
> > >mkeficapsule -f: create a FIT image firmware capsule
> >
+UNICODE_TEST(unicode_test_u16_strsize);
> +
> int do_ut_unicode(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> {
> struct unit_test *tests = ll_entry_start(struct unit_test,
> unicode_test);
> --
> 2.26.2
>
Acked-by: Ilias Apalodimas
oader/efi_var_mem.c
> @@ -211,7 +211,7 @@ static void efi_var_mem_bs_del(void)
> * @event: callback event
> * @context: callback context
> */
> -static void EFIAPI __efi_runtime
> +static void EFIAPI
> efi_var_mem_notify_exit_boot_services(struct efi_event *event,
Hi Grant,
[...]
> > >
> > > Hi Heinrich,
> > >
> > > I've got concerns about this approach. Even though it uses the UEFI
> > > infrastructure, images deployed in this way are U-Boot specific and
> > > won't ever be applicable on EDK2 or other UEFI implementations.
> > >
> > > However there is
On Sat, Oct 03, 2020 at 03:12:30PM +0200, Ard Biesheuvel wrote:
> On Sat, 3 Oct 2020 at 13:16, François Ozog wrote:
>
> >
> >> that looks super interesting.
[...]
> >> I propose something (in the latest desk preparing oct 14th) similar
> >> except the an efi application boots the FIT.
> >> I
On Fri, 16 Oct 2020 at 13:17, Heinrich Schuchardt wrote:
>
> On 10/16/20 8:17 AM, Ilias Apalodimas wrote:
> > On Fri, 16 Oct 2020 at 03:23, Heinrich Schuchardt
> > wrote:
>
> You suggested to apply the following patch:
>
> >>
> >> diff --git a/l
efi_status_t efi_initrd_register(void)
> {
> efi_handle_t efi_initrd_handle = NULL;
> efi_status_t ret;
>
> - /*
> - * Set up the handle with the EFI_LOAD_FILE2_PROTOCOL which Linux may
> - * use to load the initial ramdisk.
> - */
> ret = EFI_CALL(efi_install_multiple_protocol_interfaces
> (_initrd_handle,
> /* initramfs */
> --
> 2.28.0
>
Reviewed-by: Ilias Apalodimas
(unsigned int)crc32);
>
> status = boottime->free_pool(buf);
> if (status != EFI_SUCCESS) {
> --
> 2.28.0
>
Reviewed-by: Ilias Apalodimas
, " ");
> + file = strsep(, " ");
> if (!file)
> goto out;
>
> @@ -170,7 +171,7 @@ efi_load_file2_initrd(struct efi_load_file_protocol *this,
> }
>
> out:
> - free(s);
> + free(filespec);
> return EFI_EXIT(status);
> }
>
> --
> 2.28.0
>
Not changing the variable names would make this an one liner to read.
The changes do make sense though so
Reviewed-by: Ilias Apalodimas
+cc Mark
On Thu, 22 Oct 2020 at 01:04, Ilias Apalodimas
wrote:
>
> Order header files according to https://www.denx.de/wiki/U-Boot/CodingStyle
>
> Signed-off-by: Ilias Apalodimas
> Suggested-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_boottime.c | 7 +++
+cc Mark
On Thu, 22 Oct 2020 at 01:04, Ilias Apalodimas
wrote:
>
> U-Boot Driver Model is supposed to remove devices with either
> DM_REMOVE_ACTIVE_DMA or DM_REMOVE_OS_PREPARE flags set, before exiting.
> Our bootm command does that by explicitly calling calling
> "dm_
y to probe the device again we are getting
a busy error response. Moreover all uclass (*preremove) functions won't
run.
So let's fix this by mimicking what bootm does and disconnect devices
when efi_exit_boot_services() is called.
Signed-off-by: Ilias Apalodimas
---
changes since v1:
- Add a pat
Order header files according to https://www.denx.de/wiki/U-Boot/CodingStyle
Signed-off-by: Ilias Apalodimas
Suggested-by: Heinrich Schuchardt
---
lib/efi_loader/efi_boottime.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib
aders for EDK2 StandAloneMM
communication")
Signed-off-by: Ilias Apalodimas
---
Changes since v1:
- v1 was efi_loader: Correct value for ARM_SMC_MM_RET_NO_MEMORY
- Renamed all the definitions according to EDK2
include/mm_communication.h| 16
lib/efi_loader/efi_variable_
efi_get_next_variable_name_int(), fix an indentation
error along the way.
Fixes: f042e47e8fb43 ("efi_loader: Implement EFI variable handling via OP-TEE")
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_variable_tee.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/lib/
() and tee_close_session()
before exiting with an error to make sure we always clear the registered
memory.
Fixes: f042e47e8fb43 ("efi_loader: Implement EFI variable handling via OP-TEE")
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_variable_tee.c | 4 ++--
1 file changed, 2 insertions(+), 2
A previous commit adds support for displaying variables RO flag.
Let's add it on the TEE backed variable storage as well.
Signed-off-by: Ilias Apalodimas
---
- Depends on https://lists.denx.de/pipermail/u-boot/2020-July/419269.html
include/mm_communication.h| 39
lib
Hi Heinrich
On Wed, Jul 08, 2020 at 06:29:34PM +0200, Heinrich Schuchardt wrote:
> Saving UEFI variable as encoded U-Boot environment variables does not allow
> implement run-time support.
>
> Use a memory buffer for storing UEFI variables.
>
> Signed-off-by: Heinrich Schuchardt
> ---
>
Hi Heinrich,
the TEE side looks fine to me, but I can't apply this to current master
Thanks
/Ilias
On Tue, Jul 07, 2020 at 05:11:44AM +0200, Heinrich Schuchardt wrote:
> We currently have two implementations of UEFI variables:
>
> * variables provided via an OP-TEE module
> * variables stored
On Tue, 7 Jul 2020 at 16:10, wrote:
>
> On Tue, Jul 07, 2020 at 05:11:59AM +0200, Heinrich Schuchardt wrote:
> > Enable UEFI variables at runtime.
> >
> > Signed-off-by: Heinrich Schuchardt
> > ---
> > lib/efi_loader/efi_runtime.c | 2 ++
> > lib/efi_loader/efi_variable.c | 6 --
> > 2
1 - 100 of 2145 matches
Mail list logo
