Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

On Fri, Oct 13, 2017 at 6:56 AM, Andrey Ryabinin wrote: > > This could be fixed by s/vmovdqa/vmovdqu change like bellow, but maybe the > right fix > would be to align the data properly? I suspect anything that has the SHA extensions should also do unaligned loads

Re: [PATCH] crypto: cavium/nitrox - Remove default m setting from Kconfig

Xu <herb...@gondor.apana.org.au> wrote: > Drivers should not enable themselves by default, unless they're > an integral part of the platform. > > Reported-by: Linus Torvalds <torva...@linux-foundation.org> > Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>

Re: Crypto Update for 4.13

On Wed, Jul 5, 2017 at 6:01 AM, Herbert Xu wrote: > > Drivers: > > - Add support for CNN55XX adapters in cavium. Grr. I noticed this too late to fix it in the merge. That stupid CNN55XX driver was added with a default of "m"? WTF? Hell no. We don't add random new

Re: [PATCH] Revert "hwrng: core - zeroize buffers with random data"

Stephan, Herbert? The zeroes in /dev/hwrng output are obviously complete crap, so there's something badly wrong somewhere. The locking, for example, is completely buggered. There's even a comment about it, but that comment makes the correct observation of "but y'know: randomness". But the

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 12:55 PM, Josh Poimboeuf wrote: > > - Who's going to run sparse all the time to catch unauthorized users of > __aligned__(16)? Well, considering that we apparently only have a small handful of existing users without anybody having ever run any tool

Re: x86-64: Maintain 16-byte stack alignment

