Hi All,
Note you may have received another instance of this note but when I
attempted to send to all TF ML's simultaneously it seemed to fail, so
sending to each one at a time. Sorry about that. :/
We've created a Discord Server for real time chats/sharing. This solution
comes at no cost to the project, is set up with channels for each project,
includes a #general channel, and supports direct 1-1 chats between members,
all with the goal of improving collaboration between trustedfirmware.org
developers.
We encourage all to join! :) Instructions for joining can be found on
the TF.org
FAQ page <https://www.trustedfirmware.org/faq/>.
See you all there and please don't hesitate to reach out if you have any
questions!
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi All,
To all TF maillists in case all aren't yet aware.
We've created a Discord Server for real time chats/sharing. This solution
comes at no cost to the project, is set up with channels for each project,
includes a #general channel, and supports direct 1-1 chats between members,
all with the goal of improving collaboration between trustedfirmware.org
developers.
I've attached a recent screenshot from the #general channel as a sample of
the interface and usages.
We encourage all to join! :) Instructions for joining can be found on
the TF.org
FAQ page <https://www.trustedfirmware.org/faq/>.
See you all there and please don't hesitate to reach out if you have any
questions!
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello all,
We are started using Op-tee in our project.
Since we are new to Op-tee, could someone please confirm whether anyone has already tried below in their project or is it possible to use along with OpenSSH/OpenSSL ?
What we try to accomplish is: application/sshd -> openssl (libcrypto/provider) -> Optee (client/TA) -> (HW or SW cipher algorithm) for data encryption/decryption.
Thanks,
Hareesh
Hi everyone,
This is yet another attempt to come up with an RPMB API for the kernel.
This patch is based on patch 1 of last submission except few minor changes.
The last discussion of this was in the thread:
Subject: [PATCH v2 1/4] rpmb: add Replay Protected Memory Block (RPMB) subsystem
Date: Tue, 5 Apr 2022 10:37:56 +0100 [thread overview]
Message-ID: <20220405093759.1126835-2-alex.bennee(a)linaro.org>
The patch provides a simple RPMB driver. This is a RFC version and this
single driver can't be used by its own. It would require further work to
make use of API's provided by this driver.
Changes since the last posting:
drop RPMB char driver
drop virtio rpmb frontend driver
drop rpmb: add RPBM access tool
Rename get_write_count to get_write_counter
Make return type for rpmb_set_key() function explicit
Alex Bennée (1):
rpmb: add Replay Protected Memory Block (RPMB) driver
MAINTAINERS | 7 +
drivers/Kconfig | 1 +
drivers/Makefile | 2 +
drivers/rpmb/Kconfig | 11 ++
drivers/rpmb/Makefile | 7 +
drivers/rpmb/core.c | 439 ++++++++++++++++++++++++++++++++++++++++++
include/linux/rpmb.h | 182 +++++++++++++++++
7 files changed, 649 insertions(+)
create mode 100644 drivers/rpmb/Kconfig
create mode 100644 drivers/rpmb/Makefile
create mode 100644 drivers/rpmb/core.c
create mode 100644 include/linux/rpmb.h
--
2.34.1
Hi,
Time flies, on Tuesday, August 22 it's for another LOC monthly meeting. For
time and connection details see the calendar at
https://www.trustedfirmware.org/meetings/
I'm happy to report that the Xen patches needed to run OP-TEE with
FF-A have just been merged [1] and will be included in the next Xen
release. With this, we may need to focus more on for how long we may
hog the CPU with non-secure interrupts masked.
[1] https://patchew.org/Xen/20230731121536.934239-1-jens.wiklander@linaro.org/#…
Any other topics?
Thanks,
Jens
Hi,
I have u-boot based on u-boot 2021.04
I have configuration with fTPM of Microsoft enabled.
I have a EVB board with Nuvoton chip.
OPTee-OS is based on latest 3.22 upstream version with Nuvoton npcm
platform configuration.
If I take OPTee-OS without reading HUK from our PCR0 field from
non-secured memory,
the command works fine.
If I add reading HUK, the command fails.
Here is the error log:
-
U-Boot>tpm2 device
optee optee: OP-TEE: revision 3.22 (a012b992)
I/TC: Reserved shared memory is enabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
E/TC:0 0 std_entry_with_parg:235 Bad arg address 0x7fce2000
Couldn't set TPM 0 (rc = 1)
-
All other commands of tpm2 that are not connected to fTPM works OK.
After loading Linux, xtest works OK.
Could you please help me?
Thank you in advance,
Margarita Glushkin
This series introduces the tee based EFI Runtime Variable Service.
The eMMC device is typically owned by the non-secure world(linux in
this case). There is an existing solution utilizing eMMC RPMB partition
for EFI Variables, it is implemented by interacting with
OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
and tee-supplicant. The last piece is the tee-based variable access
driver to interact with OP-TEE and StandaloneMM.
Changelog:
v6 -> v7
Patch #1-#4 are not updated.
Patch #5 is added into this series, original patch is here:
https://lore.kernel.org/all/20230609094532.562934-1-ilias.apalodimas@linaro…
There are two issues in the v6 series and v7 series addresses those.
1) efivar ops is not restored when the tee-supplicant daemon terminates.
-> As the following patch says, user must remove the device before
terminating tee-supplicant daemon.
https://lore.kernel.org/all/20230728134832.326467-1-sumit.garg@linaro.org/
2) cause panic when someone remounts the efivarfs as RW even if
SetVariable is not supported
-> The fifth patch addresses this issue.
"[PATCH v7 5/5] efivarfs: force RO when remounting if SetVariable is
not supported"
Changelog:
v5 -> v6
- new patch #4 is added in this series, #1-#3 patches are unchanged.
automatically update super block flag when the efivarops support
SetVariable runtime service, so that user does not need to manually
remount the efivarfs as RW.
v4 -> v5
- rebase to efi-next based on v6.4-rc1
- set generic_ops.query_variable_info, it works as expected as follows.
$ df -h /sys/firmware/efi/efivars/
Filesystem Size Used Avail Use% Mounted on
efivarfs 16K 1.3K 15K 8% /sys/firmware/efi/efivars
v3 -> v4:
- replace the reference from EDK2 to PI Specification
- remove EDK2 source code reference comments
- prepare nonblocking variant of set_variable, it just returns
EFI_UNSUPPORTED
- remove redundant buffer size check
- argument name change in mm_communicate
- function interface changes in setup_mm_hdr to remove (void **) cast
v2 -> v3:
- add CONFIG_EFI dependency to TEE_STMM_EFI
- add missing return code check for tee_client_invoke_func()
- directly call efivars_register/unregister from tee_stmm_efi.c
rfc v1 -> v2:
- split patch into three patches, one for drivers/tee,
one for include/linux/efi.h, and one for the driver/firmware/efi/stmm
- context/session management into probe() and remove() same as other tee
client driver
- StMM variable driver is moved from driver/tee/optee to driver/firmware/efi
- use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c,
this file does not contain op-tee specific code, abstracted by tee layer and
StMM variable driver will work on other tee implementation.
- PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE
- implement query_variable_store() but currently not used
- no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h.
Other tee client drivers use 0 instead of using TEEC_SUCCESS
- remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output
error message
Ilias Apalodimas (1):
efivarfs: force RO when remounting if SetVariable is not supported
Masahisa Kojima (4):
efi: expose efivar generic ops register function
efi: Add EFI_ACCESS_DENIED status code
efi: Add tee-based EFI variable driver
efivarfs: automatically update super block flag
drivers/firmware/efi/Kconfig | 15 +
drivers/firmware/efi/Makefile | 1 +
drivers/firmware/efi/efi.c | 18 +
drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++
drivers/firmware/efi/stmm/tee_stmm_efi.c | 638 +++++++++++++++++++
drivers/firmware/efi/vars.c | 8 +
fs/efivarfs/super.c | 45 ++
include/linux/efi.h | 12 +
8 files changed, 973 insertions(+)
create mode 100644 drivers/firmware/efi/stmm/mm_communication.h
create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c
base-commit: 2e28a798c3092ea42b968fa16ac835969d124898
--
2.30.2