lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211001092939.heiskb5gqzx3nd7p@bogus>
Date:   Fri, 1 Oct 2021 10:29:39 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Jens Wiklander <jens.wiklander@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        op-tee@...ts.trustedfirmware.org,
        Sumit Garg <sumit.garg@...aro.org>,
        Marc Bonnici <marc.bonnici@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Jerome Forissier <jerome@...issier.org>,
        sughosh.ganu@...aro.org
Subject: Re: [PATCH v5 0/5] Add FF-A support in OP-TEE driver

On Tue, Aug 31, 2021 at 09:24:07AM +0200, Jens Wiklander wrote:
> Hi all,
> 
> This adds supports for the OP-TEE driver to communicate with secure world
> using FF-A [1] as transport.
> 
> There is one change to the TEE subsystem with "tee: add sec_world_id to
> struct tee_shm" to add support for holding globally unique handle assigned
> by the FF-A. This is a field that I believe could useful for the AMDTEE
> driver too.
> 
> For communication the OP-TEE message protocol is still used, but with a new
> type of memory reference, struct optee_msg_param_fmem, to carry the
> information needed by FF-A. The OP-TEE driver is refactored internally with
> to sets of callbacks, one for the old SMC based communication and another
> set with FF-A as transport. The functions relating to the SMC based ABI
> are moved to smc_abi.c while the FF-A based ABI is added in a ffa_abi.c.
> 
> There is also a difference in how the drivers are instantiated. With the
> SMC based transport we have a platform driver, module_platform_driver(),
> today which we're keeping as is for this configuration. In a FF-A system we
> have a FF-A driver, module_ffa_driver(), instead.
> 
> The OP-TEE driver can be compiled for both targets at the same time and
> it's up to runtime configuration (device tree or ACPI) to decide how it's
> initialized. Note that it's only the old SMC based driver instance that
> need device tree or ACPI to initialize. The FF-A based driver relies on the
> FF-A bus instead.
> 
> This can be tested QEMU
> The repo for SPMC at S-EL1 retrieved by
> repo init -u https://github.com/jenswi-linaro/manifest.git -m
> qemu_v8.xml -b ffav4_spmc
> repo sync
> # Then checkout the branch optee_ffa_v5 from
> # git://git.linaro.org/people/jens.wiklander/linux-tee.git
> # in the linux directory
> 
> To build do:
> cd build
> make toolchains
> make all
> 
> To boot:
> make run-only
> 
> Test with xtest, perhaps only with the command "xtest 1004" in case you're
> not interested in too many tests.
> 

Ran entire xtest test suite with latest TF-A, hafinum and OPTEE.
So for the series,

Tested-by:  Sudeep Holla <sudeep.holla@....com>

Minor comments to address OPTEE as module when FFA is also built as module.
FFA as a module couple of bugs(thanks for reporting one of them). I have the
fixes here[1], please test and provide feedback.

-- 
Regards,
Sudeep

[1] https://lore.kernel.org/linux-arm-kernel/20210924092859.3057562-1-sudeep.holla@arm.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