> -Original Message-
> From: Herbert Xu
> Sent: Monday, June 24, 2019 4:20 PM
> To: Antoine Tenart
> Cc: Pascal Van Leeuwen ; Pascal van Leeuwen
> ; linux-
> cry...@vger.kernel.org; da...@davemloft.net
> Subject: Re: [PATCH 3/3] crypto: inside-secure - add support for using the
> EIP197
Ard Biesheuvel wrote:
> The AIRO driver applies a ctr(aes) on a buffer of considerable size
> (2400 bytes), and instead of invoking the crypto API to handle this
> in its entirety, it open codes the counter manipulation and invokes
> the AES block cipher directly.
>
> Let's fix this, by switchin
On Mon, Jun 24, 2019 at 08:35:33PM +0300, Imre Deak wrote:
> Hi,
>
> On Thu, Jun 20, 2019 at 02:02:21PM +0800, Herbert Xu wrote:
> > On Mon, Jun 17, 2019 at 09:15:02PM +, Christophe Leroy wrote:
> > > All mapping iterator logic is based on the assumption that sg->offset
> > > is always lower t
On 6/24/19 2:29 PM, Hook, Gary wrote:
> The CCP driver is able to act as a DMA engine. Add a module parameter that
> allows this feature to be enabled/disabled.
>
> Signed-off-by: Gary R Hook
> ---
> drivers/crypto/ccp/ccp-dev-v5.c | 11 +++
> drivers/crypto/ccp/ccp-dev.h|1 +
>
On 6/24/19 2:29 PM, Hook, Gary wrote:
> Add a module parameter that allows specification of one or more CCPs
> based on PCI bus identifiers. The value of the parameter is a comma-
> separated list of bus numbers, in no particular order.
>
> Signed-off-by: Gary R Hook
> ---
> drivers/crypto/ccp/s
On 6/24/19 2:29 PM, Hook, Gary wrote:
> Some processors contain multiple CCPs with differing device IDs. Enable
> the selection of specific devices based on ID. The parameter value is
> a single PCI ID.
>
> Signed-off-by: Gary R Hook
> ---
> drivers/crypto/ccp/sp-pci.c |7 +++
> 1 file c
On Mon, 2019-06-24 at 14:37 -0600, Jonathan Corbet wrote:
> On Mon, 24 Jun 2019 13:29:42 -0700
> Joe Perches wrote:
>
> > > Finally, would you prefer a v2 of the patch set? Happy to do
> > > whatever is preferred, of course.
> >
> > Whatever Jonathan decides is fine with me.
> > Mine was just
On 6/24/19 2:28 PM, Hook, Gary wrote:
> Provide the ability to constrain the total number of enabled devices in
> the system. Once maxdev devices have been configured, additional
> devices are ignored.
>
> Signed-off-by: Gary R Hook
> ---
> drivers/crypto/ccp/sp-pci.c | 16
>
On Mon, Jun 24, 2019 at 07:07:49PM +, Hook, Gary wrote:
> Add a reference to the crypto engine documentation to
> the index.
>
> Signed-off-by: Gary R Hook
> ---
> Documentation/crypto/index.rst |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/crypto/index.rst b/Doc
On 6/24/19 2:28 PM, Hook, Gary wrote:
> Make module parameters readable in DebugFS.
Not sure why you have this... you can access the module parameters in
/sys/module/ccp/parameters. You can then get/set them based on the
value in the module_param() definition.
Thanks,
Tom
>
> Signed-off-by: Ga
On 6/24/19 2:28 PM, Hook, Gary wrote:
> Add a module parameter to limit the number of queues per CCP. The default
> (nqueues=0) is to set up every available queue on each device.
This doesn't match the code... nqueues defaults to MAX_HW_QUEUES below.
The way it is coded nqueues=0 and nqueues=1 ar
On Mon, Jun 24, 2019 at 06:32:26PM +0800, Herbert Xu wrote:
> On Mon, Jun 24, 2019 at 12:27:08AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:abf02e29 Merge tag 'pm-5.2-rc6' of git://git.kernel.org/pu..
> > git tree: upstream
> > conso
On Mon, 24 Jun 2019 13:29:42 -0700
Joe Perches wrote:
> > Finally, would you prefer a v2 of the patch set? Happy to do
> > whatever is preferred, of course.
>
> Whatever Jonathan decides is fine with me.
> Mine was just a plea to avoid unnecessarily
> making the source text harder to read as
>
On Mon, 2019-06-24 at 20:06 +, Gary R Hook wrote:
Hi Gary.
> On 6/24/19 2:30 PM, Joe Perches wrote:
> > On Mon, 2019-06-24 at 19:07 +, Hook, Gary wrote:
> > > Tidy up the crypto documentation by filling in some variable
> > > descriptions, make some grammatical corrections, and enhance
>
On 6/24/19 2:30 PM, Joe Perches wrote:
> On Mon, 2019-06-24 at 19:07 +, Hook, Gary wrote:
>> Tidy up the crypto documentation by filling in some variable
>> descriptions, make some grammatical corrections, and enhance
>> formatting.
>
> While this seems generally OK, please try not to make the
Hello David,
AFAIK Mimi is happy with this patch set, but I still need acks from
maintainers of other subsystems that my changes touch before she can
accept it.
Are this patch and the next one ("PKCS#7: Introduce pkcs7_get_digest()")
OK from your PoV?
--
Thiago Jung Bauermann
IBM Linux Technol
Hello Jessica,
AFAIK Mimi is happy with this patch set, but I still need acks from
maintainers of other subsystems that my changes touch before she can
accept it.
Is this patch OK from your PoV?
--
Thiago Jung Bauermann
IBM Linux Technology Center
Thiago Jung Bauermann writes:
> IMA will u
Add module parameter pcibus as a read-only variable to the CCP's
debugfs info.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-debugfs.c |1 +
drivers/crypto/ccp/ccp-dev.h |1 +
drivers/crypto/ccp/sp-pci.c | 47 --
3 files changed, 47
On Mon, 2019-06-24 at 19:07 +, Hook, Gary wrote:
> Tidy up the crypto documentation by filling in some variable
> descriptions, make some grammatical corrections, and enhance
> formatting.
While this seems generally OK, please try not to make the
readability of the source _text_ less intelligi
Add a module parameter that allows specification of one or more CCPs
based on PCI bus identifiers. The value of the parameter is a comma-
separated list of bus numbers, in no particular order.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/sp-pci.c | 58 +
Add a read-only variable to report the value of the parameter
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/sp-pci.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index 5b0a9c145c5a..c1c1e05a7c0f 100644
--- a/drivers/crypto/c
The CCP driver is able to act as a DMA engine. Add a module parameter that
allows this feature to be enabled/disabled.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-dev-v5.c | 11 +++
drivers/crypto/ccp/ccp-dev.h|1 +
drivers/crypto/ccp/sp-pci.c |8
3 f
Provide the ability to constrain the total number of enabled devices in
the system. Once maxdev devices have been configured, additional
devices are ignored.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/sp-pci.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers
Add a read-only debugfs entry for the module parameter 'maxdev'.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/sp-pci.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index b81493810689..29177d113c90 100644
--- a/drivers/crypt
Some processors contain multiple CCPs with differing device IDs. Enable
the selection of specific devices based on ID. The parameter value is
a single PCI ID.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/sp-pci.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/crypto/c
Add pcidev to the CCP's debugfs information
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/sp-pci.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index b024b92fb749..bcd1e233dce7 100644
--- a/drivers/crypto/ccp/sp-pci.c
+++ b/
Add a module parameter to limit the number of queues per CCP. The default
(nqueues=0) is to set up every available queue on each device.
The count of queues starts from the first one found on the device (which
is based on the device ID).
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-dev
Make module parameters readable in DebugFS.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-debugfs.c |2 ++
drivers/crypto/ccp/sp-pci.c | 22 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/crypto/ccp/ccp-debugfs.c b/drivers/crypto/ccp/ccp-debugfs
Add a config option to exclude DebugFS support in the CCP driver.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/Kconfig |9 +
drivers/crypto/ccp/Makefile |4 ++--
drivers/crypto/ccp/ccp-dev-v5.c |4
3 files changed, 15 insertions(+), 2 deletions(-)
diff --g
Firstly, add a switch to allow/disallow debugfs code to be built
into the CCP driver.
This rest of the patch series implements a set of module parameters
that allow fine-tuned control over which CCPs on a system are enabled
by the driver, and how many queues on each device are activated.
Lastly,
Tidy up the formatting/grammar in crypto_engine.rst. Use lists where
appropriate.
Signed-off-by: Gary R Hook
---
Documentation/crypto/crypto_engine.rst | 120 ++--
1 file changed, 82 insertions(+), 38 deletions(-)
diff --git a/Documentation/crypto/crypto_engine.rst
Fill in missing parameter descriptions for the ompression algorithm,
then pick them up to document for the compression_alg structure.
Signed-off-by: Gary R Hook
---
Documentation/crypto/api-skcipher.rst |2 +-
include/linux/crypto.h| 11 +++
2 files changed, 12 inse
Add a reference to the crypto engine documentation to
the index.
Signed-off-by: Gary R Hook
---
Documentation/crypto/index.rst |1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index c4ff5d791233..37cd7fb0ea82 100644
--- a/Docu
Tidy up the crypto documentation by filling in some variable
descriptions, make some grammatical corrections, and enhance
formatting.
---
Gary R Hook (3):
crypto: doc - Add parameter documentation
crypto: doc - Describe the crypto engine
crypto: doc - Fix formatting of new crypt
In preparation of tweaking the accelerated AES chaining mode routines
to be able to use a 5-way stride, implement the core routines to
support processing 5 blocks of input at a time. While at it, drop
the 2 way versions, which have been unused for a while now.
Signed-off-by: Ard Biesheuvel
---
a
As it turns out, even a 4-way interleave is not sufficient to saturate
the ThunderX2 pipeline with AES instructions, so this series implements
5-way interleave for modes that can be modified without running out of
registers to maintain chaining mode state across the encryption operation,
i.e., ECB,
This implements 5-way interleaving for ECB, CBC decryption and CTR,
resulting in a speedup of ~11% on Marvell ThunderX2, which has a
very deep pipeline and therefore a high issue latency for NEON
instructions operating on the same registers.
Note that XTS is left alone: implementing 5-way interlea
Hi,
On Thu, Jun 20, 2019 at 02:02:21PM +0800, Herbert Xu wrote:
> On Mon, Jun 17, 2019 at 09:15:02PM +, Christophe Leroy wrote:
> > All mapping iterator logic is based on the assumption that sg->offset
> > is always lower than PAGE_SIZE.
> >
> > But there are situations where sg->offset is su
On Mon, Jun 24, 2019 at 09:38:12AM +0200, Ard Biesheuvel wrote:
> Now that aegis128 has been announced as one of the winners of the CAESAR
> competition, it's time to provide some better support for it on arm64 (and
> 32-bit ARM *)
>
> This time, instead of cloning the generic driver twice and rew
On 6/24/19 8:04 AM, Lendacky, Thomas wrote:
> On 6/23/19 2:18 PM, David Rientjes wrote:
>> If ccp_dev_init() fails, kfree() the allocated ccp since it will otherwise
>> be leaked.
>
> Not needed. It's allocated with devm_kzalloc(), so it won't be leaked.
>
> Thanks,
> Tom
Nacked-By: Gary R Hook
Never mind. Please ignore this patch.
This is Intel hardware so it's little endian. There are a bunch of
other test_bit() casts which would be problematic so this wouldn't
really fix anything anyway.
regards,
dan carpenter
On Mon, 24 Jun 2019 at 09:38, Ard Biesheuvel wrote:
>
> Provide an accelerated implementation of aegis128 by wiring up the
> SIMD hooks in the generic driver to an implementation based on NEON
> intrinsics, which can be compiled to both ARM and arm64 code.
>
> This results in a performance of 2.2
On Thu, Jun 20, 2019 at 06:03:17PM -0700, Stephen Boyd wrote:
>
> What do you think of the attached patch? I haven't tested it, but it
> would make sure that the kthread is frozen so that the hardware can be
> resumed before the kthread is thawed and tries to go touch the hardware.
Looks good to m
On Thu, Jun 20, 2019 at 05:42:59PM +0200, Antoine Tenart wrote:
>
> Yes, you either have to choice to put it in /lib/firmware (and in the
> linux-firmwares project!) or to convince people to allow releasing this.
I agree. We should not be adding firmware into the driver itself.
Thanks,
--
Email
The "vf_mask" as a u32 but we were casting it to unsigned long when we
do the for_each_set_bit() loop. The problem is that is an out of bounds
read on big endian 64 bit systems.
Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV")
Signed-off-by: Dan Carpenter
---
Not tested. I don't know
The generic table based AES implementation uses 16 KB worth of lookup
tables, where 4 base tables of 1 KB each are emitted three additional
times with the coefficients rotated by 1, 2 and 3 bytes, respectively.
Given that many architectures tolerate unaligned accesses at moderate
cost, we can sacr
On 6/23/19 2:18 PM, David Rientjes wrote:
> If ccp_dev_init() fails, kfree() the allocated ccp since it will otherwise
> be leaked.
Not needed. It's allocated with devm_kzalloc(), so it won't be leaked.
Thanks,
Tom
>
> Fixes: 720419f01832 ("crypto: ccp - Introduce the AMD Secure Processor
> dev
On Mon, Jun 24, 2019 at 12:27:08AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:abf02e29 Merge tag 'pm-5.2-rc6' of git://git.kernel.org/pu..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17a8bfeaa0
> kernel
On 22.06.19 02:30, Ard Biesheuvel wrote:
> Signed-off-by: Ard Biesheuvel
> ---
> arch/s390/crypto/des_s390.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/arch/s390/crypto/des_s390.c b/arch/s390/crypto/des_s390.c
> index 1f9ab24dc048..4e4061885b0d 100644
On Mon, Jun 24, 2019 at 9:38 AM Ard Biesheuvel
wrote:
> The generic AES code provides four sets of lookup tables, where each
> set consists of four tables containing the same 32-bit values, but
> rotated by 0, 8, 16 and 24 bits, respectively. This makes sense for
> CISC architectures such as x86 w
On Mon, Jun 24, 2019 at 9:38 AM Ard Biesheuvel
wrote:
> TFM init/exit routines are optional, so no need to provide empty ones.
>
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Ondrej Mosnacek
> ---
> crypto/aegis128.c | 11 ---
> crypto/aegis128l.c | 11 ---
> crypto/aegis256.c
On Mon, 24 Jun 2019 at 09:59, Ondrej Mosnacek wrote:
>
> Hi Ard,
>
> On Mon, Jun 24, 2019 at 9:38 AM Ard Biesheuvel
> wrote:
> >
> > Use crypto_aegis128_update_u() not crypto_aegis128_update_a() in the
> > decrypt path that is taken when the source or destination pointers
> > are not aligned.
> >
Hi Ard,
On Mon, Jun 24, 2019 at 9:38 AM Ard Biesheuvel
wrote:
>
> Use crypto_aegis128_update_u() not crypto_aegis128_update_a() in the
> decrypt path that is taken when the source or destination pointers
> are not aligned.
>
> Signed-off-by: Ard Biesheuvel
> ---
> crypto/aegis128.c | 2 +-
> 1
Use crypto_aegis128_update_u() not crypto_aegis128_update_a() in the
decrypt path that is taken when the source or destination pointers
are not aligned.
Signed-off-by: Ard Biesheuvel
---
crypto/aegis128.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/aegis128.c b/cry
Add some plumbing to allow the AEGIS128 code to be built with SIMD
routines for acceleration.
Signed-off-by: Ard Biesheuvel
---
crypto/aegis.h| 14 +++
crypto/aegis128.c | 42 ++--
2 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/crypto/aegis.h b/crypto/ae
Provide an accelerated implementation of aegis128 by wiring up the
SIMD hooks in the generic driver to an implementation based on NEON
intrinsics, which can be compiled to both ARM and arm64 code.
This results in a performance of 2.2 cycles per byte on Cortex-A53,
which is a performance increase o
The generic AES code provides four sets of lookup tables, where each
set consists of four tables containing the same 32-bit values, but
rotated by 0, 8, 16 and 24 bits, respectively. This makes sense for
CISC architectures such as x86 which support memory operands, but
for other architectures, the
Now that aegis128 has been announced as one of the winners of the CAESAR
competition, it's time to provide some better support for it on arm64 (and
32-bit ARM *)
This time, instead of cloning the generic driver twice and rewriting half
of it in arm64 and ARM assembly, add hooks for an accelerated
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index ad78ab5b93cb..c578ccd92c57 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -2327,6 +2327,13 @@ static int do_test(const char *alg, u32 type, u
TFM init/exit routines are optional, so no need to provide empty ones.
Signed-off-by: Ard Biesheuvel
---
crypto/aegis128.c | 11 ---
crypto/aegis128l.c | 11 ---
crypto/aegis256.c | 11 ---
3 files changed, 33 deletions(-)
diff --git a/crypto/aegis128.c b/crypto/aegis1
Hello,
syzbot found the following crash on:
HEAD commit:abf02e29 Merge tag 'pm-5.2-rc6' of git://git.kernel.org/pu..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17a8bfeaa0
kernel config: https://syzkaller.appspot.com/x/.config?x=56f1da14935c3cce
da
Document the binding used by the MediaTek ARMv8 SoCs random
number generator with TrustZone enabled.
Signed-off-by: Neal Liu
---
.../devicetree/bindings/rng/mtk-sec-rng.txt| 10 ++
1 file changed, 10 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/mtk-se
1. Add a header file to provide SIP interface to ATF
2. Add hwrng SMC fid
Signed-off-by: Neal Liu
---
include/linux/soc/mediatek/mtk_sip_svc.h | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 include/linux/soc/mediatek/mtk_sip_svc.h
diff --git a/includ
These patch series introduce a generic rng driver for Trustzone
based kernel driver which would like to communicate with ATF
SIP services.
Patch #1 initials SMC fid table for Mediatek SIP interfaces and
adds HWRNG related SMC call.
Patch #2..3 adds mtk-sec-rng kernel driver for Trustzone based So
For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
entropy sources is not accessible from normal world (linux) and
rather accessible from secure world (ATF/TEE) only. This driver aims
to provide a generic interface to ATF rng service.
Signed-off-by: Neal Liu
---
drivers/char/hw_
On SEC1, hash provides wrong result when performing hashing in several
steps with input data SG list has more than one element. This was
detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[ 44.185947] alg: hash: md5-talitos test failed (wrong result) on test vector
6, cfg="random: may_sleep use_f
icv_ool is not used anymore, drop it.
Fixes: e345177ded17 ("crypto: talitos - fix AEAD processing.")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/tali
Moves struct talitos_edesc into talitos.h so that it can be used
from any place in talitos.c
It will be required for next patch ("crypto: talitos - fix hash
on SEC1")
Signed-off-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
drivers/crypto/talitos.c | 30 --
dri
All mapping iterator logic is based on the assumption that sg->offset
is always lower than PAGE_SIZE.
But there are situations where sg->offset is such that the SG item
is on the second page. In that case sg_copy_to_buffer() fails
properly copying the data into the buffer. One of the reason is
tha
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[3.385197] bus: 'platform': really_probe: probing driver talitos with
device ff02.crypto
[3
70 matches
Mail list logo
