From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent
Date: Sat, 6 Apr 2019 16:21:31 +0100 [thread overview]
Message-ID: <479d5fa5-e9dd-f45b-5db6-45b6bfdde791@linaro.org> (raw)
In-Reply-To: <1554480925-36-1-git-send-email-breno.lima@nxp.com>
On 05/04/2019 17:16, Breno Matheus Lima wrote:
> + if ((IS_ENABLED(CONFIG_OPTEE) ||
> + !IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT)) &&
> + !IS_ENABLED(CONFIG_CMD_DEKBLOB)) {
So.
How does this patch work if you want to do HABv4 encrypted
authentication of an OP-TEE image prior to booting it ?
i.e.
You'll switch the job-ring ownership over to non-trusted world, call HAB
and the BootROM will fail to authenticate.
How about we improve the hab driver in u-boot ?
1. I notice somebody has already added a save_gd()/restore_gd() pair
2. How about a save_jr()/restore_jr() pair and
3. a bootrom_jr_setup() ?
In pseudocode then
do_hab_auth()
{
save_jr(); // save current job-ring context
bootrom_jr_setup(); // set job-ring to bootrom mode
hab_rvt_authenticate();
restore_jr(); // restore previous job-ring context
}
That gets us out of the nasty business of
1. Constraining the use case of CONFIG_OPTEE=y &&
authenticate(encrypted-dek-blob);
2. Pushing changes into upstream OP-TEE for job-ring assignment
IMV - we should save and restore the job ring context so that all of
this stuff will "just work"
That should work for
BootROM -> u-boot -> HABv4 auth(encryptedblob) -> Linux
and
BootROM -> u-boot -> run optee -> HABv4 auth(encrypted blob) -> Linux
Basically you've described and additional dependency the BootROM has, so
lets just "switch context" prior to calling into the BootROM and restore
to a default non-secure job-ring assignment after.
---
bod
next prev parent reply other threads:[~2019-04-06 15:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-05 16:16 [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent Breno Matheus Lima
2019-04-06 15:21 ` Bryan O'Donoghue [this message]
2019-04-06 15:31 ` Bryan O'Donoghue
2019-04-06 21:41 ` Breno Matheus Lima
2019-04-07 8:05 ` Bryan O'Donoghue
2019-04-07 18:56 ` Breno Matheus Lima
2019-04-08 8:09 ` Bryan O'Donoghue
2019-04-08 12:58 ` Fabio Estevam
2019-04-15 11:28 ` Bryan O'Donoghue
2019-04-06 22:26 ` Breno Matheus Lima
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=479d5fa5-e9dd-f45b-5db6-45b6bfdde791@linaro.org \
--to=bryan.odonoghue@linaro.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.