On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf wrote: > > Just to clarify, I think you're asking if, for versions of gcc which > don't support -mpreferred-stack-boundary=3, objtool can analyze all C > functions to ensure their stacks are 16-byte aligned. > > It's certainly

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 7:30 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > If you really want more stack alignment, you have to generate that > alignment yourself by hand (and have a bigger buffer that you do that > alignment inside). Side note: gcc can (

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 7:11 PM, Herbert Xu wrote: > > Well the only other alternative I see is to ban compilers which > enforce 16-byte stack alignment, such as gcc 4.7.2. No, you don't have to ban the compiler - it's just a "generate overly stupid code that just

Re: x86-64: Maintain 16-byte stack alignment

On Tue, Jan 10, 2017 at 6:39 AM, Herbert Xu wrote: > > BTW this is with Debian gcc 4.7.2 which does not allow an 8-byte > stack alignment as attempted by the Makefile: I'm pretty sure we have random asm code that may not maintain a 16-byte stack alignment when it

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 7:55 AM, George Spelvin wrote: > > How much does kernel_fpu_begin()/kernel_fpu_end() cost? It's now better than it used to be, but it's absolutely disastrous still. We're talking easily many hundreds of cycles. Under some loads, thousands. And

Re: [kernel-hardening] Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On Thu, Dec 15, 2016 at 1:11 PM, Jason A. Donenfeld wrote: > > Indeed, I stand corrected. But in any case, the use of __aligned(8) in > the patchset ensures that things are fixed and that we don't have this > issue. I think you can/should just use the natural alignment for

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 3:34 PM, Jason A. Donenfeld wrote: > > Or does your reasonable dislike of "word" still allow for the use of > dword and qword, so that the current function names of: dword really is confusing to people. If you have a MIPS background, it means 64 bits.

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld wrote: > > So actually jhash_Nwords makes no sense, since it takes dwords > (32-bits) not words (16-bits). The siphash analog should be called > siphash24_Nqwords. No. The bug is talking about "words" in the first place.

Re: [PATCH v3] siphash: add cryptographically secure hashtable function

On Tue, Dec 13, 2016 at 12:39 AM, Eric Biggers wrote: > > Hmm, I don't think you can really do load_unaligned_zeropad() without first > checking for 'left != 0'. Right you are. If the allocation is at the end of a page, the 0-size case would be entirely outside the page and

Re: [PATCH v3] siphash: add cryptographically secure hashtable function

On Mon, Dec 12, 2016 at 3:04 PM, Jason A. Donenfeld wrote: > > Indeed this would be a great first candidate. There are lots of places > where MD5 (!!) is pulled in for this sort of thing, when SipHash could > be a faster and leaner replacement (and arguably more secure than >

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

On Sun, Dec 11, 2016 at 9:48 PM, Jason A. Donenfeld wrote: > I modified the test to hash data of size 0 through 7 repeatedly > 1 times, and benchmarked that a few times on a Skylake laptop. > The `load_unaligned_zeropad & bytemask_from_count` version was > consistently 7%

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

On Sun, Dec 11, 2016 at 7:48 PM, Jason A. Donenfeld wrote: > + switch (left) { > + case 7: b |= ((u64)data[6]) << 48; > + case 6: b |= ((u64)data[5]) << 40; > + case 5: b |= ((u64)data[4]) << 32; > + case 4: b |=

Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized

On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote: > > Please merge these directly if you are happy with the result. I will take this. I do see two warnings, but they both seem to be valid and recent, though, so I have no issues with the spurious cases. Warning #1:

Re: [GIT PULL] /dev/random driver changes for 4.8

On Wed, Jul 27, 2016 at 6:12 AM, Theodore Ts'o wrote: > > Are you planning on pulling the random tree this cycle? I'm not sure > if you wanted to let it soak for a few days in linux-next, or whether > you want to wait another full release cycle It's next in line in my queue, so

Re: [patch] crypto: sha256-mb - cleanup a || vs | typo

[ rare comment rant. I think I'll do this once, and then ignore the discussion ] On Fri, Jul 8, 2016 at 9:45 AM, Herbert Xu wrote: > > Nack. As I said the commenting style in the crypto API is the > same as the network stack. So unless we decide to change both >

Re: linux/bitops.h

On Wed, May 4, 2016 at 5:30 PM, H. Peter Anvin wrote: > > Yes. d7e35dfa is baloney IMNSHO. All it does is produce worse code, and the > description even says so. > > As I said, gcc has treated the former code as idiomatic since gcc 2, so that > support is beyond ancient. Well,

Re: Crypto Fixes for 4.3

On Tue, Oct 13, 2015 at 5:17 AM, Herbert Xu wrote: > > This push fixes the following issues: > > * Fix AVX detection to prevent use of non-existent AESNI. > * Some SPARC ciphers did not set their IV size which may lead > to memory corruption. Hmm. It looks like you

Re: Crypto Fixes for 4.3

On Tue, Oct 13, 2015 at 6:03 PM, Herbert Xu wrote: > > Oops, I should've waited for you to pull the previous one before > pushing this one out. You might try to start using signed tags for your pull requests. That lessens this kind of issue, because now only will you

Re: Crypto Fixes for 4.2

On Fri, Jun 26, 2015 at 11:56 PM, Herbert Xu herb...@gondor.apana.org.au wrote: So I think Tadeusz's patch is the simplest fix for 4.2. Could you please test it to see if it makes your warning go away? Seems to silence it here. I get the feeling that the patch is still wrong - why are not

Re: Crypto Fixes for 4.2

On Fri, Jun 26, 2015 at 3:22 AM, Herbert Xu herb...@gondor.apana.org.au wrote: * Kill testmgr warning for gcm-aes-aesni. Hmm. You killed one of the warnings, but the setkey one remains. alg: aead: setkey failed on test 1 for rfc4106-gcm-aesni: flags=0 Expected? Linus -- To

Re: [PATCH] crypto: aesni - fix failing setkey for rfc4106-gcm-aesni

On Thu, Jun 25, 2015 at 7:25 AM, Herbert Xu herb...@gondor.apana.org.au wrote: Linus, could you confirm that you have AESNI built into the kernel and not as a module? Yes, confirmed. Linus -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of

Re: Crypto Update for 4.2

On Mon, Jun 22, 2015 at 1:44 AM, Herbert Xu herb...@gondor.apana.org.au wrote: Here is the crypto update for 4.2: Hmm. I noticed a new annoyance: I get this at bootup: [ +0.001504] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) [ +0.002233] alg: aead: setkey failed on test 1

Re: Crypto Update for 4.2

On Mon, Jun 22, 2015 at 1:44 AM, Herbert Xu herb...@gondor.apana.org.au wrote: Here is the crypto update for 4.2: So this generates conflicts with your earlier changes (that I got through the networking tree - they are your patches, but they went through Steffen Klassert and then David Miller).

Re: Crypto Fixes for 4.1

On Thu, May 21, 2015 at 9:05 PM, Herbert Xu herb...@gondor.apana.org.au wrote: Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git or master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git Mind fixing your script to not have that old

Re: Crypto Update for 4.1

Oh, and I forgot to add Stephan to the email recipients list.. Sorry for the duplicate email, Linus On Wed, Apr 15, 2015 at 7:37 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Apr 15, 2015 at 6:58 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, Apr

Re: Crypto Update for 4.1

On Tue, Apr 14, 2015 at 8:39 PM, Herbert Xu herb...@gondor.apana.org.au wrote: Here is the crypto update for 4.1: Just a heads-up: this breaks iwlwifi for me after suspend. I'm bisecting right now. But because this laptop is what I expect to travel with tomorrow, I will ruthlessly revert

Re: Crypto Update for 4.1

On Wed, Apr 15, 2015 at 8:07 PM, Herbert Xu herb...@gondor.apana.org.au wrote: Thanks! It actually appears to be a very simple bug that I somehow missed during reviewing. Ok, this patch seems to fix it for me, so I undid my revert that I hadn't pushed out yet, and pushed out this instead.

Re: Crypto Fixes for 4.0

On Tue, Mar 17, 2015 at 10:25 PM, Herbert Xu herb...@gondor.apana.org.au wrote: Hi Linus: On Mon, Mar 09, 2015 at 04:19:50PM +1100, Herbert Xu wrote: This push fixes a bug in the ARM XTS implementation that can cause failures to in decrypting encrypted disks. For some reason this didn't

Re: [PATCH v3 11/12] security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c

On Mon, Sep 15, 2014 at 12:30 AM, beh...@converseincode.com wrote: From: Behan Webster beh...@converseincode.com Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the

Re: Crypto Update for 3.16

On Wed, Jun 4, 2014 at 11:23 PM, Herbert Xu herb...@gondor.apana.org.au wrote: Here is the crypto update for 3.16: There's something odd going on with bfin_crc.h. You moved it in commit 52e6e543f2d8 (crypto: bfin_crc - access crc registers by readl and writel functions). It got *deleted* by

Re: Crypto Fixes for 3.12

On Fri, Sep 13, 2013 at 4:30 AM, Herbert Xu herb...@gondor.apana.org.au wrote: Herbert Xu (2): crypto: api - Fix race condition in larval lookup crypto: crct10dif - Add fallback for broken initrds crypto/Makefile |2 +- crypto/api.c

Re: Kernel 3.7.0-rc1 crash after TrueCrypt mount device on a computer with Intel i5

Krzysztof, please try to cc the appropriate people/list. I've added linux-crypto and the people who touched aesni-intel since 3.6, and am re-quoting the whole email (except for the continuation oopses that won't be relevant) It seems to crash on the very first instruction of _aesni_enc1, which

Re: Linux 3.6-rc5

On Sun, Sep 9, 2012 at 5:54 AM, Jussi Kivilinna jussi.kivili...@mbnet.fi wrote: Does reverting e46e9a46386bca8e80a6467b5c643dc494861896 help? That commit added crypto selftest for authenc(hmac(sha1),cbc(aes)) in 3.6, and probably made this bug visible (but not directly causing it). So Romain

Re: [PATCH 5/6] workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()

Seeing code like this + return (*nr_running)[0]; just makes me go WTF? Why are you taking the address of something you just dereferenced (the [0] part). And you actually do that *twice*, except the inner one is more complicated. When you assign nr_runing, you take the address of it, so

Re: [PATCH 5/6] workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()

On Fri, Jul 13, 2012 at 9:44 PM, Tejun Heo t...@kernel.org wrote: nr_running is atomic_t (*nr_running)[2]. Ignoring the pointer to array part, it's just returning the address of N'th element of the array. ARRAY + N == ARRAY[N]. None of this matters one whit. You did (x)[0]. That's insane.

Re: Crypto Update for 3.5

On Tue, May 22, 2012 at 6:35 PM, Herbert Xu herb...@gondor.apana.org.au wrote: Here is the crypto update for 3.5: I pulled this, but quite frankly, some of it looks like utter garbage. There's a declaration for dbx500_add_platform_device_noirq() that does not exist and is not used anywhere.

Re: Crypto Fixes for 3.3

On Wed, Jan 25, 2012 at 6:43 PM, Herbert Xu herb...@gondor.apana.org.au wrote: This push fixes a race condition in sha512 that affects users who use it in process context and softirq context concurrently, in particular, this affects IPsec.  The result of the race is the production of

Re: Crypto Fixes for 3.3

On Wed, Jan 25, 2012 at 8:07 PM, Herbert Xu herb...@gondor.apana.org.au wrote: Oops, I had incorrectly applied the first patch in the thread. I've fixed it in the tree now. Oh well, I already pulled your tree. I just wanted to voice a few comments on it. We also avoid the problem with

Re: [PATCH 2/3] sha512: reduce stack usage to safe number

On Sat, Jan 14, 2012 at 10:40 AM, Alexey Dobriyan adobri...@gmail.com wrote: Line by line explanation: * BLEND_OP  array is circular now, all indexes have to be modulo 16.  Round number is positive, so remainder operation should be  without surprises. Don't use % except on unsigned values.

Re: [PATCH 2/3] sha512: reduce stack usage to safe number

On Sat, Jan 14, 2012 at 12:41 PM, Alexey Dobriyan adobri...@gmail.com wrote: For the record, it generates andl $15 here. Ok. That means that gcc was able to prove that it never had any signed values (which is certainly reasonable when you do things like for (i=0; iX;i++)). But it's better to

Re: [PATCH 1/3] sha512: make it work, undo percpu message schedule

On Sat, Jan 14, 2012 at 1:46 PM, Eric Dumazet eric.duma...@gmail.com wrote: This is too risky, and we provided an alternate patch, not just for fun. Did you see the second patch? The one that got rid of the *stupid* 80-entry array? I don't know why so many sha implementations do that idiotic

Re: Crypto Update for 3.2

On Mon, Oct 31, 2011 at 9:42 AM, Randy Dunlap rdun...@xenotime.net wrote: Actually adds select NET, a reverse dependency.  :( Linus was quite vocal about not allowing MD to select BLOCK. See https://lkml.org/lkml/2011/8/10/527 and https://lkml.org/lkml/2011/8/10/533 To me this is very

Re: [PATCH] treewide: Update sha_transform

On Tue, Aug 9, 2011 at 1:58 AM, Joe Perches j...@perches.com wrote: Eliminate possible sha_transform unaligned accesses to data by copying data to an aligned __u32 array if necessary. This is wrong. Not only does it double the stack space, when I tried it for git it just made things slower. So

Re: [PATCH] lib/sha1: remove memsets and allocate workspace on the stack

On Mon, Aug 8, 2011 at 4:07 PM, Mandeep Singh Baines m...@chromium.org wrote: There is no loss of security due to removing the memset. It would be a bug for the stack to leak to userspace. However, a defence-in-depth argument could be made for keeping the clearing of the workspace. So I'm

Re: [PATCH] lib/sha1: use the git implementation of SHA-1

, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, Aug 7, 2011 at 10:36 AM, Joachim  Eastwood manab...@gmail.com wrote: These printk's come from drivers/char/random.c So it doesn't seem like it hangs in any of the sha_* funtions. The only other change is to SHA_WORKSPACE_WORDS - I

Re: [PATCH] lib/sha1: use the git implementation of SHA-1

On Sun, Aug 7, 2011 at 12:47 PM, Andreas Schwab sch...@linux-m68k.org wrote: ARM has its own implementation of sha_transform in arch/arm/lib/sha1.S, which assumes SHA_WORKSPACE_WORDS is 80. Well, that certainly explains it. I wonder if that thing is worth it. It seems to be based on the bad

Re: [PATCH] treewide: Remove direct uses of SHA_WORKSPACE_WORDS

On Sun, Aug 7, 2011 at 2:29 PM, Joe Perches j...@perches.com wrote: While not connected to ARM's implementation of sha_transform, maybe this might make code a bit clearer. Remove need to know the size and type of SHA_WORKSPACE_WORDS. Introduce and use opaque struct sha_workspace instead. The

Re: Crypto Update for 2.6.38

On Wed, Jan 5, 2011 at 4:01 PM, Herbert Xu herb...@gondor.hengli.com.au wrote: * Crypto API interface for user-space (hash + skcipher) Is there really any point to this? And can we get more explanation of what the interface is, and who would use it? If you need crypto in user space, it's

Re: Crypto Update for 2.6.38

On Thu, Jan 6, 2011 at 1:16 PM, Herbert Xu herb...@gondor.hengli.com.au wrote: On Thu, Jan 06, 2011 at 10:05:46AM -0800, Linus Torvalds wrote: Is there really any point to this? And can we get more explanation of what the interface is, and who would use it? I think you've answered

Re: Crypto Update for 2.6.38

On Thu, Jan 6, 2011 at 1:39 PM, Herbert Xu herb...@gondor.hengli.com.au wrote: On Thu, Jan 06, 2011 at 01:23:19PM -0800, Linus Torvalds wrote: Explanations of interface. Code. Who uses it? What are the actual performance benefits on real code? You snipped out the bit in my reply where I

Re: Crypto Update for 2.6.38

On Thu, Jan 6, 2011 at 2:30 PM, Herbert Xu herb...@gondor.hengli.com.au wrote: The main use-case is bulk encryption/hashing in user-space.  For example, on Sparc Niagara2 you need to use SPU (Stream Processing Unit) in order to do crypto at 10Gb/s over the network. Umm. But doesn't that

Re: Crypto Update for 2.6.38

On Thu, Jan 6, 2011 at 2:53 PM, Herbert Xu herb...@gondor.hengli.com.au wrote: On Thu, Jan 06, 2011 at 02:43:35PM -0800, Linus Torvalds wrote: Can you do the bypass directly to the TCP stream with the interface you added? It isn't at all obvious how it would work. Yes it can.  The interface

Re: Crypto Fixes for 2.6.37

On Wed, Dec 15, 2010 at 3:50 AM, Herbert Xu herb...@gondor.hengli.com.au wrote: This push fixes a build problem under certain configurations due to a missing include. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git You have a bad repo. Git says:

Re: Initcall ordering problem (TTY vs modprobe vs MD5) and cryptomgr problem

On Fri, Aug 6, 2010 at 1:06 AM, Olivier Galibert galib...@pobox.com wrote: Maybe Linus would be happier if the self-tests were limited (by default) to the hardware accelerators?  Having a software backup and the risk of data loss indeed makes things different. No. I'd be happier if it was an

Re: Initcall ordering problem (TTY vs modprobe vs MD5) and cryptomgr problem

On Thu, Aug 5, 2010 at 6:40 PM, Herbert Xu herb...@gondor.hengli.com.au wrote: -config CRYPTO_MANAGER_TESTS -       bool Run algolithms' self-tests -       default y -       depends on CRYPTO_MANAGER2 +config CRYPTO_MANAGER_DISABLE_TESTS +       bool Disable run-time self tests +      

Re: Initcall ordering problem (TTY vs modprobe vs MD5) and cryptomgr problem

On Thu, Aug 5, 2010 at 7:23 PM, David Howells dhowe...@redhat.com wrote: I wonder if tty_init() should be moved up, perhaps to immediately after chrdev_init(). I do think that sounds sane. The tty layer is kind of special. I wouldn't call it _after_ chrdev_init(), though, I'd call it _from_

Re: Initcall ordering problem (TTY vs modprobe vs MD5) and cryptomgr problem

On Thu, Aug 5, 2010 at 7:35 PM, Herbert Xu herb...@gondor.hengli.com.au wrote: Because it can save data.  Each cryptographic algorithm (such as AES) may have multiple impelmentations, some of which are hardware- based. Umm. The _developer_ had better test the thing. That is absolutely _zero_

Re: Crypto Fixes for 2.6.35

On Thu, 3 Jun 2010, Herbert Xu wrote: Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git Already up-to-date. Forgot to push? (I also checked master, so it's not that mirroring is slow) Linus -- To unsubscribe from this list: send the

Re: Crypto Update for 2.6.28

On Thu, 25 Dec 2008, Herbert Xu wrote: A regression has been reported where the new algorithm testing infrastructure may cause the optimised versions of AES to fail when it's built into the kernel (as opposed to as a module). Can't we just get rid of that stupid testing infrastructure, or

Re: Crypto Update for 2.6.28

On Fri, 10 Oct 2008, Herbert Xu wrote: Here is the crypto update for 2.6.28: Umm. Here was empty. Mind adding where it actually is, again? Yeah, yeah, I can look at my old merges (you didn't think I _remember_ things, did you?), and I can see that it's going to be

Re: [PATCH 0/6] MODSIGN: Kernel module signing

On Wed, 14 Feb 2007, David Howells wrote: (1) A cut-down MPI library derived from GPG with error handling added. Do we really need to add this? Wouldn't it be much nicer to just teach people to use one of the existing signature things that we need for _other_ cases anyway, and already have

Re: Creating diff from 2.6.16 from cryptodev-2.6 git tree

On Fri, 30 Jun 2006, Michal Ludvig wrote: Linus Torvalds wrote: git log -p --full-diff v2.6.16.. crypto/ Can I somehow get the result in a reverse order, i.e. oldest commits first? Not that way, no. git log generates the data on-the-fly, so a simple git log will always give most

Re: Creating diff from 2.6.16 from cryptodev-2.6 git tree

On Fri, 30 Jun 2006, Herbert Xu wrote: On Thu, Jun 29, 2006 at 07:25:01PM -0700, Linus Torvalds wrote: The easiest by far is if you only care about a certain sub-directory. Then, assuming the branch crypto is the top-most commit of the cryptodev repo, just do git diff