alg: cipher: Test 1 failed on encryption for aes-asm

On my new thinkpad with a Intel Core2 Duo T9600 I reproducibly get this message during boot: [0.657034] alg: cipher: Test 1 failed on encryption for aes-asm [0.657111] : 00 01 02 03 04 05 06 07 08 08 08 08 08 08 08 08 I'd assume it's not a hardware but, so my the assembly code

Re: alg: cipher: Test 1 failed on encryption for aes-asm

On Sat, Dec 20, 2008 at 07:55:10AM +1100, Herbert Xu wrote: You forgot to list the kernel version :) 2.6.28-rc9, aka Linus' git as of today. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: RFC: Crypto API User-interface

On Tue, Sep 07, 2010 at 04:42:13PM +0800, Herbert Xu wrote: Hi: This is what I am proposing for the Crypto API user-interface. Can you explain why we would ever want a userspace interface to it? doing crypto in kernel for userspace consumers sis simply insane. It's computational intensive

Re: RFC: Crypto API User-interface

On Tue, Sep 07, 2010 at 10:11:12PM +0800, Herbert Xu wrote: FWIW I don't care about user-space using kernel software crypto at all. It's the security people that do. And since when did we care about their crack pipe dreams? The purpose of the user-space API is to export the hardware crypto

Re: RFC: Crypto API User-interface

On Tue, Sep 07, 2010 at 10:34:25AM -0400, Miloslav Trmac wrote: - Don't use a FD for associated data that is limited to 16? bytes - Don't use file descriptors for input data at all, if it makes the interface so complex. Calling into the kernel for 16 bytes of crypto is a braindead idea to

Re: RFC: Crypto API User-interface

On Tue, Sep 07, 2010 at 10:52:03AM -0400, Miloslav Trmac wrote: Because in the real world people want both certification, features _and_ performance. If all they cared about is certification they could just as well buy a pencil. Okay Mr Smartass. Please put away your crackpipe and get down

Re: RFC: Crypto API User-interface

On Tue, Sep 07, 2010 at 04:57:04PM +0200, Nikos Mavrogiannopoulos wrote: Or that someone is not really aware of some cryptographic uses. Embedded systems have crypto accelerators in hardware available through kernel device drivers. In the systems I worked the accelerators via a crypto device

Re: [RFC 12/12] iscsi-target: Add Makefile/Kconfig and update TCM top level

On Wed, Mar 02, 2011 at 01:32:11PM -0800, Nicholas A. Bellinger wrote: The kernel code itself that is specific to using the SSE v4.2 instruction for CRC32C offload are using #ifdef CONFIG_X86 stubs in iscsi_target_login.c:iscsi_login_setup_crypto(), and !CONFIG_X86 will default to using the

Re: [PATCH 3/3] crc32c: Implement a self-test for CRC32c

On Thu, Sep 01, 2011 at 03:18:54PM -0700, Darrick J. Wong wrote: I suspect it would be pretty easy to adapt the Makefile to generate the relevant .c and .h files; in particular it could be useful to use the crypto framework for crc32 on the off chance anyone wants to provide hwaccel for that

Re: [PATCH] random: add blocking facility to urandom

On Wed, Sep 07, 2011 at 04:02:24PM -0400, Steve Grubb wrote: The only time this kicks in is when a system is under attack. If you have set this and the system is running as normal, you will never notice it even there. So your userspace will break exactly when you least need it and can't

Re: [PATCH] random: add blocking facility to urandom

On Wed, Sep 07, 2011 at 05:18:58PM -0400, Ted Ts'o wrote: If this is the basis for the patch, then we should definitely NACK it. It sounds like snake oil fear mongering. You're around long enough to know that Steve and his gang do nothing but selling snake oil. -- To unsubscribe from this list:

Re: [PATCH] random: add blocking facility to urandom

On Wed, Sep 07, 2011 at 11:27:12PM +0200, Stephan Mueller wrote: And exactly that is the concern from organizations like BSI. Their cryptographer's concern is that due to the volume of data that you can extract from /dev/urandom, you may find cycles or patterns that increase the probability to

Re: [PATCH] Crypto: change all occurances of kerneli to kernel Bug #60848

On Wed, Oct 02, 2013 at 11:56:23AM -0400, Kevin Mulvey wrote: replace all kerneli with kernel kerneli is correct in this case. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH, RFC] random: introduce getrandom(2) system call

On Thu, Jul 17, 2014 at 05:18:15AM -0400, Theodore Ts'o wrote: The getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD. What's the reason to not implement exactly the same system call OpenBSD does? Having

Re: [PATCH v3 net-next 0/3] Add support for async socket operations

