Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 6月, 2019 2 次提交
    • H
      crypto: caam - update IV using HW support · 334d37c9
      由 Horia Geantă 提交于 
      Modify drivers to perform skcipher IV update using the crypto engine,
instead of performing the operation in SW.

Besides being more efficient, this also fixes IV update for CTR mode.

Output HW S/G table is appended with an entry pointing to the same
IV buffer used as input (which is now mapped BIDIRECTIONAL).

AS (Algorithm State) parameter of the OPERATION command is changed
from INIFINAL to INIT in descriptors used by ctr(aes), cbc(aes).
This is needed since in case FINAL bit is set, HW skips IV updating
in the Context Register for the last data block.
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      334d37c9
    • H
      crypto: caam - use len instead of nents for bulding HW S/G table · 059d73ee
      由 Horia Geantă 提交于 
      Currently, conversion of SW S/G table into HW S/G layout relies on
nents returned by sg_nents_for_len(sg, len).
However this leaves the possibility of HW S/G referencing more data
then needed: since buffer length in HW S/G entries is filled using
sg_dma_len(sg), the last entry in HW S/G table might have a length
that is bigger than needed for the crypto request.

This way of S/G table conversion is fine, unless after converting a table
more entries have to be appended to the HW S/G table.
In this case, crypto engine would access data from the S/G entry having
the incorrect length, instead of advancing in the S/G table.
This situation doesn't exist, but the upcoming implementation of
IV update for skcipher algorithms needs to add a S/G entry after
req->dst S/G (corresponding to output IV).
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      059d73ee
  3. 06 6月, 2019 4 次提交
  5. 30 5月, 2019 4 次提交
  7. 23 5月, 2019 7 次提交
    • S
      crypto: caam - print debugging hex dumps after unmapping · bb992bc4
      由 Sascha Hauer 提交于 
      For encryption the destination pointer was still mapped, so the hex dump
may be wrong. The IV still contained the input IV while printing instead
of the output IV as intended.

For decryption the destination pointer was still mapped, so the hex dump
may be wrong. The IV dump was correct.

Do the hex dumps consistenly after the buffers have been unmapped and
in case of IV copied to their final destination.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      bb992bc4
    • H
      crypto: caam/qi - DMA map keys using proper device · a7cd942b
      由 Horia Geantă 提交于 
      Currently there is a mismatch b/w the ICID (Isolation Context ID) used
for DMA mapping keys and ICID used for accessing them.
-keys are DMA mapped using a job ring device, thus a job ring ICID
-keys are accessed from descriptors enqueued via Queue Interface,
thus using QI ICID

[Note: ICIDs of JRs, QI are configured by U-boot / other entity by:
-fixing up the corresponding job ring and controller DT nodes
-setting up corresponding caam ICID registers]

In order to avoid IOMMU faults, DMA map the key using the controller
device instead of a job ring device.
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      a7cd942b
    • H
      crypto: caam/qi - fix address translations with IOMMU enabled · b2b2ee35
      由 Horia Geantă 提交于 
      When IOMMU is enabled, iova -> phys address translation should be
performed using iommu_ops, not dma_to_phys().
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      b2b2ee35
    • H
      crypto: caam/qi - don't allocate an extra platform device · 6b175685
      由 Horia Geantă 提交于 
      Use the controller device for caam/qi instead of allocating
a new platform device.
This is needed as a preparation to add support for working behind an
SMMU. A platform device allocated using platform_device_register_full()
is not completely set up - most importantly .dma_configure()
is not called.
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6b175685
    • H
      crypto: caam - convert top level drivers to libraries · 1b46c90c
      由 Horia Geantă 提交于 
      Currently we allow top level code, i.e. that which sits between the
low level (HW-specific) drivers and crypto API, to be built as several
drivers: caamalg, caamhash, caam_pkc, caamrng, caamalg_qi.

There is no advantage in this, more it interferes with adding support
for deferred probing (there are no corresponding devices and thus
no bus).

Convert these drivers and call init() / exit() manually at the right
time.
Move algorithms initialization at JR probe / remove time:
-the first probed JR registers the crypto algs
-the last removed JR unregisters the crypto algs

Note: caam_qi_init() is called before JR platform devices creation
(of_populate_bus()), such that QI interface is initialized when
the caam/qi algorithms are registered in the JR driver (by calling
caam_qi_algapi_init().

While here, fix the Kconfig entries under CRYPTO_DEV_FSL_CAAM_JR
to be aligned.
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      1b46c90c
    • H
      crypto: caam - fix S/G table passing page boundary · a5e5c133
      由 Horia Geantă 提交于 
      According to CAAM RM:
-crypto engine reads 4 S/G entries (64 bytes) at a time,
even if the S/G table has fewer entries
-it's the responsibility of the user / programmer to make sure
this HW behaviour has no side effect

The drivers do not take care of this currently, leading to IOMMU faults
when the S/G table ends close to a page boundary - since only one page
is DMA mapped, while CAAM's DMA engine accesses two pages.

Fix this by rounding up the number of allocated S/G table entries
to a multiple of 4.
Note that in case of two *contiguous* S/G tables, only the last table
might needs extra entries.
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      a5e5c133
    • H
      crypto: caam - avoid S/G table fetching for AEAD zero-length output · dcd9c76e
      由 Horia Geantă 提交于 
      When enabling IOMMU support, the following issue becomes visible
in the AEAD zero-length case.

Even though the output sequence length is set to zero, the crypto engine
tries to prefetch 4 S/G table entries (since SGF bit is set
in SEQ OUT PTR command - which is either generated in SW in case of
caam/jr or in HW in case of caam/qi, caam/qi2).
The DMA read operation will trigger an IOMMU fault since the address in
the SEQ OUT PTR is "dummy" (set to zero / not obtained via DMA API
mapping).

1. In case of caam/jr, avoid the IOMMU fault by clearing the SGF bit
in SEQ OUT PTR command.

2. In case of caam/qi - setting address, bpid, length to zero for output
entry in the compound frame has a special meaning (cf. CAAM RM):
"Output frame = Unspecified, Input address = Y. A unspecified frame is
indicated by an unused SGT entry (an entry in which the Address, Length,
and BPID fields are all zero). SEC obtains output buffers from BMan as
prescribed by the preheader."

Since no output buffers are needed, modify the preheader by setting
(ABS = 1, ADDBUF = 0):
-"ABS = 1 means obtain the number of buffers in ADDBUF (0 or 1) from
the pool POOL ID"
-ADDBUF: "If ABS is set, ADD BUF specifies whether to allocate
a buffer or not"

3. In case of caam/qi2, since engine:
-does not support FLE[FMT]=2'b11 ("unused" entry) mentioned in DPAA2 RM
-requires output entry to be present, even if not used
the solution chosen is to leave output frame list entry zeroized.

Fixes: 763069ba ("crypto: caam - handle zero-length AEAD output")
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      dcd9c76e
  9. 17 5月, 2019 1 次提交
  11. 09 5月, 2019 3 次提交
  13. 03 5月, 2019 3 次提交
  15. 25 4月, 2019 2 次提交
  17. 18 4月, 2019 3 次提交
  19. 08 4月, 2019 1 次提交
  21. 28 3月, 2019 5 次提交
  23. 22 3月, 2019 1 次提交
  25. 07 3月, 2019 1 次提交
  27. 28 2月, 2019 3 次提交