* Tero Kristo [160621 10:58]:
>
> Do you want to pick-up the DTS changes from this revision of series as is or
> shall I repost those also? I think the series would require a re-ordering of
> posting the DTS changes before the hwmod data.
I'll pick the dts changes from this series into omap-for-
Hi Herbert,
> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Wednesday, June 22, 2016 7:41 AM
> To: Benedetto, Salvatore
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v10 2/3] crypto: kpp - Add DH software implementation
>
> On Wed, Jun 22,
On 07/06/16 15:24, Grygorii Strashko wrote:
On 06/07/2016 02:52 PM, Tero Kristo wrote:
On 07/06/16 13:08, Herbert Xu wrote:
On Wed, Jun 01, 2016 at 06:03:52PM -0500, Dave Gerlach wrote:
On 06/01/2016 04:53 AM, Grygorii Strashko wrote:
On 06/01/2016 11:56 AM, Tero Kristo wrote:
From: Lokesh V
On Wed, Jun 22, 2016 at 08:18:42AM +, Benedetto, Salvatore wrote:
>
> If I have to pack the secret into a bytestream, where do you expect the
> endianness
> of the sizes to be handled? If I understood you correctly I'll pack them in
> little endian,
> but when decoding I have to take that int
> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Wednesday, June 22, 2016 11:04 AM
> To: Benedetto, Salvatore
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v10 2/3] crypto: kpp - Add DH software implementation
>
> On Wed, Jun 22, 2016 at 08
The helper pkcs1pad_sg_set_buf tries to split a buffer that crosses
a page boundary into two SG entries. This is unnecessary. This
patch removes that.
Signed-off-by: Herbert Xu
---
crypto/rsa-pkcs1pad.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a
Rather than repeatedly checking the key size on each operation,
we should be checking it once when the key is set.
Signed-off-by: Herbert Xu
---
crypto/rsa-pkcs1pad.c | 56 +++---
1 file changed, 26 insertions(+), 30 deletions(-)
diff --git a/crypt
Ben Dooks wrote:
> The __raw IO functions are not endian safe, so use the readl_relaxed
> and writel_relaxed versions of these.
>
> Signed-off-by: Ben Dooks
This patch has already been merged.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor
Hello,
Le 22/06/2016 12:33, Herbert Xu a écrit :
Romain Perier wrote:
Add a BUG_ON() call when the driver tries to launch a crypto request
while the engine is still processing the previous one. This replaces
a silent system hang by a verbose kernel panic with the associated
backtrace to let th
On 22/06/16 11:37, Herbert Xu wrote:
> Ben Dooks wrote:
>> The __raw IO functions are not endian safe, so use the readl_relaxed
>> and writel_relaxed versions of these.
>>
>> Signed-off-by: Ben Dooks
>
> This patch has already been merged.
>
> Cheers,
Apologies, only meant to repost the core p
We don't currently support using akcipher in atomic contexts,
so GFP_KERNEL should always be used.
Signed-off-by: Herbert Xu
---
crypto/rsa-pkcs1pad.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/crypto/rsa-pkcs1pad.c b/crypto/rsa-pkcs1pad.c
inde
Every implementation of RSA that we have naturally generates
output with leading zeroes. The one and only user of RSA,
pkcs1pad wants to have those leading zeroes in place, in fact
because they are currently absent it has to write those zeroes
itself.
So we shouldn't be stripping leading zeroes i
This patch allows RSA implementations to produce output with
leading zeroes. testmgr will skip leading zeroes when comparing
the output.
This patch also tries to make the RSA test function generic enough
to potentially handle other akcipher algorithms.
Signed-off-by: Herbert Xu
---
crypto/tes
In the vast majority of cases (2^-32 on 32-bit and 2^-64 on 64-bit)
cases, the result from encryption/signing will require no padding.
This patch makes these two operations write their output directly
to the final destination. Only in the exceedingly rare cases where
fixup is needed to we copy it
Currently the mpi SG helpers use sg_virt which is completely
broken. It happens to work with normal kernel memory but will
fail with anything that is not linearly mapped.
This patch fixes this by using the SG iterator helpers.
Signed-off-by: Herbert Xu
---
lib/mpi/mpicoder.c | 86 ++
This was prompted by the caam RSA submission where a lot of work
was done just to strip the RSA output of leading zeroes. This is
in fact completely pointless because the only user of RSA in the
kernel then promptly puts them back.
This patch series resolves this madness by simply leaving any
lea
The only user of rsa-pkcs1pad always uses the hash so there is
no reason to support the case of not having a hash.
This patch also changes the digest info lookup so that it is
only done once during template instantiation rather than on each
operation.
Signed-off-by: Herbert Xu
---
crypto/rsa-p
Romain Perier wrote:
> Add a BUG_ON() call when the driver tries to launch a crypto request
> while the engine is still processing the previous one. This replaces
> a silent system hang by a verbose kernel panic with the associated
> backtrace to let the user know that something went wrong in the
On Wed, Jun 22, 2016 at 10:06:32AM +, Benedetto, Salvatore wrote:
>
> It is pointless because it will only be used for the testmanager.
> I can merge the test functions but I'll still have two set_secret functions
> based on the alg value. Would that be enough for you?
I have made myself perfe
On 2016-06-22 01:16, Stephan Mueller wrote:
Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn:
Hi Austin,
Little data, interesting statement for results on 200+ systems including
all major CPU arches all showing information leading in the same
directions.
Let me try rephrasing
Change crypto queue size from 1 to 10 for omap SHA driver. This should
allow clients to enqueue requests more effectively to avoid serializing
whole crypto sequences, giving extra performance.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 2 +-
1 file changed, 1 insertion(+), 1 del
From: Lokesh Vutla
The extra call to dmaengine_terminate_all is not needed, as the DMA
is not running at this point. This improves performance slightly.
Signed-off-by: Lokesh Vutla
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes.c | 2 --
drivers/crypto/omap-sham.c | 1 -
2 files chan
Context export/import are now required for ahash algorithms due to
required support in algif_hash. Implement these for OMAP SHA driver,
saving and restoring the internal state of the driver.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 40 ++--
Hi,
Changes compared to v1 of the series:
- dropped first patch from the series (crypto: omap-aes: Fix registration of
algorithms) as it was queued by Herbert already
- modified the second (now first) patch of the series to use runtime auto-
suspend instead of getting static sync over a cra l
From: Bin Liu
Adds software fallback support for small crypto requests. In these cases,
it is undesirable to use DMA, as setting it up itself is rather heavy
operation. Gives about 40% extra performance in ipsec usecase.
Signed-off-by: Bin Liu
[t-kri...@ti.com: dropped the extra traces, updated
Calling runtime PM API for every block causes serious performance hit to
crypto operations that are done on a long buffer. As crypto is performed
on a page boundary, encrypting large buffers can cause a series of crypto
operations divided by page. The runtime PM API is also called those many
times.
From: Lokesh Vutla
Adding dt node for hardware random number generator IP.
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/dra7.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 64759e1..16ff083 100644
--- a/arch
From: Lokesh Vutla
Enable clocks for all cores before starting session.
Driver has to pic the aes core dynamically based on the queue length.
Signed-off-by: Lokesh Vutla
---
drivers/crypto/omap-aes.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/d
From: Lokesh Vutla
DRA7 SoC contains SHA crypto hardware accelerator. Add hwmod data for
this IP so that it can be utilized by crypto frameworks.
Signed-off-by: Lokesh Vutla
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 37 +++
1 file c
From: Joel Fernandes
DRA7 SoC contains hardware random number generator. Add hwmod data for
this IP so that it can be utilized.
Signed-off-by: Joel Fernandes
Signed-off-by: Lokesh Vutla
[t-kri...@ti.com: squashed the RNG hwmod IP flag fixes from Lokesh,
squashed the HS chip f
From: Lokesh Vutla
AM43xx SoC contains DES crypto hardware accelerator. Add hwmod data for
this IP so that it can be utilized by crypto frameworks.
Signed-off-by: Lokesh Vutla
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 33 ++
arch/a
From: Joel Fernandes
DRA7 SoC contains AES crypto hardware accelerator. Add hwmod data for
this IP so that it can be utilized by crypto frameworks.
Signed-off-by: Joel Fernandes
Signed-off-by: Lokesh Vutla
[t-kri...@ti.com: squash in support for both AES1 and AES2 cores]
Signed-off-by: Tero Kr
From: Lokesh Vutla
DRA7 SoC has the same SHA IP as OMAP5. Add DT entry for the same.
Signed-off-by: Lokesh Vutla
[t-kri...@ti.com: changed SHA to use EDMA instead of SDMA]
Signed-off-by: Tero Kristo
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git
From: Lokesh Vutla
Add clk node for RNG module.
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 8
drivers/clk/ti/clk-43xx.c| 1 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.
From: Joel Fernandes
Using HWSUP for l4sec clock domain is causing warnings in HWMOD code for
DRA7. Based on some observations, once the clock domain goes into an IDLE
state (because of no activity etc), the IDLEST for the module goes to '0x2'
value which means Interface IDLE condition. So far so
From: Joel Fernandes
DRA7 SoC has the same AES IP as OMAP4. Add DT entries for both AES cores.
Signed-off-by: Joel Fernandes
Signed-off-by: Lokesh Vutla
[t-kri...@ti.com: squashed in the change to use EDMA, squashed in
support for two AES cores]
Signed-off-by: Tero Kristo
--
From: Joel Fernandes
DRA7 SoC contains DES crypto hardware accelerator. Add hwmod data for
this IP so that it can be utilized by crypto frameworks.
Signed-off-by: Joel Fernandes
Signed-off-by: Lokesh Vutla
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 37
From: Lokesh Vutla
Adding DT node for hardware random number generator.
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/am4372.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 12fcde4..a44ee94 100644
--- a/arc
From: Lokesh Vutla
Some SoCs like omap4/omap5/dra7 contain multiple AES crypto accelerator
cores. Adapt the driver to support this. The driver picks the last used
device from a list of AES devices.
Signed-off-by: Lokesh Vutla
[t-kri...@ti.com: forward ported to 4.7 kernel]
Signed-off-by: Tero K
The statesize is used to determine the maximum size for saved ahash
context. In some cases, this can be much larger than what is currently
allocated for it, for example omap-sham driver uses a buffer size of
PAGE_SIZE. Increase the statesize to accommodate this.
Signed-off-by: Tero Kristo
---
cr
Am Mittwoch, 22. Juni 2016, 08:54:16 schrieb Austin S. Hemmelgarn:
Hi Austin,
> You're not demonstrating it's inherently present in the architecture,
I am not demonstrating it, interesting statement. I take different arches from
different vendors which were developed independently from each oth
Some of the call paths of OMAP SHA driver can avoid executing the next
step of the crypto queue under tasklet; instead, execute the next step
directly via function call. This avoids a costly round-trip via the
scheduler giving a slight performance boost.
Signed-off-by: Tero Kristo
---
drivers/cr
The crypto engine must be initialized before registering algorithms,
otherwise the test manager will crash as it attempts to execute
tests for the algos while they are being registered.
Fixes: 0529900a01cb ("crypto: omap-aes - Support crypto engine framework")
Signed-off-by: Tero Kristo
---
driv
Crypto engine will now hi-jack the currently running thread for executing
crypto functionality. Only if we are not running a thread (in interrupt
context) the kthread will be scheduled.
This will improve performance of crypto operations using crypto engine.
Signed-off-by: Tero Kristo
---
crypto
From: Joel Fernandes
DRA7xx SoCs have a DES3DES IP. Add DT data for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e007401..959f99b 100644
-
From: Lokesh Vutla
As setting up the DMA operations is quite costly, add software fallback
support for requests smaller than 200 bytes. This change gives some 10%
extra performance in ipsec use case.
Signed-off-by: Lokesh Vutla
Signed-off-by: Tero Kristo
---
drivers/crypto/Kconfig| 3 +++
From: Lokesh Vutla
For cases where total length of an input SGs is not same as
length of the input data for encryption, omap-des driver
crashes. This happens in the case when IPsec is trying to use
omap-des driver.
To avoid this, we copy all the pages from the input SG list
into a contiguous buf
The crypto engine must be initialized before registering algorithms,
otherwise the test manager will crash as it attempts to execute
tests for the algos while they are being registered.
Fixes: f1b77aaca85a ("crypto: omap-des - Integrate with the crypto engine
framework")
Signed-off-by: Tero Krist
Hi Herbert,
On 22 June 2016 at 12:16, Herbert Xu wrote:
> The only user of rsa-pkcs1pad always uses the hash so there is
> no reason to support the case of not having a hash.
We use pkcs1pad with AF_ALG to implement lightweight TLS. TLS
versions < 1.2 use a non-standard hash so we'd have to mov
From: Lokesh Vutla
Hardware random number generator is present in both AM33xx and AM43xx
SoC's. So moving the hwmod data to common data.
Signed-off-by: Lokesh Vutla
Signed-off-by: Tero Kristo
---
.../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 2 ++
.../omap_hwmod_33xx_43xx_interconnect
On Wed, Jun 22, 2016 at 03:20:51PM +0200, Andrzej Zaborowski wrote:
>
> We use pkcs1pad with AF_ALG to implement lightweight TLS. TLS
> versions < 1.2 use a non-standard hash so we'd have to move the PKCS#1
> padding back to userspace if this is changed.
When this is submitted for upstream inclus
Hi:
I'm in the process of removing blkcipher/ablkcipher which have
been replaced with skcipher. It would be nice if we stop adding
new users of these two interfaces :)
Anyway, if you guys are OK with this patch I'd like to push it
through cryptodev so I can carry on with the removal of blkcipher
Hi Herbert,
On 06/22/2016 09:02 AM, Herbert Xu wrote:
On Wed, Jun 22, 2016 at 03:20:51PM +0200, Andrzej Zaborowski wrote:
We use pkcs1pad with AF_ALG to implement lightweight TLS. TLS
versions < 1.2 use a non-standard hash so we'd have to move the PKCS#1
padding back to userspace if this is c
On Wed, Jun 22, 2016 at 09:19:16AM -0500, Denis Kenzior wrote:
> Just to clarify, we use this from userspace. So we _already_ depend
> on this functionality. Please keep the hash and non-hash versions
> of pkcs1pad available.
How can you be depending on this in userspace when we haven't
even exp
Herbert Xu wrote:
> I'm in the process of removing blkcipher/ablkcipher which have
> been replaced with skcipher. It would be nice if we stop adding
> new users of these two interfaces :)
>
> Anyway, if you guys are OK with this patch I'd like to push it
> through cryptodev so I can carry on wi
On Wed, Jun 22, 2016 at 09:30:12AM -0500, Denis Kenzior wrote:
>
> We live on the bleeding edge :)
>
> I realize that these features are not upstream yet, but that doesn't
> mean that we can't influence / see the direction that the kernel is
> taking and act accordingly.
>
> We'd like to have bot
Hi Herbert,
On 06/22/2016 09:20 AM, Herbert Xu wrote:
On Wed, Jun 22, 2016 at 09:19:16AM -0500, Denis Kenzior wrote:
Just to clarify, we use this from userspace. So we _already_ depend
on this functionality. Please keep the hash and non-hash versions
of pkcs1pad available.
How can you be de
Herbert,
On Wed, 22 Jun 2016, Herbert Xu wrote:
On Wed, Jun 22, 2016 at 09:30:12AM -0500, Denis Kenzior wrote:
We live on the bleeding edge :)
I realize that these features are not upstream yet, but that doesn't
mean that we can't influence / see the direction that the kernel is
taking and
On Mon, Jun 13, 2016 at 04:56:12PM +0800, Herbert Xu wrote:
> The backup path is also very unlikely to work because we'll be
> hitting this with 64K sizes and this just won't work with a 4K
> page size.
Is scatterwalk_map_and_copy broken?
> So up until now we've getting around this 64K issue with
* Implement MPI based Diffie-Hellman under kpp API
* Test provided uses data generad by OpenSSL
Signed-off-by: Salvatore Benedetto
---
crypto/Kconfig | 8 ++
crypto/Makefile | 4 +
crypto/dh.c | 189 ++
crypto/dh_helper.c | 95
Hi Herb,
the following patchset introduces a new API for abstracting key-agreement
protocols such as DH and ECDH. It provides the primitives required for
implementing
the protocol, thus the name KPP (Key-agreement Protocol Primitives).
Regards,
Salvatore
Changes from v10:
* Remove all DH/ECDH c
* Implement ECDH under kpp API
* Provide ECC software support for curve P-192 and
P-256.
* Add kpp test for ECDH with data generated by OpenSSL
Signed-off-by: Salvatore Benedetto
---
crypto/Kconfig |5 +
crypto/Makefile |4 +
crypto/ecc.c| 1018
Add key-agreement protocol primitives (kpp) API which allows to
implement primitives required by protocols such as DH and ECDH.
The API is composed mainly by the following functions
* set_secret() - It allows the user to set his secret, also
referred to as his private key, along with the parame
Hi John, Herbert,
Changes v2: use ktime_get_ns instead of ktime_get_raw_ns
The testing was re-performed and indicate no difference to the previous testing.
Ciao
Stephan
---8<---
As part of the Y2038 development, __getnstimeofday is not supposed to be
used any more. It is now replaced with ktim
On Wed, Jun 22, 2016 at 10:26 AM, Stephan Mueller wrote:
> Hi John, Herbert,
>
> Changes v2: use ktime_get_ns instead of ktime_get_raw_ns
>
> The testing was re-performed and indicate no difference to the previous
> testing.
Thanks for following through on this. This version addresses my
concern
Commit 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG")
accidentally removed the minimum size check for CRYPTO_MSG_GETALG
netlink messages. This allows userland to send a truncated
CRYPTO_MSG_GETALG message as short as a netlink header only making
crypto_report() operate on uninitialized memor
Am Mittwoch, 22. Juni 2016, 20:29:37 schrieb Mathias Krause:
Hi Mathias,
> Commit 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG")
> accidentally removed the minimum size check for CRYPTO_MSG_GETALG
> netlink messages. This allows userland to send a truncated
> CRYPTO_MSG_GETALG message as s
On 22 June 2016 at 21:03, Stephan Mueller wrote:
> Am Mittwoch, 22. Juni 2016, 20:29:37 schrieb Mathias Krause:
>
> Hi Mathias,
>
>> Commit 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG")
>> accidentally removed the minimum size check for CRYPTO_MSG_GETALG
>> netlink messages. This allows us
On Wednesday, June 22, 2016 7:26:06 PM CEST Stephan Mueller wrote:
> As part of the Y2038 development, __getnstimeofday is not supposed to be
> used any more. It is now replaced with ktime_get_ns. The Jitter RNG uses
> the time stamp to measure the execution time of a given code path and
> tries to
On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski wrote:
> On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu
> wrote:
>> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote:
>>>
>>> Is there a straightforward way that bluetooth and, potentially, other
>>> drivers can just do synchronous cry
Stephan and Tadeusz,
On Fri, 10 Jun 2016, Tadeusz Struk wrote:
On 06/09/2016 11:36 AM, Stephan Mueller wrote:
Am Donnerstag, 9. Juni 2016, 11:27:13 schrieb Mat Martineau:
Hi Mat, Tadeusz,
Ok, after checking the code again, I think that dropping that sanity check
should be ok given that this
On Wed, Jun 22, 2016 at 2:48 PM, Andy Lutomirski wrote:
> On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski wrote:
>> On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu
>> wrote:
>>> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote:
Is there a straightforward way that bluetooth
Hi all,
This patch series adds support for the Broadcom BCM5301x SoCs random number
generator which is the same block as the one found in NSP and BCM2835.
Florian Fainelli (3):
Documentation: devicetree: bindings: Add BCM5301x binding
hw_random: bcm2835: Add support for Broadcom BCM5301x
AR
Document the binding used by the Broadcom BCM5301x (Northstar) SoC
random number generator.
Signed-off-by: Florian Fainelli
---
Documentation/devicetree/bindings/rng/brcm,bcm2835.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rng/brcm,
The Broadcom BCM5301x SoCs (Northstar) utilize the same random number
generator peripheral as Northstar Plus and BCM2835, but just like the
NSP SoC, we need to enable the interrupt.
Signed-off-by: Florian Fainelli
---
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/bcm2835-rn
Add the DT node for the random number generator peripheral.
Signed-off-by: Florian Fainelli
---
arch/arm/boot/dts/bcm5301x.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index 7d4d29bf0ed3..c67e451435f4 100644
--- a
Patch series looks good.
Acked-by: Scott Branden
On 16-06-22 05:27 PM, Florian Fainelli wrote:
Hi all,
This patch series adds support for the Broadcom BCM5301x SoCs random number
generator which is the same block as the one found in NSP and BCM2835.
Florian Fainelli (3):
Documentation: de
On Wed, Jun 22, 2016 at 08:39:09AM -0700, Mat Martineau wrote:
>
> David Howells has a keyctl patch set in progress that makes use of
> pkcs1pad, with or without a hash:
>
> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-asym-keyctl&id=6fe3b4aa7df524f4867868b01d4
On Wed, Jun 22, 2016 at 02:48:24PM -0700, Andy Lutomirski wrote:
>
> Before I do this, can you explain what the difference is between
> crypto_cipher and crypto_skcipher? net/bluetooth/smp.c currently uses
> crypto_alloc_skcipher, which you added in:
crypto_cipher operates on a single block. cry
On Wed, Jun 22, 2016 at 04:45:46PM -0700, Andy Lutomirski wrote:
>
> *However*, the other offender I've found (net/rxrpc/rxkad.c) uses
> "pcbc(fcrypt)", which doesn't appear to be usable with this API. Is
> there no way to say "I want synchronous crypto on this VA range" using
> the skcipher API?
* Tero Kristo [160622 06:27]:
> Hi,
>
> Changes compared to v1 of the series:
>
> - dropped first patch from the series (crypto: omap-aes: Fix registration of
> algorithms) as it was queued by Herbert already
> - modified the second (now first) patch of the series to use runtime auto-
> susp
Am Mittwoch, 22. Juni 2016, 15:45:38 schrieb Mat Martineau:
Hi Mat,
> >
> > Ok, I'll update the patch.
>
> Thanks, that helps (especially with pkcs1pad).
Tadeusz received the updated patch from me to integrate it into his patch set.
>
> This brings me to another proposal for read buffer sizin
On Thu, Jun 23, 2016 at 11:48:25AM +0800, Herbert Xu wrote:
>
> No we never had such an API in the kernel. However, I see that
> rxkad does some pretty silly things and we should be able to avoid
> using the stack in pretty much all cases. Let me try to come up with
> something.
Here it is:
--
83 matches
Mail list logo
