Some bug fixes for issues that I stumbled upon while working on other
stuff.
Ard Biesheuvel (2):
crypto: morus/generic - fix for big endian systems
crypto: aegis/generic - fix for big endian systems
crypto/aegis.h | 23 +---
crypto/morus1280.c | 7 ++
On Wed, Sep 19, 2018 at 10:42:16PM +0530, Harsh Jain wrote:
> Update PCI Id in "cpl_rx_phys_dsgl" header. In case pci_chan_id and
> tx_chan_id are not derived from same queue, H/W can send request
> completion indication before completing DMA Transfer.
>
> Herbert, It would be good if fix can be
On Wed, Sep 19, 2018 at 05:54:21PM +0300, Horia Geantă wrote:
> Commit 110492183c4b ("crypto: compress - remove unused pcomp interface")
> removed pcomp interface but missed cleaning up tcrypt.
>
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page:
On Mon, Sep 17, 2018 at 08:24:32PM +0300, Dan Aloni wrote:
> The encryption mode of pkcs1pad never uses out_sg and out_buf, so
> there's no need to allocate the buffer, which presently is not even
> being freed.
>
> CC: Herbert Xu
> CC: linux-crypto@vger.kernel.org
> CC: "David S. Miller"
>
On Wed, Sep 12, 2018 at 05:07:17PM +0100, Jonathan Cameron wrote:
> There should not be a comma in the address used for the instance
> so drop them.
>
> This is a left over from a review of the final version before
> Herbert Xu picked the series up.
>
> Reported-by: Rob Herring
> Signed-off-by:
On Wed, Sep 26, 2018 at 5:43 PM Kees Cook wrote:
> On Wed, Sep 26, 2018 at 2:51 AM, Ard Biesheuvel
> wrote:
>
> I think the depth warning is minor (90 bytes over), so I don't think
> it's high priority to backport the fix. I'm fine either way, of
> course.
The way I see these warnings,
On Wed, Sep 26, 2018 at 5:42 PM Ard Biesheuvel
wrote:
>
> On Wed, 26 Sep 2018 at 16:02, Ard Biesheuvel
> wrote:
> Actually, looking at the code again, the abstraction does appear to be
> fine, it is just the chacha20 code that does not make use of it.
So what you have in mind is something like
On Wed, Sep 26, 2018 at 2:51 AM, Ard Biesheuvel
wrote:
> Arnd reports that with Kees's latest VLA patches applied, the HMAC
> handling in the QAT driver uses a worst case estimate of 160 bytes
> for the SHA blocksize, allowing the compiler to determine the size
> of the stack frame at runtime and
Hi Leonard,
On Wed, Sep 26, 2018 at 7:31 AM, Leonard Crestez
wrote:
> That's not very easy since I don't know much about crypto api and don't
> understand the patches. From what I do know some of them look a bit
I am in the same position too :-)
> dubious, I'm not sure those issues can't be
On Fri, 2018-09-21 at 19:09 -0300, Fabio Estevam wrote:
> On Fri, Sep 21, 2018 at 5:13 PM, Leonard Crestez
> wrote:
> > The mxs-dcp driver fails to probe if sha1/sha256 are supported:
> >
> > [2.455404] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
> > [2.464042] mxs-dcp: probe of
On Wed, 26 Sep 2018 at 11:53, Ard Biesheuvel wrote:
>
> Arnd reports that with Kees's latest VLA patches applied, the HMAC
> handling in the QAT driver uses a worst case estimate of 160 bytes
> for the SHA blocksize, allowing the compiler to determine the size
> of the stack frame at runtime and
Fixes the following sparse warning:
drivers/crypto/ccp/psp-dev.c:444:5: warning:
symbol 'sev_get_firmware' was not declared. Should it be static?
Fixes: e93720606efd ("crypto: ccp - Allow SEV firmware to be chosen based on
Family and Model")
Signed-off-by: Wei Yongjun
---
v1 -> v2: add fixes
On 09/25/2018 09:35 AM, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/crypto/ccp/psp-dev.c:444:5: warning:
> symbol 'sev_get_firmware' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun
This appears to have been introduced by (cryptodev-2.6) commit
Fixes the following sparse warning:
drivers/crypto/ccp/psp-dev.c:444:5: warning:
symbol 'sev_get_firmware' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
drivers/crypto/ccp/psp-dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
For historical reasons, the AES-NI based implementation of the PCBC
chaining mode uses a special FPU chaining mode wrapper template to
amortize the FPU start/stop overhead over multiple blocks.
When this FPU wrapper was introduced, it supported widely used
chaining modes such as XTS and CTR (as
Hi Leonard,
On Fri, Sep 21, 2018 at 5:13 PM, Leonard Crestez
wrote:
> The mxs-dcp driver fails to probe if sha1/sha256 are supported:
>
> [2.455404] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
> [2.464042] mxs-dcp: probe of 80028000.dcp failed with error -22
>
> This happens
The mxs-dcp driver fails to probe if sha1/sha256 are supported:
[2.455404] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
[2.464042] mxs-dcp: probe of 80028000.dcp failed with error -22
This happens because since commit 8996eafdcbad ("crypto: ahash - ensure
statesize is non-zero")
On Fri, Sep 14, 2018 at 06:34:28PM +0300, Horia Geantă wrote:
> In some cases the zero-length hw_desc array at the end of
> ablkcipher_edesc struct requires for 4B of tail padding.
>
> Due to tail padding and the way pointers to S/G table and IV
> are computed:
> edesc->sec4_sg = (void
On Wed, Sep 12, 2018 at 04:20:48PM +0300, Horia Geantă wrote:
> ghash is a keyed hash algorithm, thus setkey needs to be called.
> Otherwise the following error occurs:
> $ modprobe tcrypt mode=318 sec=1
> testing speed of async ghash-generic (ghash-generic)
> tcrypt: test 0 ( 16 byte blocks,
On Tue, Sep 11, 2018 at 08:05:10PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for
> chacha20_block()"), I had missed that chacha20_block() can be called
> directly on the buffer passed to get_random_bytes(), which can
On Mon, Sep 10, 2018 at 04:41:11PM +0200, Ard Biesheuvel wrote:
> Some cleanups and optimizations for the arm64 AES skcipher routines.
>
> Patch #1 fixes the peculiar use of u8 arrays to refer to AES round keys,
> which are natively arrays of u32.
>
> Patch #2 partially reverts the use of NEON
On Tue, Sep 11, 2018 at 09:40:08AM +0200, Ondrej Mosnacek wrote:
> Since commit acb9b159c784 ("crypto: gf128mul - define gf128mul_x_* in
> gf128mul.h"), the gf128mul_x_*() functions are very fast and therefore
> caching the computed XTS tweaks has only negligible advantage over
> computing them
On 10 September 2018 at 07:41, Ard Biesheuvel wrote:
> Some cleanups and optimizations for the arm64 AES skcipher routines.
>
> Patch #1 fixes the peculiar use of u8 arrays to refer to AES round keys,
> which are natively arrays of u32.
>
> Patch #2 partially reverts the use of NEON yield calls,
On Tue, Sep 18, 2018 at 01:00:31PM -0400, Sandy Harris wrote:
> Solutions have been proposed by various people. If I understand them
> right, Ted Ts'o suggests modifying the boot loader to provide some
> entropy & John Denker suggests that every machine should be
> provisioned with some entropy in
Update PCI Id in "cpl_rx_phys_dsgl" header. In case pci_chan_id and
tx_chan_id are not derived from same queue, H/W can send request
completion indication before completing DMA Transfer.
Herbert, It would be good if fix can be merge to stable tree.
For 4.14 kernel, It requires some update to
Commit 110492183c4b ("crypto: compress - remove unused pcomp interface")
removed pcomp interface but missed cleaning up tcrypt.
Signed-off-by: Horia Geantă
---
crypto/tcrypt.c | 7 +--
crypto/testmgr.h | 2 --
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/crypto/tcrypt.c
Dear,
I am working in financial firm in Asia. I have a business to transfer the sum
of $19.000.000.00 of abandon fund in my office.
If you are,interested in the transaction reply on my email for more details.
Best Regards,
Danny Chan.
On Tue, Sep 18, 2018 at 7:03 PM John Denker wrote:
> > Is a fix that only deals with a subset of the problem worth
> > considering? Just patch the VM support code so that any time a VM is
> > either booted or re-started after a save, the host system drops in
> > some entropy, ...
>
> Good
On 09/18/2018 10:00 AM, Sandy Harris wrote:
> Is a fix that only deals with a subset of the problem worth
> considering? Just patch the VM support code so that any time a VM is
> either booted or re-started after a save, the host system drops in
> some entropy, This looks relatively easy to do,
Getting the random driver well initialised early enough is a hard
problem, at least on some machines.
Solutions have been proposed by various people. If I understand them
right, Ted Ts'o suggests modifying the boot loader to provide some
entropy & John Denker suggests that every machine should be
On 9/17/18 3:04 PM, Dan Aloni wrote:
> That's also true, but what I still don't understand is how
> pkcs1pad_decrypt_complete() would be called when a higher layer calls to
> *encrypt* in roughly this API call sequence:
>
>ak_tfm = crypto_alloc_akcipher("pkcs1pad(rsa,sha256)", 0, 0);
>
On Mon, Sep 17, 2018 at 02:39:46PM -0700, Tadeusz Struk wrote:
> On 9/17/18 1:28 PM, Dan Aloni wrote:
> > On Mon, Sep 17, 2018 at 12:52:44PM -0700, Tadeusz Struk wrote:
> >> On 9/17/18 10:24 AM, Dan Aloni wrote:
> >>> The encryption mode of pkcs1pad never uses out_sg and out_buf, so
> >>> there's
On 9/17/18 1:28 PM, Dan Aloni wrote:
> On Mon, Sep 17, 2018 at 12:52:44PM -0700, Tadeusz Struk wrote:
>> On 9/17/18 10:24 AM, Dan Aloni wrote:
>>> The encryption mode of pkcs1pad never uses out_sg and out_buf, so
>>> there's no need to allocate the buffer, which presently is not even
>>> being
On Mon, Sep 17, 2018 at 12:52:44PM -0700, Tadeusz Struk wrote:
> On 9/17/18 10:24 AM, Dan Aloni wrote:
> > The encryption mode of pkcs1pad never uses out_sg and out_buf, so
> > there's no need to allocate the buffer, which presently is not even
> > being freed.
>
> It is used and freed in
On 9/17/18 10:24 AM, Dan Aloni wrote:
> The encryption mode of pkcs1pad never uses out_sg and out_buf, so
> there's no need to allocate the buffer, which presently is not even
> being freed.
It is used and freed in pkcs1pad_decrypt_complete().
--
Tadeusz
The encryption mode of pkcs1pad never uses out_sg and out_buf, so
there's no need to allocate the buffer, which presently is not even
being freed.
CC: Herbert Xu
CC: linux-crypto@vger.kernel.org
CC: "David S. Miller"
Signed-off-by: Dan Aloni
---
crypto/rsa-pkcs1pad.c | 9 -
1 file
Hi Brijesh,
excellent work!
Thanks, Thomas
On Sat, 2018-09-15 at 06:44 -0500, Brijesh Singh wrote:
> Hi,
>
> The workaround to handle this FW bug has been submitted last month
>
> https://marc.info/?l=linux-crypto-vger=153436754612783=2
>
> And patch is accepted in crypto tree
>
>
Hi,
The workaround to handle this FW bug has been submitted last month
https://marc.info/?l=linux-crypto-vger=153436754612783=2
And patch is accepted in crypto tree
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?id=3702a0585e64d70d5bf73bf3e943b8d6005b72c1
It
Hi, please find below a list of related bugs to a blocker that affects
existing systems and even prevents the installation of several Linux
distributions:
https://bugzilla.kernel.org/show_bug.cgi?id=199267
https://bugzilla.kernel.org/show_bug.cgi?id=201129
Hi Yann,
On Wed, Sep 12, 2018 at 11:50:00AM +0200, Yann Droneaud wrote:
> Hi,
>
> Le mardi 11 septembre 2018 à 20:05 -0700, Eric Biggers a écrit :
> > From: Eric Biggers
> >
> > In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for
> > chacha20_block()"), I had missed that
In some cases the zero-length hw_desc array at the end of
ablkcipher_edesc struct requires for 4B of tail padding.
Due to tail padding and the way pointers to S/G table and IV
are computed:
edesc->sec4_sg = (void *)edesc + sizeof(struct ablkcipher_edesc) +
On Wed, Sep 05, 2018 at 09:18:43AM -0400, Mikulas Patocka wrote:
> This patch fixes gcmaes_crypt_by_sg so that it won't use memory
> allocation if the data doesn't cross a page boundary.
>
> Authenticated encryption may be used by dm-crypt. If the encryption or
> decryption fails, it would result
On Wed, Sep 05, 2018 at 01:52:44AM +0800, kbuild test robot wrote:
>
> Fixes: b76377543b73 ("crc-t10dif: Pick better transform if one becomes
> available")
> Signed-off-by: kbuild test robot
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On Wed, Sep 05, 2018 at 09:26:41AM +0200, Ondrej Mosnacek wrote:
> It turns out OSXSAVE needs to be checked only for AVX, not for SSE.
> Without this patch the affected modules refuse to load on CPUs with SSE2
> but without AVX support.
>
> Fixes: 877ccce7cbe8 ("crypto: x86/aegis,morus - Fix and
On Fri, Sep 07, 2018 at 02:57:42AM +0100, Ben Hutchings wrote:
> The current constraints for inline "rep xcrypt*" instructions mark ecx
> as an input only. The compiler can therefore assume wrongly that ecx
> holds the same value afterward, but in reality it will contain 0.
>
> This previously
On 13 September 2018 at 08:24, Stefan Agner wrote:
> On 10.09.2018 00:01, Ard Biesheuvel wrote:
>> On 10 September 2018 at 08:21, Stefan Agner wrote:
>>> Hi Ard,
>>>
>>> On 21.05.2017 03:23, Ard Biesheuvel wrote:
Make the module autoloadable by tying it to the CPU feature bit that
On 10.09.2018 00:01, Ard Biesheuvel wrote:
> On 10 September 2018 at 08:21, Stefan Agner wrote:
>> Hi Ard,
>>
>> On 21.05.2017 03:23, Ard Biesheuvel wrote:
>>> Make the module autoloadable by tying it to the CPU feature bit that
>>> describes whether the optional instructions it relies on are
Reported-by: Rob Herring
Signed-off-by: Jonathan Cameron
Fixes: e4a1f7858ab8 ("arm64: dts: hisi: add SEC crypto accelerator nodes for
hip07 SoC")
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 28
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git
There should not be a comma in the address used for the instance
so drop them.
This is a left over from a review of the final version before
Herbert Xu picked the series up.
Reported-by: Rob Herring
Signed-off-by: Jonathan Cameron
Fixes: 8f026dc887fe ("dt-bindings: Add bidnings for Hisilicon
Rob Herring picked up on an issue in our sec dt binding doc where we had
an unnecessary comma in the addresses provided as part of the node name.
The comment wasn't fixed before the series was applied, hence this follow up.
This was a cut and paste job from a few of the its entries already
On 12 September 2018 at 15:20, Horia Geantă wrote:
> ghash is a keyed hash algorithm, thus setkey needs to be called.
> Otherwise the following error occurs:
> $ modprobe tcrypt mode=318 sec=1
> testing speed of async ghash-generic (ghash-generic)
> tcrypt: test 0 ( 16 byte blocks, 16 bytes
ghash is a keyed hash algorithm, thus setkey needs to be called.
Otherwise the following error occurs:
$ modprobe tcrypt mode=318 sec=1
testing speed of async ghash-generic (ghash-generic)
tcrypt: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):
tcrypt: hashing failed ret=-126
Cc:
Hi,
Le mardi 11 septembre 2018 à 20:05 -0700, Eric Biggers a écrit :
> From: Eric Biggers
>
> In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for
> chacha20_block()"), I had missed that chacha20_block() can be called
> directly on the buffer passed to get_random_bytes(),
From: Eric Biggers
In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for
chacha20_block()"), I had missed that chacha20_block() can be called
directly on the buffer passed to get_random_bytes(), which can have any
alignment. So, while my commit didn't break anything, it didn't
To revive this...
On Fri, Aug 10, 2018 at 08:27:58AM +0200, Stephan Mueller wrote:
> Am Donnerstag, 9. August 2018, 21:40:12 CEST schrieb Eric Biggers:
>
> Hi Eric,
>
> > while (bytes >= CHACHA20_BLOCK_SIZE) {
> > chacha20_block(state, stream);
> > - crypto_xor(dst,
For some reason, the asmlinkage prototypes of the NEON routines take
u8[] arguments for the round key arrays, while the actual round keys
are arrays of u32, and so passing them into those routines requires
u8* casts at each occurrence. Fix that.
Signed-off-by: Ard Biesheuvel
---
The reasoning of commit f10dc56c64bb ("crypto: arm64 - revert NEON yield
for fast AEAD implementations") applies equally to skciphers: the walk
API already guarantees that the input size of each call into the NEON
code is bounded to the size of a page, and so there is no need for an
additional
The Crypto Extension instantiation of the aes-modes.S collection of
skciphers uses only 15 NEON registers for the round key array, whereas
the pure NEON flavor uses 16 NEON registers for the AES S-box.
This means we have a spare register available that we can use to hold
the XTS mask vector,
Some cleanups and optimizations for the arm64 AES skcipher routines.
Patch #1 fixes the peculiar use of u8 arrays to refer to AES round keys,
which are natively arrays of u32.
Patch #2 partially reverts the use of NEON yield calls, which is not
needed for skciphers.
Patch #3 adds support for
Currently, we rely on the generic CTS chaining mode wrapper to
instantiate the cts(cbc(aes)) skcipher. Due to the high performance
of the ARMv8 Crypto Extensions AES instructions (~1 cycles per byte),
any overhead in the chaining mode layers is amplified, and so it pays
off considerably to fold
On 10 September 2018 at 08:21, Stefan Agner wrote:
> Hi Ard,
>
> On 21.05.2017 03:23, Ard Biesheuvel wrote:
>> Make the module autoloadable by tying it to the CPU feature bit that
>> describes whether the optional instructions it relies on are implemented
>> by the current CPU.
>>
>
> This leads
Hi Ard,
On 21.05.2017 03:23, Ard Biesheuvel wrote:
> Make the module autoloadable by tying it to the CPU feature bit that
> describes whether the optional instructions it relies on are implemented
> by the current CPU.
>
This leads to a compiler warning when compiling multi_v7_defconfig/ARM32
Currently, we rely on the generic CTS chaining mode wrapper to
instantiate the cts(cbc(aes)) skcipher. Due to the high performance
of the ARMv8 Crypto Extensions AES instructions (~1 cycles per byte),
any overhead in the chaining mode layers is amplified, and so it pays
off considerably to fold
The current constraints for inline "rep xcrypt*" instructions mark ecx
as an input only. The compiler can therefore assume wrongly that ecx
holds the same value afterward, but in reality it will contain 0.
This previously led to data corruption, which was fixed around by
commit 46d8c4b28652
On 5 September 2018 at 21:24, Eric Biggers wrote:
> From: Eric Biggers
>
> fscrypt doesn't use the CTR mode of operation for anything, so there's
> no need to select CRYPTO_CTR. It was added by commit 71dea01ea2ed
> ("ext4 crypto: require CONFIG_CRYPTO_CTR if ext4 encryption is
> enabled").
From: Eric Biggers
fscrypt doesn't use the CTR mode of operation for anything, so there's
no need to select CRYPTO_CTR. It was added by commit 71dea01ea2ed
("ext4 crypto: require CONFIG_CRYPTO_CTR if ext4 encryption is
enabled"). But, I've been unable to identify the arm64 crypto bug it
was
This patch fixes gcmaes_crypt_by_sg so that it won't use memory
allocation if the data doesn't cross a page boundary.
Authenticated encryption may be used by dm-crypt. If the encryption or
decryption fails, it would result in I/O error and filesystem corruption.
The function gcmaes_crypt_by_sg is
It turns out OSXSAVE needs to be checked only for AVX, not for SSE.
Without this patch the affected modules refuse to load on CPUs with SSE2
but without AVX support.
Fixes: 877ccce7cbe8 ("crypto: x86/aegis,morus - Fix and simplify CPUID checks")
Cc: # 4.18
Reported-by: Zdenek Kaspar
On Tue, Sep 04, 2018 at 09:18:32AM -0500, Rob Herring wrote:
> On Mon, Sep 3, 2018 at 10:09 PM Herbert Xu
> wrote:
> >
> > On Mon, Aug 06, 2018 at 07:48:52AM -0400, Robert P. J. Day wrote:
> > >
> > > Signed-off-by: Robert P. J. Day
> >
> > Adding Rob Herring to the cc list.
>
> Please resend
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: a1b22a5f45fe884147a99e7c381bcc48d9b2acef
commit: b76377543b738a6b58b0a7b0a42dd9e16436fee1 [22/24] crc-t10dif: Pick
better transform if one becomes available
reproduce:
# apt-get install
Fixes: b76377543b73 ("crc-t10dif: Pick better transform if one becomes
available")
Signed-off-by: kbuild test robot
---
crc-t10dif.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/crc-t10dif.c b/lib/crc-t10dif.c
index 52f577a3..8e144c3 100644
--- a/lib/crc-t10dif.c
On Mon, Sep 3, 2018 at 10:09 PM Herbert Xu wrote:
>
> On Mon, Aug 06, 2018 at 07:48:52AM -0400, Robert P. J. Day wrote:
> >
> > Signed-off-by: Robert P. J. Day
>
> Adding Rob Herring to the cc list.
Please resend to DT list if you want me to take it. Otherwise,
Acked-by: Rob Herring
On Sat, Sep 01, 2018 at 12:17:07AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Optimize ChaCha20 NEON performance by:
>
> - Implementing the 8-bit rotations using the 'vtbl.8' instruction.
> - Streamlining the part that adds the original state and XORs the data.
> - Making some other
On Mon, Aug 27, 2018 at 05:38:10PM +0200, Ard Biesheuvel wrote:
> The current arm64 CRC-T10DIF code only runs on cores that implement the
> 64x64 bit PMULL instructions that are part of the optional Crypto
> Extensions, and falls back to the highly inefficient C code otherwise.
>
> Let's provide
On Thu, Aug 30, 2018 at 11:00:14AM -0400, Martin K. Petersen wrote:
> Introduce a facility that can be used to receive a notification
> callback when a new algorithm becomes available. This can be used by
> existing crypto registrations to trigger a switch from a software-only
> algorithm to a
On Mon, Aug 27, 2018 at 01:02:45PM +0200, Ard Biesheuvel wrote:
> Now that the scalar fallbacks have been moved out of this driver into
> the core crc32()/crc32c() routines, we are left with a CRC32 crypto API
> driver for arm64 that is based only on 64x64 polynomial multiplication,
> which is an
On Thu, Aug 23, 2018 at 05:48:45PM +0100, Ard Biesheuvel wrote:
> Replace the literal load of the addend vector with a sequence that
> performs each add individually. This sequence is only 2 instructions
> longer than the original, and 2% faster on Cortex-A53.
>
> This is an improvement by
On Thu, Aug 23, 2018 at 03:48:51PM +0100, Ard Biesheuvel wrote:
> Speed up the GHASH algorithm based on 64-bit polynomial multiplication
> by adding support for 4-way aggregation. This improves throughput by
> ~85% on Cortex-A53, from 1.7 cycles per byte to 0.9 cycles per byte.
>
> When combined
On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote:
> v8 cover letter:
>
> I continue to hope this can land in v4.19, but I realize that's unlikely.
> It would be nice, though, if some of the "trivial" patches could get taken
> (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep
On Wed, Aug 22, 2018 at 10:51:44AM +0200, Ard Biesheuvel wrote:
> As it turns out, the AVX2 multibuffer SHA routines are currently
> broken [0], in a way that would have likely been noticed if this
> code were in wide use. Since the code is too complicated to be
> maintained by anyone except the
On Wed, Aug 15, 2018 at 04:11:25PM -0500, Brijesh Singh wrote:
> Currently, the CCP driver assumes that the SEV command issued to the PSP
> will always return (i.e. it will never hang). But recently, firmware bugs
> have shown that a command can hang. Since of the SEV commands are used
> in
On Tue, Aug 21, 2018 at 04:36:09PM +0300, Tudor Ambarus wrote:
> Adopt the SPDX license identifiers to ease license compliance
> management.
>
> Signed-off-by: Tudor Ambarus
> ---
> drivers/crypto/atmel-aes.c | 5 +
> drivers/crypto/atmel-authenc.h | 13 +
>
On Tue, Aug 07, 2018 at 08:22:25AM +0200, Jason A. Donenfeld wrote:
> These are unused, undesired, and have never actually been used by
> anybody. The original authors of this code have changed their mind about
> its inclusion. While originally proposed for disk encryption on low-end
> devices,
On Mon, Aug 06, 2018 at 03:43:56PM +0300, Horia Geantă wrote:
> This patch set converts caam/jr and caam/qi top level drivers
> from ablkcipher API to skcipher.
>
> First two patches remove the unused ablkcipher algorithms with
> support for IV generation.
> The following two patches deal with
On Mon, Aug 06, 2018 at 07:48:52AM -0400, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day
Adding Rob Herring to the cc list.
>
> ---
>
> diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
>
From: Eric Biggers
Optimize ChaCha20 NEON performance by:
- Implementing the 8-bit rotations using the 'vtbl.8' instruction.
- Streamlining the part that adds the original state and XORs the data.
- Making some other small tweaks.
On ARM Cortex-A7, these optimizations improve ChaCha20
On Fri, Aug 31, 2018 at 06:51:34PM +0200, Ard Biesheuvel wrote:
> >>
> >> + adr ip, .Lrol8_table
> >> mov r3, #10
> >>
> >> .Ldoubleround4:
> >> @@ -238,24 +268,25 @@ ENTRY(chacha20_4block_xor_neon)
> >> // x1 += x5, x13 = rotl32(x13 ^ x1, 8)
> >>
Hi Ard,
On Fri, Aug 31, 2018 at 05:56:24PM +0200, Ard Biesheuvel wrote:
> Hi Eric,
>
> On 31 August 2018 at 10:01, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Optimize ChaCha20 NEON performance by:
> >
> > - Implementing the 8-bit rotations using the 'vtbl.8' instruction.
> > -
On 31 August 2018 at 17:56, Ard Biesheuvel wrote:
> Hi Eric,
>
> On 31 August 2018 at 10:01, Eric Biggers wrote:
>> From: Eric Biggers
>>
>> Optimize ChaCha20 NEON performance by:
>>
>> - Implementing the 8-bit rotations using the 'vtbl.8' instruction.
>> - Streamlining the part that adds the
Hi Eric,
On 31 August 2018 at 10:01, Eric Biggers wrote:
> From: Eric Biggers
>
> Optimize ChaCha20 NEON performance by:
>
> - Implementing the 8-bit rotations using the 'vtbl.8' instruction.
> - Streamlining the part that adds the original state and XORs the data.
> - Making some other small
From: Eric Biggers
Optimize ChaCha20 NEON performance by:
- Implementing the 8-bit rotations using the 'vtbl.8' instruction.
- Streamlining the part that adds the original state and XORs the data.
- Making some other small tweaks.
On ARM Cortex-A7, these optimizations improve ChaCha20
Hello Atul Gupta,
The patch 36bedb3f2e5b: "crypto: chtls - Inline TLS record Tx" from
Mar 31, 2018, leads to the following static checker warning:
drivers/crypto/chelsio/chtls/chtls_io.c:1036 chtls_sendmsg()
warn: assigning signed to unsigned: 'csk->tlshws.txleft = recordsz'
Hello Tero Kristo,
This is a semi-automatic email about new static checker warnings.
The patch ad18cc9d0f91: "crypto: omap-aes - Add support for GCM mode"
from May 24, 2017, leads to the following Smatch complaint:
drivers/crypto/omap-aes.c:1262 omap_aes_probe()
error: we previously
On Sun, Aug 26, 2018 at 08:12:06AM +0200, Greg KH wrote:
>
> The patch didn't apply, but I fixed it :)
>
> Now queued up.
Thanks Greg!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
i have been trying to contact you
On Fri, Aug 24, 2018 at 09:51:41AM +0200, Petr Vorel wrote:
> Hi Herbert,
>
> > On Thu, Aug 23, 2018 at 05:31:01PM +0200, Petr Vorel wrote:
> > > Hi,
>
> > > I wonder, it it makes sense to backport commit
> > > e666d4e9ceec crypto: vmx - Use skcipher for ctr fallback
> > > to v 4.14 stable
Dear sir ,
I KELLY ALAN purchasing and sales manager of CFM INTERNATIONAL .Our
Company specialised in Supplying computer hardware and Electronic .We
want to extend our supplier list because of concurrency in prices on the
international market. We are seeking a supplier with whom we can to
On Mon, Aug 20, 2018 at 04:58:34PM +0200, Ard Biesheuvel wrote:
> Commit 71e52c278c54 ("crypto: arm64/aes-ce-gcm - operate on
> two input blocks at a time") modified the granularity at which
> the AES/GCM code processes its input to allow subsequent changes
> to be applied that improve performance
On Tue, Aug 07, 2018 at 11:18:36PM +0200, Ard Biesheuvel wrote:
> ARMv8.2 specifies special instructions for the SM3 cryptographic hash
> and the SM4 symmetric cipher. While it is unlikely that a core would
> implement one and not the other, we should only use SM4 instructions
> if the SM4 CPU
201 - 300 of 29368 matches
Mail list logo
