On Sun, Sep 30, 2018 at 10:59 AM Ard Biesheuvel
wrote:
> Omit the endian swabbing when folding the lengths of the assoc and
> crypt input buffers into the state to finalize the tag. This is not
> necessary given that the memory representation of the state is in
> machine native endianness
On Sun, Sep 30, 2018 at 9:51 PM Ard Biesheuvel
wrote:
> Due to an unfortunate interaction between commit fbe1a850b3b1
> ("crypto: lrw - Fix out-of bounds access on counter overflow") and
> commit c778f96bf347 ("crypto: lrw - Optimize tweak computation"),
> we ended up with a version of
On 30 September 2018 at 10:58, Ard Biesheuvel wrote:
> Use the correct __le32 annotation and accessors to perform the
> single round of AES encryption performed inside the AEGIS transform.
> Otherwise, tcrypt reports:
>
> alg: aead: Test 1 failed on encryption for aegis128-generic
> :
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
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
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
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,
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, at least for Linux
> VMs, and some of the code might be the same as what the more general
&g
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
> > so
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 relativel
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
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 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
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
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
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(),
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,
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
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").
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
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
>
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)
> >>
row of each
> > block)
> > + vld1.32 {q0}, [ip, :128]// load (1, 0, 2, 0)
>
> Would something like
>
> vmov.i32d0, #1
> vmovl.u32 q0, d0
> vadd.u64d1, d1
>
> (untested) work as well?
>
> >
+ sub ip, sp, #0x20 // allocate a 32 byte buffer
>> + bic ip, ip, #0x1f // aligned to 32 bytes
>> + mov sp, ip
>>
>
> Is there a reason for preferring ip over r3 for preserving the
> ori
t; // r1: 4 data blocks output, o
> @@ -157,25 +187,24 @@ ENTRY(chacha20_4block_xor_neon)
> // This function encrypts four consecutive ChaCha20 blocks by loading
> // the state matrix in NEON registers four times. The algorithm
> performs
> // each operati
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
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
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
On Mon, Aug 06, 2018 at 03:29:39PM +0300, Horia Geantă wrote:
> xts setkey callback returns 0 on some error paths.
> Fix this by returning -EINVAL.
>
> Cc: # 4.12+
> Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc
> algorithms")
> Signed-off-by: Horia Geantă
Patch applied.
On Mon, Aug 06, 2018 at 03:29:55PM +0300, Horia Geantă wrote:
> Crypto engine needs some temporary locations in external memory for
> running RSA decrypt forms 2 and 3 (CRT).
> These are named "tmp1" and "tmp2" in the PDB.
>
> Update DMA mapping direction of tmp1 and tmp2 from TO_DEVICE to
>
On Mon, Aug 06, 2018 at 03:29:09PM +0300, Horia Geantă wrote:
> Descriptor address needs to be swapped to CPU endianness before being
> DMA unmapped.
>
> Cc: # 4.8+
> Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam
> endianness")
> Reported-by: Laurentiu Tudor
>
Jiecheng Wu wrote:
> Function chtls_close_conn() defined in
> drivers/crypto/chelsio/chtls/chtls_cm.c calls alloc_skb() to allocate memory
> for struct sk_buff which is dereferenced immediately. As alloc_skb() may
> return NULL on failure, this code piece may cause NULL pointer dereference
>
On Tue, Aug 07, 2018 at 12:34:57PM +, Horia Geanta wrote:
> On 8/7/2018 11:00 AM, Marcin Niestroj wrote:
> > It is possible, that caam_jr_alloc() is called before JR devices are
> > probed. Return -EPROBE_DEFER in drivers that rely on JR devices, so
> > they are probed at later stage.
> >
>
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 kernel.
> > I'm using it in 4.12+.
> > These commits (somehow similar) has been
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 kernel.
> I'm using it in 4.12+.
>
> These commits (somehow similar) has been backported to 4.10.2:
>
On 23 August 2018 at 21:04, Nick Desaulniers wrote:
> On Thu, Aug 23, 2018 at 9:48 AM 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%
On Thu, Aug 23, 2018 at 9:48 AM 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 itself, but
On 21 August 2018 at 20:34, Nick Desaulniers wrote:
> On Tue, Aug 21, 2018 at 11:19 AM Ard Biesheuvel
> wrote:
>>
>> On 21 August 2018 at 20:04, Nick Desaulniers wrote:
>> > On Tue, Aug 21, 2018 at 9:46 AM Ard Biesheuvel
>> > wrote:
>> >>
>> >> Replace the literal load of the addend vector
On Tue, Aug 21, 2018 at 11:19 AM Ard Biesheuvel
wrote:
>
> On 21 August 2018 at 20:04, Nick Desaulniers wrote:
> > On Tue, Aug 21, 2018 at 9:46 AM Ard Biesheuvel
> > wrote:
> >>
> >> Replace the literal load of the addend vector with a sequence that
> >> composes it using immediates. While at
On 21 August 2018 at 20:04, Nick Desaulniers wrote:
> On Tue, Aug 21, 2018 at 9:46 AM Ard Biesheuvel
> wrote:
>>
>> Replace the literal load of the addend vector with a sequence that
>> composes it using immediates. While at it, tweak the code that refers
>> to it so it does not clobber the
On Tue, Aug 21, 2018 at 9:46 AM Ard Biesheuvel
wrote:
>
> Replace the literal load of the addend vector with a sequence that
> composes it using immediates. While at it, tweak the code that refers
> to it so it does not clobber the register, so we can take the load
> out of the loop as well.
>
>
ut 21. 8. 2018 o 16:18 Stephan Mueller napísal(a):
> Am Dienstag, 21. August 2018, 14:48:11 CEST schrieb Ondrej Mosnáček:
>
> Hi Ondrej, Marcelo,
>
> (+Marcelo)
>
> > Looking at crypto/algif_skcipher.c, I can see that skcipher_recvmsg()
> > holds the socket lock the whole time and yet passes
> >
Am Dienstag, 21. August 2018, 14:48:11 CEST schrieb Ondrej Mosnáček:
Hi Ondrej, Marcelo,
(+Marcelo)
> Looking at crypto/algif_skcipher.c, I can see that skcipher_recvmsg()
> holds the socket lock the whole time and yet passes
> CRYPTO_TFM_REQ_MAY_SLEEP to the cipher implementation. Isn't that
> -Original Message-
> From: Ard Biesheuvel
> Sent: Monday, August 20, 2018 8:29 PM
> To: linux-crypto@vger.kernel.org
> Cc: herb...@gondor.apana.org.au; Vakul Garg ;
> davejwat...@fb.com; Peter Doliwa ; Ard
> Biesheuvel
> Subject: [PATCH] crypto: arm64/aes-gcm-ce - fix scatterwalk
Am Donnerstag, 16. August 2018, 09:14:59 CEST schrieb Jitendra Lulla:
Hi Jitendra,
> Hi Stephen,
>
> I could not spot in the kernel where we are computing GHASH when the
> IV is bigger than 12 Bytes for GCM encryption.
>
> libkcapi and kernel appears to ignore the bytes beyond 12th byte in the
On Mon, 6 Aug 2018 23:12:44 +0300
Dan Carpenter wrote:
> Hello Jonathan Cameron,
>
> The patch 915e4e8413da: "crypto: hisilicon - SEC security accelerator
> driver" from Jul 23, 2018, leads to the following static checker
> warning:
>
> drivers/crypto/hisilicon/sec/sec_algs.c:865
On Fri, Aug 10, 2018 at 08:20:51AM +0200, Stephan Mueller wrote:
> > while (nbytes >= CHACHA20_BLOCK_SIZE) {
> > int adjust = (unsigned long)buf & (sizeof(tmp[0]) - 1);
> >
> > extract_crng(buf);
>
> Why this line?
>
> > buf += CHACHA20_BLOCK_SIZE;
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, (const u8 *)stream, CHACHA20_BLOCK_SIZE);
> + crypto_xor(dst, stream,
Am Donnerstag, 9. August 2018, 21:21:32 CEST schrieb Theodore Y. Ts'o:
Hi Theodore,
> I'm wondering whether we have kernel code that actually tries to
> extract more than 64 bytes, so I'm not sure how often we enter the
> while loop at all. Out of curiosity, did you find this from code
>
Am Donnerstag, 9. August 2018, 21:07:18 CEST schrieb Eric Biggers:
Hi Eric,
> This patch is backwards: the temporary buffer is used when the buffer is
> *aligned*, not misaligned. And more problematically, 'buf' is never
> incremented in one of the cases...
Of course, it needs to be reversed.
Hi,
Le jeudi 09 août 2018 à 12:40 -0700, Eric Biggers a écrit :
> From: Eric Biggers
> Subject: [PATCH] crypto: chacha20 - Fix keystream alignment for
> chacha20_block() (again)
>
> In commit 9f480faec58cd6 ("crypto: chacha20 - Fix keystream alignment
> for chacha20_block()") I had missed that
On Thu, Aug 09, 2018 at 12:07:18PM -0700, Eric Biggers wrote:
> On Thu, Aug 09, 2018 at 08:38:56PM +0200, Stephan Müller wrote:
> > The function extract_crng invokes the ChaCha20 block operation directly
> > on the user-provided buffer. The block operation operates on u32 words.
> > Thus the
On Thu, Aug 09, 2018 at 08:38:56PM +0200, Stephan Müller wrote:
> The function extract_crng invokes the ChaCha20 block operation directly
> on the user-provided buffer. The block operation operates on u32 words.
> Thus the extract_crng function expects the buffer to be aligned to u32
> as it is
On Thu, Aug 09, 2018 at 08:38:56PM +0200, Stephan Müller wrote:
> The function extract_crng invokes the ChaCha20 block operation directly
> on the user-provided buffer. The block operation operates on u32 words.
> Thus the extract_crng function expects the buffer to be aligned to u32
> as it is
On Wed, Aug 08, 2018 at 04:30:09AM +, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/crypto/hisilicon/sec/sec_algs.c:396:5: warning:
> symbol 'sec_send_request' was not declared. Should it be static?
>
> Fixes: 915e4e8413da ("crypto: hisilicon - SEC security
On 8/7/2018 11:00 AM, Marcin Niestroj wrote:
> It is possible, that caam_jr_alloc() is called before JR devices are
> probed. Return -EPROBE_DEFER in drivers that rely on JR devices, so
> they are probed at later stage.
>
These drivers don't have a probe() callback.
Returning -EPROBE_DEFER in
On Sat, Aug 04, 2018 at 06:21:01AM +0800, kbuild test robot wrote:
>
> Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
> Signed-off-by: kbuild test robot
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On Sat, Aug 04, 2018 at 08:46:23PM +0200, Ard Biesheuvel wrote:
> Another bit of performance work on the GHASH driver: this time it is not
> the combined AES/GCM algorithm but the bare GHASH driver that gets updated.
>
> Even though ARM cores that implement the polynomical multiplication
>
On Fri, Aug 03, 2018 at 01:37:50PM +0200, Ondrej Mosnacek wrote:
> It turns out I had misunderstood how the x86_match_cpu() function works.
> It evaluates a logical OR of the matching conditions, not logical AND.
> This caused the CPU feature checks for AEGIS to pass even if only SSE2
> (but not
On 03/08/18 13:37, Ondrej Mosnacek wrote:
> It turns out I had misunderstood how the x86_match_cpu() function works.
> It evaluates a logical OR of the matching conditions, not logical AND.
> This caused the CPU feature checks for AEGIS to pass even if only SSE2
> (but not AES-NI) was supported
On 3 August 2018 at 17:47, Herbert Xu wrote:
> On Mon, Jul 30, 2018 at 11:06:39PM +0200, Ard Biesheuvel wrote:
>> Update the combined AES-GCM AEAD implementation to process two blocks
>> at a time, allowing us to switch to a faster version of the GHASH
>> implementation.
>>
>> Note that this does
101 - 200 of 16295 matches
Mail list logo
