Re: [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

Eric Biggers wrote: > > > By the way: do we really need this in the kernel at all, given that it's > > > just doing some math on data which userspace has access to? > > > > It is the question about how we want the keys subsystem to operate. The DH > > shared secret shall

ecdh: generation and retention of ecc privkey in kernel/hardware

Hi, Herbert, I'm working with a crypto accelerator that is capable of generating and retaining ecc private keys in hardware and further use them for ecdh. The private keys can not be read from the device. This is good because the less software has access to secrets, the better. Generation and

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote: > > The main difficulty we > > have now is that neither of those functions are expected to fail and we > > need them to be able to in cases where the page doesn't map to system > > RAM. This patch series is trying to address it

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 27/04/17 12:53 AM, Christoph Hellwig wrote: > I think you'll need to follow the existing kmap semantics and never > fail the iomem version either. Otherwise you'll have a special case > that's almost never used that has a different error path. > > Again, wrong way. Suddenly making things

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 26/04/17 09:56 PM, Herbert Xu wrote: > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote: >> Very straightforward conversion to the new function in the caam driver >> and shash library. >> >> Signed-off-by: Logan Gunthorpe >> Cc: Herbert Xu

[PATCH] crypto: talitos: Extend max key length for SHA384/512-HMAC

The max keysize for both of these is 128, not 96. Before, with keysizes over 96, the memcpy in ahash_setkey() would overwrite memory beyond the key field. Signed-off-by: Martin Hicks --- drivers/crypto/talitos.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 27/04/17 09:27 AM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote: > How about first switching as many call sites as possible to use > sg_copy_X_buffer instead of kmap? Yeah, I could look at doing that first. One problem is we might get more Naks

Re: [PATCH 4/8] random: remove unused branch in hot code path

Hi Ted, (replying to an old thread) On Wed, Jan 18, 2017 at 5:35 AM, Theodore Ts'o wrote: > On Tue, Dec 27, 2016 at 11:40:23PM +0100, Stephan Müller wrote: >> The variable ip is defined to be a __u64 which is always 8 bytes on any >> architecture. Thus, the check for sizeof(ip) >

[PATCH] crypto: stm32 - fix building as a module

The names in the MODULE_DEVICE_TABLE and the actual array don't match: drivers/crypto/stm32/stm32_crc32.c:309:21: error: 'sti_dt_ids' undeclared here (not in a function); did you mean 'stm32_dt_ids'? This changes the reference that was evidently copied incorrectly from another driver. Fixes:

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote: > Ok, well for starters I think you are mistaken about kmap being able to > fail. I'm having a hard time finding many users of that function that > bother to check for an error when calling it. A quick audit of the arch code shows

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Tue, Apr 25, 2017 at 02:39:55PM -0500, Bjorn Helgaas wrote: > This still leaves these: > > [PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it > [PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating it > [PATCH 7/7] liquidio: use pcie_flr instead of duplicating it > > I

[PATCH v4 0/3] arm64: marvell: add cryptographic engine support for 7k/8k

Hi all, This series adds support for the Inside Secure SafeXcel EIP197 cryptographic engine which can be found on Marvell Armada 7k and 8k boards. A new cryptographic engine driver is added, as well as the relevant device tree definition for the Armada 7040 DB and 8040 DB boards. This driver

[PATCH v4 1/3] Documentation/bindings: Document the SafeXel cryptographic engine driver

The Inside Secure Safexcel cryptographic engine is found on some Marvell SoCs (7k/8k). Document the bindings used by its driver. Signed-off-by: Antoine Tenart --- .../bindings/crypto/inside-secure-safexcel.txt | 27 ++ 1 file changed,

[PATCH v4 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver

Add support for Inside Secure SafeXcel EIP197 cryptographic engine, which can be found on Marvell Armada 7k and 8k boards. This driver currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and hmac(sah1) algorithms. Two firmwares are needed for this engine to work. Their are mostly used

[PATCH v4 3/3] MAINTAINERS: add a maintainer for the Inside Secure crypto driver

A new cryptographic engine driver was added in drivers/crypto/inside-secure. Add myself as a maintainer for this driver. Signed-off-by: Antoine Tenart --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Thu, Apr 27, 2017 at 08:47:58AM +0200, Christoph Hellwig wrote: > On Tue, Apr 25, 2017 at 02:39:55PM -0500, Bjorn Helgaas wrote: > > This still leaves these: > > > > [PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it > > [PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating

Re: ecdh: generation and retention of ecc privkey in kernel/hardware

Hi Tudor, > I'm working with a crypto accelerator that is capable of generating and > retaining ecc private keys in hardware and further use them for ecdh. > The private keys can not be read from the device. This is good because > the less software has access to secrets, the better. > >

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 26/04/17 01:44 AM, Christoph Hellwig wrote: > I think we'll at least need a draft of those to make sense of these > patches. Otherwise they just look very clumsy. Ok, what follows is a draft patch attempting to show where I'm thinking of going with this. Obviously it will not compile because

Re: [PATCH 6/6] ima: Support appended signatures for appraisal

Am Mittwoch, 26. April 2017, 18:18:34 BRT schrieb Mehmet Kayaalp: > > On Apr 20, 2017, at 7:41 PM, Thiago Jung Bauermann > > wrote: > > > > This patch introduces the appended_imasig keyword to the IMA policy syntax > > to specify that a given hook should expect the

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > Well, that is in the current form, with more users it would make sense > to optimize for the single page case, eg by providing the existing > call, providing a faster

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 02:19:24PM -0600, Logan Gunthorpe wrote: > > > On 26/04/17 01:37 AM, Roger Pau Monné wrote: > > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote: > >> Straightforward conversion to the new helper, except due to the lack > >> of error path, we have to use

Re: [PATCH 6/6] ima: Support appended signatures for appraisal

> On Apr 27, 2017, at 5:41 PM, Thiago Jung Bauermann > wrote: > > Am Mittwoch, 26. April 2017, 18:18:34 BRT schrieb Mehmet Kayaalp: >>> On Apr 20, 2017, at 7:41 PM, Thiago Jung Bauermann >>> wrote: >>> >>> This patch introduces the

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 02:53 PM, Jason Gunthorpe wrote: > blkfront is one of the drivers I looked at, and it appears to only be > memcpying with the bvec_data pointer, so I wonder why it does not use > sg_copy_X_buffer instead.. Yes, sort of... But you'd potentially end up calling sg_copy_to_buffer

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > On 27/04/17 02:53 PM, Jason Gunthorpe wrote: > > blkfront is one of the drivers I looked at, and it appears to only be > > memcpying with the bvec_data pointer, so I wonder why it does not use > > sg_copy_X_buffer instead.. > >

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 05:03:45PM -0600, Logan Gunthorpe wrote: > > > On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > > Well, that is in the current form, with more users it would make sense > > to optimize for the single page

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 05:20 PM, Jason Gunthorpe wrote: > It seems the most robust: test for iomem, and jump to a slow path > copy, otherwise inline the kmap and memcpy > > Every place doing memcpy from sgl will need that pattern to be > correct. Ok, sounds like a good place to start to me. I'll see what

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 26/04/17 01:37 AM, Roger Pau Monné wrote: > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote: >> Straightforward conversion to the new helper, except due to the lack >> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in >> certain cases in the future. >> >>