All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: u-boot@lists.denx.de
Subject: [PATCH v3 0/6] crypto/fsl: add RNG support
Date: Sat, 27 Jun 2020 21:20:55 +0200	[thread overview]
Message-ID: <0fa1291619abb949ae16cfb1c8c53504@walle.cc> (raw)
In-Reply-To: <98d5562d-e26f-3b52-8b0e-a7a99ce80a5f@gmx.de>

Am 2020-06-26 18:26, schrieb Heinrich Schuchardt:
> On 6/25/20 11:01 PM, Michael Walle wrote:
>> Am 2020-06-25 18:03, schrieb Heinrich Schuchardt:
>>> On 25.06.20 16:36, Heinrich Schuchardt wrote:
>>>> On 25.06.20 14:18, Michael Walle wrote:
>>>>> First, improve the compatibility on newer Era CAAMs. These
>>>>> introduced new
>>>>> version registers. Secondly, add RNG support for the CAAM. This way
>>>>> we get
>>>>> random number generator support for EFI for free and KASLR will 
>>>>> work
>>>>> with
>>>>> ARM64 kernels booted with bootefi.
>>>>> 
>>>> 
>>>> It seems that a Kconfig dependency at least on 
>>>> CONFIG_SYS_FSL_HAS_SEC
>>>> which itself depends on CONFIG_IMX_HAB is missing:
>>>> 
>>>> wandboard_defconfig + FSL_CAAM + DM_RNG gives me a bunch of errors
>>>> 
>>>> drivers/crypto/fsl/jr.c: In function ?start_jr0?:
>>>> drivers/crypto/fsl/jr.c:47:2: error: unknown type name ?ccsr_sec_t?; 
>>>> did
>>>> you mean ?pci_dev_t??
>>>> ? ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
>>>> ? ^~~~~~~~~~
>>>> ? pci_dev_t
>>>> In file included from ./arch/arm/include/asm/byteorder.h:29,
>>>> ???????????????? from include/linux/libfdt_env.h:15,
>>>> ???????????????? from include/linux/libfdt.h:6,
>>>> ???????????????? from include/fdtdec.h:17,
>>>> ???????????????? from include/asm-generic/global_data.h:23,
>>>> ???????????????? from ./arch/arm/include/asm/global_data.h:87,
>>>> ???????????????? from include/common.h:26,
>>>> ???????????????? from drivers/crypto/fsl/jr.c:8:
>>>> drivers/crypto/fsl/jr.c:48:29: error: request for member ?ctpr_ms? 
>>>> in
>>>> something not a structure or union
>>>> ? u32 ctpr_ms = sec_in32(&sec->ctpr_ms);
>>>> ???????????????????????????? ^~
>>>> 
>>>> But if I enable IMX_HAB booting fails with: "hab fuse not enabled".
>>>> 
>>>> Why should I need to enable the HAB fuse to use the random number
>>>> generator on the i.MX6?
>>>> 
>>> 
>>> With this change I can build the RNG driver for the i.MX6 Wandboard:
>>> 
>>> diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
>>> index 5ed6140da3..84783ea987 100644
>>> --- a/drivers/crypto/fsl/Kconfig
>>> +++ b/drivers/crypto/fsl/Kconfig
>>> @@ -37,7 +37,6 @@ config SYS_FSL_SEC_BE
>>> 
>>> ?config SYS_FSL_SEC_COMPAT
>>> ??????? int "Freescale Secure Boot compatibility"
>>> -?????? depends on SYS_FSL_HAS_SEC
>>> ??????? default 2 if SYS_FSL_SEC_COMPAT_2
>>> ??????? default 4 if SYS_FSL_SEC_COMPAT_4
>>> ??????? default 5 if SYS_FSL_SEC_COMPAT_5
>>> 
>>> Even if you do not plan to support the i.MX6, I would recommend this
>>> change to separate HAB and RNG.
>> 
>> I don't think this is the correct place. Rather the architecture 
>> should
>> set SYS_FSL_HAS_SEC if it actually has the SEC. I mean it already sets
>> the COMPAT level but not the actual config which indicates it has one.
>> At the moment it depends on IMX_HAB; I don't know the reasoning behind
>> this. But I don't see how this would be part of this series.
> 
> ARCH_MX7 (arch/arm/Kconfig) has:
> select SYS_FSL_HAS_SEC if IMX_HAB
> 
> So according to your suggestion this should be changed to
> 
> select SYS_FSL_HAS_SEC ?
> And the same added to ARCH_MX6?

yes, because HAS_SEC is a hardware feature, why should that be dependant
on a feature which is selected by the user? But I don't know if there 
are
any side effects.

Also I don't know if the SEC is available in all SoC of the imx6/7 
series.

-michael

  reply	other threads:[~2020-06-27 19:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 12:18 [PATCH v3 0/6] crypto/fsl: add RNG support Michael Walle
2020-06-25 12:19 ` [PATCH v3 1/6] crypto/fsl: make SEC%u status line consistent Michael Walle
2020-06-25 12:19 ` [PATCH v3 2/6] crypto/fsl: export caam_get_era() Michael Walle
2020-06-25 12:19 ` [PATCH v3 3/6] crypto/fsl: support newer SEC modules Michael Walle
2020-06-25 12:19 ` [PATCH v3 4/6] crypto/fsl: don't regenerate secure keys Michael Walle
2020-06-25 12:19 ` [PATCH v3 5/6] crypto/fsl: instantiate the RNG with prediciton resistance Michael Walle
2020-06-27 17:32   ` Heinrich Schuchardt
2020-06-25 12:19 ` [PATCH v3 6/6] crypto/fsl: add RNG support Michael Walle
2020-06-25 13:19   ` Heinrich Schuchardt
2020-06-26 17:32   ` Heinrich Schuchardt
2020-06-25 14:36 ` [PATCH v3 0/6] " Heinrich Schuchardt
2020-06-25 16:03   ` Heinrich Schuchardt
2020-06-25 21:01     ` Michael Walle
2020-06-26 16:26       ` Heinrich Schuchardt
2020-06-27 19:20         ` Michael Walle [this message]
2020-06-27 19:25         ` Michael Walle

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=0fa1291619abb949ae16cfb1c8c53504@walle.cc \
    --to=michael@walle.cc \
    --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.