On Thu, Mar 19, 2015 at 07:51:05PM +, Al Viro wrote: I think I can live with that. Christoph, do you have any objections to that series? Patch 1 looks fine to me which is probably what you care for. I didn't have time to look into the other two. -- To unsubscribe from this list: send the

[PATCH 1/6] scatterlist: allow limited chaining without ARCH_HAS_SG_CHAIN

chaining. This patch removes a few #ifdef ARCH_HAS_SG_CHAIN statements so that we can switch the crypto code to these common helpers. Signed-off-by: Christoph Hellwig h...@lst.de --- include/linux/scatterlist.h | 4 lib/scatterlist.c | 4 2 files changed, 8 deletions(-) diff --git

[PATCH 4/6] scatterlist: remove open coded sg_unmark_end instances

From: Dan Williams dan.j.willi...@intel.com Signed-off-by: Dan Williams dan.j.willi...@intel.com [hch: split from a larger patch by Dan] Signed-off-by: Christoph Hellwig h...@lst.de --- block/blk-merge.c| 2 +- drivers/mmc/card/queue.c | 4 ++-- 2 files changed, 3 insertions(+), 3

[PATCH 2/6] target/rd: always chain S/G list

The rd sg lists are never passed to hardware, so use S/G chaining unonditionally. Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/target/target_core_rd.c | 44 - 1 file changed, 44 deletions(-) diff --git a/drivers/target/target_core_rd.c b

[PATCH 5/6] crypto/omap-sham: remove an open coded access to -page_link

Signed-off-by: Dan Williams dan.j.willi...@intel.com [hch: split from a larger patch by Dan] Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/crypto/omap-sham.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c

scatterlist cleanups

This series contains various scatterlist cleanups. It makes the chained scatterlist helpers generally available, even if a architecture doesn't allow a DMA mapping for it, and changes two callers to make use of this as well as cleans up various opencoded access to scatterlist internals. A large

[PATCH 6/6] scatterlist: use sg_phys()

From: Dan Williams dan.j.willi...@intel.com Coccinelle cleanup to replace open coded sg to physical address translations. This is in preparation for introducing scatterlists that reference __pfn_t. // sg_phys.cocci: convert usage page_to_phys(sg_page(sg)) to sg_phys(sg) // usage: make

[PATCH 3/6] crypto: replace scatterwalk_sg_chain with sg_chain

From: Dan Williams dan.j.willi...@intel.com Signed-off-by: Dan Williams dan.j.willi...@intel.com [hch: split from a larger patch by Dan] Signed-off-by: Christoph Hellwig h...@lst.de --- crypto/algif_skcipher.c | 2 +- crypto/ccm.c | 8 crypto/gcm.c

Re: crypto/cavium MSI-X fixups

On Tue, Feb 21, 2017 at 09:36:04AM -0800, David Daney wrote: > With respect to pci_enable_msix(), what do you recommend as a replacement? pci_alloc_irq_vectors. In fact I have a tree ready for after -rc1 that removes pci_enable_msix() entirely. > For the crypto/cavium driver, you recommend

Re: crypto/cavium MSI-X fixups

Herbert, any comment? I'd really like to avoid introducing new pci_enable_msix users in this merge window.. On Wed, Feb 15, 2017 at 02:47:09PM +0530, George Cherian wrote: > Hi Christoph, > > > On 02/15/2017 12:48 PM, Christoph Hellwig wrote: >> Hi George, >> >&g

[PATCH 1/3] crypto: cavium: remove dead MSI-X related define

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/crypto/cavium/cpt/cpt_common.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/crypto/cavium/cpt/cpt_common.h b/drivers/crypto/cavium/cpt/cpt_common.h index ede612f306d3..225078d03773 100644 --- a/drivers/crypto/cavi

[PATCH 3/3] crypto: cavium/cptvf: switch to pci_alloc_irq_vectors

pci_enable_msix has been long deprecated, but this driver adds a new instance. Convert it to pci_alloc_irq_vectors and greatly simplify the code, and make sure the prope code properly unwinds. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/crypto/cavium/cpt/cptvf.h

crypto/cavium MSI-X fixups

Hi George, your commit "crypto: cavium - Add Support for Octeon-tx CPT Engine" add a new caller to pci_enable_msix. This API has long been deprecated so this series switches it to use pci_alloc_irq_vectors instead. Can you please test it and make sure it goes in before the end of the merge

[PATCH 2/3] crypto: cavium/cptpf: switch to pci_alloc_irq_vectors

pci_enable_msix has been long deprecated, but this driver adds a new instance. Convert it to pci_alloc_irq_vectors and greatly simplify the code. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/crypto/cavium/cpt/cptpf.h | 5 --- drivers/crypto/cavium/cpt/cptpf_main.

