> From: Jerome Glisse
> Sent: Thursday, September 13, 2018 10:52 PM
>
[...]
> AFAIK, on x86 and PPC at least, all PCIE devices are in the same group
> by default at boot or at least all devices behind the same bridge.
the group thing reflects physical hierarchy limitation, not changed
cross boot.
On 12 September 2018 at 20:34, Eric Biggers wrote:
> On Wed, Sep 12, 2018 at 08:19:21PM +0200, Ard Biesheuvel wrote:
>> On 12 September 2018 at 20:16, Jason A. Donenfeld wrote:
>> > Hi Eric,
>> >
>> > On Wed, Sep 12, 2018 at 12:08 AM Eric Biggers wrote:
>> >> I'd strongly prefer the assembly to
On 13 September 2018 at 17:58, Jason A. Donenfeld wrote:
> On Thu, Sep 13, 2018 at 5:43 PM Ard Biesheuvel
> wrote:
>> I'd prefer it if all the accelerated software implementations live in
>> the same place. But I do strongly prefer arch code to live in
>> arch/$arch
>
> Zinc follows the scheme of
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 Fri, Sep 07, 2018 at 12:31:18PM +0530, Srikanth Jampala wrote:
> Added support to configure SR-IOV using sysfs interface.
> Supported VF modes are 16, 32, 64 and 128. Grouped the
> hardware configuration functions to "nitrox_hal.h" file.
> Changed driver version to "1.1".
>
> Signed-off-by: Sri
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 s
On Thu, Sep 13, 2018 at 01:54:39PM -0400, Mike Snitzer wrote:
>
> Acked-by: Mike Snitzer
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Kalyani Akula wrote:
> ALG_SET_KEY_TYPE requires caller to pass the key_type to be used
> for AES encryption/decryption.
>
> Sometimes the cipher key will be stored in the device's
> hardware (eFuse, BBRAM etc).So,there is a need to specify the information
> about the key-type to use it for Encry
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 le
On Thu, Sep 13, 2018 at 10:51:50AM -0400, Jerome Glisse wrote:
> Date: Thu, 13 Sep 2018 10:51:50 -0400
> From: Jerome Glisse
> To: Kenneth Lee
> CC: Kenneth Lee , Alex Williamson
> , Herbert Xu ,
> k...@vger.kernel.org, Jonathan Corbet , Greg Kroah-Hartman
> , Zaibo Xu ,
> linux-...@vger.kern
RFC follow-up to
https://lkml.kernel.org/r/CAGXu5j+bpLK=EQ9LHkO8V=sdaQwt==6fbghgn2vi1e9_wxs...@mail.gmail.com
The core API changes:
struct crypto_sync_skcipher
crypto_alloc_sync_skcipher()
crypto_free_sync_skcipher()
crypto_sync_skcipher_setkey()
skcipher_
On Tue, Aug 07 2018 at 5:18pm -0400,
Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this uses
> the new HASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper
> bounds on stack usage.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfE
On Thu, Sep 13, 2018 at 9:46 AM, Kees Cook wrote:
> On Mon, Sep 10, 2018 at 10:52 PM, Herbert Xu
> wrote:
>> On Fri, Sep 07, 2018 at 08:56:23AM +0200, Ard Biesheuvel wrote:
>>>
>>> OK, so given that all SKCIPHER_REQUEST_ON_STACK occurrences are
>>> updated in this series anyway, perhaps we should
On Mon, Sep 10, 2018 at 10:52 PM, Herbert Xu
wrote:
> On Fri, Sep 07, 2018 at 08:56:23AM +0200, Ard Biesheuvel wrote:
>>
>> OK, so given that all SKCIPHER_REQUEST_ON_STACK occurrences are
>> updated in this series anyway, perhaps we should add
>> skcipher_[en|de]crypt_onstack() flavors that encaps
On Mon, Sep 3, 2018 at 8:13 PM, Herbert Xu wrote:
> On Tue, Aug 07, 2018 at 02:18:39PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this uses
>> the new HASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper
>> bounds on stack usage.
>>
>> [1]
On Thu, Sep 13, 2018 at 5:43 PM Ard Biesheuvel
wrote:
> I'd prefer it if all the accelerated software implementations live in
> the same place. But I do strongly prefer arch code to live in
> arch/$arch
Zinc follows the scheme of the raid6 code, as well as of most other
crypto libraries: code is
On Thu, Sep 13, 2018 at 5:04 PM Ard Biesheuvel
wrote:
> > The code still benefits from the review that's gone into OpenSSL. It's
> > not modified in ways that would affect the cryptographic operations
> > being done. It's modified to be suitable for kernel space.
>
> So could we please at least ha
On 13 September 2018 at 16:32, Jason A. Donenfeld wrote:
> On Thu, Sep 13, 2018 at 7:41 AM Ard Biesheuvel
> wrote:
>> But one of the supposed selling points of this crypto library is that
>> it gives engineers who are frightened of crypto in general and the
>> crypto API in particular simple and
> On Sep 12, 2018, at 11:39 PM, Milan Broz wrote:
>
>> On 13/09/18 01:45, Andy Lutomirski wrote:
>> On Wed, Sep 12, 2018 at 3:56 PM, Ard Biesheuvel
> ...
>> b) Crypto that is used dynamically. This includes dm-crypt
>> (aes-xts-plain64, aes-cbc-essiv, etc), all the ALG_IF interfaces, a
>> lot
On 13 September 2018 at 16:18, Jason A. Donenfeld wrote:
> On Thu, Sep 13, 2018 at 1:45 AM Andy Lutomirski wrote:
>> I'm not convinced that there's any real need for *all* crypto
>> algorithms to move into lib/zinc or to move at all. As I see it,
>> there are two classes of crypto algorithms in
On 13 September 2018 at 16:15, Jason A. Donenfeld wrote:
> Hi Ard,
>
> On Thu, Sep 13, 2018 at 12:56 AM Ard Biesheuvel
> wrote:
>> In this series, you are dumping a huge volume of unannotated,
>> generated asm into the kernel which has been modified [by you] to
>> [among other things?] adhere to
On Thu, Sep 13, 2018 at 04:32:32PM +0800, Kenneth Lee wrote:
> On Tue, Sep 11, 2018 at 09:40:14AM -0400, Jerome Glisse wrote:
> > On Tue, Sep 11, 2018 at 02:40:43PM +0800, Kenneth Lee wrote:
> > > On Mon, Sep 10, 2018 at 11:33:59PM -0400, Jerome Glisse wrote:
> > > > On Tue, Sep 11, 2018 at 10:42:0
Hi Milan,
On Thu, Sep 13, 2018 at 8:40 AM Milan Broz wrote:
> Please note, that dm-crypt now uses not only block ciphers and modes,
> but also authenticated encryption and hashes (for ESSIV and HMAC
> in authenticated composed modes) and RNG (for random IV).
> We use crypto API, including async v
On Thu, Sep 13, 2018 at 7:41 AM Ard Biesheuvel
wrote:
> But one of the supposed selling points of this crypto library is that
> it gives engineers who are frightened of crypto in general and the
> crypto API in particular simple and easy to use crypto primitives
> rather than having to jump throug
On Thu, Sep 13, 2018 at 1:45 AM Andy Lutomirski wrote:
> I'm not convinced that there's any real need for *all* crypto
> algorithms to move into lib/zinc or to move at all. As I see it,
> there are two classes of crypto algorithms in the kernel:
>
> a) Crypto that is used by code that chooses its
Hi Ard,
On Thu, Sep 13, 2018 at 12:56 AM Ard Biesheuvel
wrote:
> In this series, you are dumping a huge volume of unannotated,
> generated asm into the kernel which has been modified [by you] to
> [among other things?] adhere to the kernel API (without documenting
> what the changes are exactly).
This patchset contains a corner-case fix and several improvements for
the LRW template.
The first patch fixes an out-of-bounds array access (and subsequently
incorrect cipher output) when the LRW counter goes from all ones to all
zeros. This patch should be applied to the crypto-2.6 tree and also
This patch rewrites the tweak computation to a slightly simpler method
that performs less bswaps. Based on performance measurements the new
code seems to provide slightly better performance than the old one.
PERFORMANCE MEASUREMENTS (x86_64)
Performed using: https://gitlab.com/omos/linux-crypto-be
This patch simplifies the LRW template to recompute the LRW tweaks from
scratch in the second pass and thus also removes the need to allocate a
dynamic buffer using kmalloc().
As discussed at [1], the use of kmalloc causes deadlocks with dm-crypt.
PERFORMANCE MEASUREMENTS (x86_64)
Performed using
When the LRW block counter overflows, the current implementation returns
128 as the index to the precomputed multiplication table, which has 128
entries. This patch fixes it to return the correct value (127).
Fixes: 64470f1b8510 ("[CRYPTO] lrw: Liskov Rivest Wagner, a tweakable narrow
block ciphe
This patch adds a test vector for lrw(aes) that triggers wrap-around of
the counter, which is a tricky corner case.
Suggested-by: Eric Biggers
Signed-off-by: Ondrej Mosnacek
---
crypto/testmgr.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/crypto/testmgr.h b/crypto
On Tue, Sep 11, 2018 at 09:40:14AM -0400, Jerome Glisse wrote:
> Date: Tue, 11 Sep 2018 09:40:14 -0400
> From: Jerome Glisse
> To: Kenneth Lee
> CC: Kenneth Lee , Alex Williamson
> , Herbert Xu ,
> k...@vger.kernel.org, Jonathan Corbet , Greg Kroah-Hartman
> , Zaibo Xu ,
> linux-...@vger.kern
Fix two whitespace issues that occurred at line breakup.
Signed-off-by: Christoph Manszewski
---
drivers/crypto/s5p-sss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 0cf3f12d8f74..ce9bd13ea166 100644
--- a/driv
Add support for aes counter(ctr) block cipher mode of operation for
Exynos Hardware. In contrast to ecb and cbc modes, aes-ctr allows
encyption/decryption for request sizes not being a multiple of 16(bytes).
Hardware requires block sizes being a multiple of 16(bytes). In order to
achieve this, cop
Remove a race condition introduced by error path in functions:
s5p_aes_interrupt and s5p_aes_crypt_start. Setting the busy field of
struct s5p_aes_dev to false made it possible for s5p_tasklet_cb to
change the req field, before s5p_aes_complete was called.
Change the first parameter of s5p_aes_com
Hello,
This patch series adds aes-ctr support in s5p-sss.c driver. Additionally it
it provides a fix, and a minor code cleanup.
Patch 1 contains a simple fix, of a possible race condition.
Patches 2-3 are code cleanup patches.
Patch 4 adds support for aes-ctr block cipher mode of operation.
Rega
Modifications in s5p-sss.c:
- remove unnecessary 'goto' statements,
- change uint_8 and uint_32 to u8 and u32 types,
Signed-off-by: Christoph Manszewski
---
drivers/crypto/s5p-sss.c | 54 +++-
1 file changed, 17 insertions(+), 37 deletions(-)
diff -
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
descr
39 matches
Mail list logo