Re: [PATCH 1/2] fscrypto: don't use on-stack buffer for filename encryption

On Sat, Nov 05, 2016 at 07:13:49AM -0800, Kent Overstreet wrote: > Vmalloc memory does have struct pages - you just need to use vmalloc_to_page() > instead of virt_to_page. Look at drivers/md/bcache/util.c bch_bio_map() if you > want an example. That example seems to be clearly broken on

Re: [PATCH 00/28] Reenable maybe-uninitialized warnings

On Tue, Oct 18, 2016 at 12:03:28AM +0200, Arnd Bergmann wrote: > This is a set of patches that I hope to get into v4.9 in some form > in order to turn on the -Wmaybe-uninitialized warnings again. Hi Arnd, I jsut complained to Geert that I was introducing way to many bugs or pointless warnings

Re: sg_set_buf

On Thu, Oct 20, 2016 at 05:42:19PM -0400, J. Bruce Fields wrote: > Turns out there are several places in the kerberos code where it just > needs to encrypt one small checksum or sequence number, and it's been > doing that on the stack. > > For now I'll just sprinkle kmalloc()'s all over.

Re: [PATCH 10/10] virtio: enable endian checks for sparse builds

On Tue, Dec 06, 2016 at 05:41:05PM +0200, Michael S. Tsirkin wrote: > __CHECK_ENDIAN__ isn't on by default presumably because > it triggers too many sparse warnings for correct code. > But virtio is now clean of these warnings, and > we want to keep it this way - enable this for > sparse builds. >

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote: > This is a straight forward conversion in two places. Should kmap fail, > the code will return an INVALD_DATA error in the completion. It really should be using nvmet_copy_from_sgl to make things safer, as we don't want to rely on

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 11:06:16PM -0600, Logan Gunthorpe wrote: > Or maybe I'll just send a patch for that > separately seeing it doesn't depend on anything and is pretty simple. I > can do that next week. Yes, please just send that patch linux-nvme, we should be able to get it into 4.12.

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote: > Very straightforward conversion to the new function in all four spots. I think the right fix here is to switch dm-crypt to the ahash API that takes a scatterlist.

Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote: > Convert the kmap and kmap_atomic uses to the sg_map function. We now > store the flags for the kmap instead of a boolean to indicate > atomicitiy. We also propogate a possible kmap error down and create > a new

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

> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 0007b79..b95934b 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -37,6 +37,9 @@ > > #include > > +/* Prevent the highmem.h macro from aliasing ops->kunmap_atomic */ > +#undef

[PATCH 7/7] liquidio: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c

[PATCH 2/7] PCI: call pcie_flr from reset_intel_82599_sfp_virtfn

The 82599 quirk contained an outdated copy of the FLR code. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/pci/quirks.c | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 673683660b5c..b17753

[PATCH 1/7] PCI: export pcie_flr

Currently we opencode the FLR sequence in lots of place, export a core helper instead. We split out the probing for FLR support as all the non-core callers already know their hardware. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/pci/pci.c

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

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/infiniband/hw/hfi1/chip.c | 4 ++-- drivers/infiniband/hw/hfi1/hfi.h | 1 - drivers/infiniband/hw/hfi1/pcie.c | 30 -- 3 files changed, 2 insertions(+), 33 deletions(-) diff --git a/drivers/infinib

[PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/crypto/qat/qat_common/adf_aer.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/crypto/qat/qat_common/adf_aer.c b/drivers/crypto/qat/qat_common/adf_aer.c index 2839fccdd84b..d3e25c37dc33

[PATCH 3/7] PCI: call pcie_flr from reset_chelsio_generic_dev

Instead of copy & pasting and old version of the code. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/pci/quirks.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index b1775354cc69..b54c0d986

[PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index a7a430

export pcie_flr and remove copies of it in drivers

Hi all, this exports the PCI layer pcie_flr helper, and removes various opencoded copies of it.

Re: [PATCH 1/7] PCI: export pcie_flr

> s/pcie_has_flr/pcie_has_flr()/ Ok. > This performs an FLR (if supported) always, regardless of "probe". > I think it should look something like this instead: > > if (pcie_has_flr(dev)) { > if (!probe) > pcie_flr(dev); > rc = 0; > goto done; > } Indeed!

Re: export pcie_flr and remove copies of it in drivers

On Fri, Apr 14, 2017 at 09:41:08AM -0500, Bjorn Helgaas wrote: > Looks good to me (except the comment on probe). If you want to apply > the whole series via netdev or some non-PCI tree, here's my ack for > the drivers/pci parts, assuming the probe thing is resolved: > > Acked-by: Bjorn Helgaas

Re: export pcie_flr and remove copies of it in drivers

On Fri, Apr 14, 2017 at 09:51:48AM -0500, Bjorn Helgaas wrote: > > Otherwise, I'd be glad to take the series given acks for the non-PCI > > parts. Just let me know. > > I do already have a patch (c5e4f0192ad2 ("PCI: Avoid FLR for Intel > 82579 NICs")) on my pci/virtualization branch that touches

[PATCH 2/7] PCI: call pcie_flr from reset_intel_82599_sfp_virtfn

The 82599 quirk contained an outdated copy of the FLR code. Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Bjorn Helgaas <bhelg...@google.com> --- drivers/pci/quirks.c | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/pci/quirks

[PATCH 7/7] liquidio: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c

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

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/infiniband/hw/hfi1/chip.c | 4 ++-- drivers/infiniband/hw/hfi1/hfi.h | 1 - drivers/infiniband/hw/hfi1/pcie.c | 30 -- 3 files changed, 2 insertions(+), 33 deletions(-) diff --git a/drivers/infinib

[PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/crypto/qat/qat_common/adf_aer.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/crypto/qat/qat_common/adf_aer.c b/drivers/crypto/qat/qat_common/adf_aer.c index 2839fccdd84b..d3e25c37dc33

[PATCH 3/7] PCI: call pcie_flr from reset_chelsio_generic_dev

Instead of copy & pasting and old version of the code. Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Bjorn Helgaas <bhelg...@google.com> --- drivers/pci/quirks.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/pci/quirks

[PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index a7a430

export pcie_flr and remove copies of it in drivers V2

Hi all, this exports the PCI layer pcie_flr helper, and removes various opencoded copies of it. Changes since V1: - rebase on top of the pci/virtualization branch - fixed the probe case in __pci_dev_reset - added ACKs from Bjorn

[PATCH 1/7] PCI: export pcie_flr

as there is no point in reading the capability in this case. Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Bjorn Helgaas <bhelg...@google.com> --- drivers/pci/pci.c | 39 --- include/linux/pci.h | 1 + 2 files changed, 29 insertions(+), 11 deleti

Re: [PATCH v2 02/21] libiscsi: Add an internal error code

On Tue, Apr 25, 2017 at 12:20:49PM -0600, Logan Gunthorpe wrote: > This is a prep patch to add a new error code to libiscsi. We want to > rework some kmap calls to be able to fail. When we do, we'd like to > use this error code. The kmap case in iscsi_tcp_segment_map can already fail. Please add

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

On Tue, Apr 25, 2017 at 12:20:48PM -0600, Logan Gunthorpe wrote: > This patch introduces functions which kmap the pages inside an sgl. > These functions replace a common pattern of kmap(sg_page(sg)) that is > used in more than 50 places within the kernel. > > The motivation for this work is to

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

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

On Mon, Apr 24, 2017 at 02:16:31PM +, Byczkowski, Jakub wrote: > Tested-by: Jakub Byczkowski Are you (and Doug) ok with queueing this up in the PCI tree?

Re: [PATCH] crypto: qat - avoid an uninitialized variable warning

Thanks Arnd, added to the dma-mapping tree.

[PATCH] crypto: qat: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/crypto/qat/qat_common/adf_aer.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/crypto/qat/qat_common/adf_aer.c b/drivers/crypto/qat/qat_common/adf_aer.c index 2839fccdd84b..d3e25c37dc33

Re: [Part2 PATCH v4.1 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

On Wed, Oct 04, 2017 at 11:21:53AM +0200, Borislav Petkov wrote: > On Wed, Oct 04, 2017 at 12:26:11PM +0530, P J P wrote: > > Each return above needs to be on its own line. > > ... because? It's actually readable by humanѕ that way.

Re: DMA error when sg->offset value is greater than PAGE_SIZE in Intel IOMMU

On Wed, Sep 27, 2017 at 10:13:51AM -0700, Dan Williams wrote: > As far as I can see "Offset can be greater than PAGE_SIZE" is the only > safe assumption for core code. It seems completely bogus to me, but if it is the current assumption we'll have to document it. But this brings me back to that

Re: [PATCH] crypto: marvell/cesa - Fix DMA API misuse

On Wed, Jan 10, 2018 at 04:25:22PM +0100, Boris Brezillon wrote: > On Wed, 10 Jan 2018 15:15:43 + > Robin Murphy wrote: > > > phys_to_dma() is an internal helper for certain DMA API implementations, > > and is not appropriate for drivers to use. It appears that what the