Re: [RFC 6/7] x86: Move kernel_fpu_using to asm/i387.h

spurious #TS faults due to broken design of the Padlock instructions. The AES and PCLMUL instructions actually use SSE registers and so will require different structure. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf

Re: [RFC 6/7] x86: Move kernel_fpu_using to asm/i387.h

Herbert Xu wrote: On Wed, Jun 17, 2009 at 10:06:44AM -0700, H. Peter Anvin wrote: Huang: if I recall correctly, these functions were originally designed to deal with the fact that VIA processors generate spurious #TS faults due to broken design of the Padlock instructions. The AES

Re: [RFC 6/7] x86: Move kernel_fpu_using to asm/i387.h

() fpu_using(); } Yes, looks good. I'll pull in the patch as soon as I get it. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body

Re: [PATCH -v4] crypto: Add PCLMULQDQ accelerated GHASH implementation

are *guaranteed* to want to do the same thing again. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More

Re: [PATCH 4/5] tsc: wire up entropy generation function

let's keep the code lean enough that it can be called from an interrupt service routine. Consider the case where the TSC is running in steps of 64 and you're using the low 6 bits. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf

Re: [PATCH 4/5] tsc: wire up entropy generation function

On 06/13/2011 04:10 PM, Matt Mackall wrote: Well the issue is that samples are going to be roughly aligned to some multiple of the bus frequency. If an interrupt occurs on bus cycle X, this code will be hit at roughly TSC cycle X*M+d. This is correct; at the very least I would multiply the

Re: [PATCH 0/5] Feed entropy pool via high-resolution clocksources

system for /dev/urandom users and pull straight from the RDRAND instruction. I don't actually know what the exact numbers look like, but the stall conditions being looked at are of the order of every core in the socket trying to execute RDRAND at the same time. -hpa -- H. Peter Anvin

Re: [PATCH 0/5] Feed entropy pool via high-resolution clocksources

to give are very, very strict. RDRAND do not fulfill those criteria, but we should be able to use it as part of its implementation. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line

Re: [RFC][PATCH 00/16] Crypto keys and module signing [ver #2]

On 11/29/2011 03:42 PM, David Howells wrote: I have provided a couple of subtypes: DSA and RSA. Both types have signature verification facilities available within the kernel, and both can be used for module signature verification with any encryption algorithm known by the PGP parser,

Re: [PATCH 1/2] crypto: camellia-x86_64 - module init/exit functions should be static

anywhere? I'm still seeing build problems in linux-next 20120321. Thanks for the reminder, I'll push these through today. Please push these to Linus ASAP, it is breaking the x86-64 allyesconfig build upstream right now. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I

Re: [PATCH 0/3 v2] Optimize CRC32C calculation using PCLMULQDQ in crc32c-intel module

for 1K buffer and by 3x for buffer 4k or more. The tcrypt module was enhanced for doing speed test on crc32c calculations. Herbert - you are handling this one, right? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf

Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.

On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote: udev isn't doing any module loading, 'modprobe' is just being called for any new module alias that shows up in the system, and all of the drivers that match it then get loaded. How is it a problem if a module is attempted to be loaded that

Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.

On 07/19/2013 04:26 PM, Greg Kroah-Hartman wrote: RAID has effectively the same issue, and we just solved it by compiling in all the accelerators into the top-level module. Then there's nothing to be done in udev or kmod, right? I don't know. -hpa -- To unsubscribe from this

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

On 11/10/2013 09:21 AM, Stephan Mueller wrote: Here you say it: we *assume*. And please bear in mind that we all know for a fact that the theory behind quantum physics is not complete, because it does not work together with the theory of relativity. That again is a hint that there is NO

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

Can the code be adjusted to compile for 32 bit x86 or is that pointless? Tim Chen tim.c.c...@linux.intel.com wrote: On Mon, 2013-12-30 at 15:52 +0200, Andy Shevchenko wrote: It seems commit d764593a crypto: aesni - AVX and AVX2 version of AESNI-GCM encode and decode breaks a build on x86_32

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

On 01/06/2014 09:57 AM, Tim Chen wrote: On Mon, 2014-01-06 at 09:45 -0800, H. Peter Anvin wrote: Can the code be adjusted to compile for 32 bit x86 or is that pointless? Code was optimized for wide registers. So it is only meant for x86_64. Aren't the wide registers the vector registers

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

On 01/06/2014 12:26 PM, Borislav Petkov wrote: On Mon, Jan 06, 2014 at 10:10:55AM -0800, Tim Chen wrote: Yes, the code is in the file named aesni_intel_avx.S. So it should be clear that the code is meant for x86_64. How do you deduce aesni_intel_avx.S is meant for x86_64 only from the name?

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

On 01/06/2014 03:39 PM, Tim Chen wrote: Will renaming the file to aesni_intel_avx-x86_64.S make things clearer now? Tim Yes. Acked-by: H. Peter Anvin h...@linux.intel.com Herbert, can you pick it up? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-crypto

Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources

On 03/03/2014 03:51 PM, Kees Cook wrote: When bringing a new RNG source online, it seems like it would make sense to use some of its bytes to make the system entropy pool more random, as done with all sorts of other devices that contain per-device or per-boot differences. Signed-off-by:

Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources

On 03/04/2014 02:39 PM, Matt Mackall wrote: [temporarily coming out of retirement to provide a clue] The pool mixing function is intentionally _reversible_. This is a crucial security property. That means, if I have an initial secret pool state X, and hostile attacker controlled data Y,

Re: [PATCH 2/2] SHA1 transform: x86_64 AVX2 optimization - glue build-v2

On 03/17/2014 09:53 AM, chandramouli narayanan wrote: On second thoughts, with sha1-sse3-(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o, I have build issues and sha1_transform_avx2 undefined in sha1-sss3.ko. I can rid #ifdef CONFIG_AS_AVX2 in patch1. The following works though: ifeq

Re: [PATCH v4 1/1] crypto: SHA1 transform x86_64 AVX2

Herbert, do you want to take this or should I? In the former case, please feel free to add my: Acked-by: H. Peter Anvin h...@zytor.com -hpa On 03/19/2014 02:21 PM, chandramouli narayanan wrote: From 8948c828aa929a3e2531ca88e3f05fbeb1ff53db Mon Sep 17 00:00:00 2001 From: Chandramouli

Re: [PATCH v6 1/1] crypto: SHA1 transform x86_64 AVX2

Again... Herbert, David... yours or mine? -hpa -- 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 http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/1] crypto: SHA1 transform x86_64 AVX2

On 03/20/2014 05:09 PM, Herbert Xu wrote: On Thu, Mar 20, 2014 at 03:23:27PM -0700, H. Peter Anvin wrote: Again... Herbert, David... yours or mine? Yes I will be taking this through cryptodev. Thanks! Acked-by: H. Peter Anvin h...@linux.intel.com -hpa -- To unsubscribe from

Re: [PATCH 0/3] crypto: x86/sha1 - regression and other fixes

On 03/24/2014 09:10 AM, Mathias Krause wrote: The recent addition of the AVX2 variant of the SHA1 hash function wrongly disabled the AVX variant by introducing a flaw in the feature test. Fixed in patch 1. The alignment calculations of the AVX2 assembler implementation are questionable,

Re: [PATCH 0/3] crypto: x86/sha1 - regression and other fixes

. Peter Anvin h...@linux.intel.com Thank you for doing these. -hpa -- 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 http://vger.kernel.org/majordomo-info.html

Re: [PATCH] x86/crypto: ghash: use C implementation for setkey()

operation is probably not worth it, so I'm fine with reimplementing it in integer logic. Acked-by: H. Peter Anvin h...@linux.intel.com -hpa -- 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

Re: [PATCH] crypto: sha{256,512}_ssse3 - remove asmlinkage from static functions

On 04/17/2014 08:28 AM, Marek Vasut wrote: On Wednesday, April 16, 2014 at 06:19:50 PM, Jianyu Zhan wrote: Commit 128ea04a9885(lto: Make asmlinkage __visible) restricts asmlinkage to externally_visible, this causes compilation warnings: arch/x86/crypto/sha256_ssse3_glue.c:56:1:

Re: [PATCH] crypto: sha{256,512}_ssse3 - remove asmlinkage from static functions

On 04/17/2014 09:58 PM, Herbert Xu wrote: It doesn't make sense, sorry. The right thing to drop here is not asmlinkage, it is static: this is an external declaration. It's a function pointer that's static, not the function that it's pointing to. {facepalm} Right, function *pointer*.

Re: arch_random_refill

On 05/11/2014 04:01 PM, Stephan Mueller wrote: Hi Peter, some time back when the RDRAND instruction was debated, a patch was offered for driver/char/random.c that in essence turned /dev/random into a frontend for RDRAND in case that instruction was available. The patch kind of

Re: arch_random_refill

On 05/11/2014 08:36 PM, Stephan Mueller wrote: Ohh, ok, thanks for fixing that. :-) Though what makes me wonder is the following: why are some RNGs forced to use the hw_random framework whereas some others are not? What is the driver for that? The current state of random.c vs.

Re: arch_random_refill

On 05/11/2014 08:36 PM, Stephan Mueller wrote: But in our current predicament, not everybody trusts a few potentially easily manipulated gates that have no other purpose than produce white noise which are developed by the biggest chip vendor in the US. Gates which have other purposes may

Re: [PATCH] random: limit the contribution of the hw rng to at most half

On 07/17/2014 03:03 AM, Theodore Ts'o wrote: For people who don't trust a hardware RNG which can not be audited, the changes to add support for RDSEED can be troubling since 97% or more of the entropy will be contributed from the in-CPU hardware RNG. We now have a in-kernel khwrngd, so for

Re: [PATCH -v5] random: introduce getrandom(2) system call

On 07/24/2014 01:54 PM, Andy Lutomirski wrote: Or that someone writes userspace code that gets -EPERM/-EACCESS on getrandom with GRND_RANDOM and falls back to something worse than getrandom w/o GRND_RANDOM. -ENXIO? -hpa -- To unsubscribe from this list: send the line unsubscribe

Re: General flags to turn things off (getrandom, pid lookup, etc)

On 07/25/2014 11:30 AM, Andy Lutomirski wrote: - 32-bit GDT code segments [huge attack surface] - 64-bit GDT code segments [probably pointless] I presume you mean s/GDT/LDT/. We already don't allow 64-bit LDT code segments. Also, it is unclear to me how 32-bit LDT segments have a huge

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On 06/20/16 08:49, Stephan Mueller wrote: > Am Montag, 20. Juni 2016, 11:01:47 schrieb Theodore Ts'o: > > Hi Theodore, > >> >> So simply doing chacha20 encryption in a tight loop in the kernel >> might not be a good proxy for what would actually happen in real life >> when someone calls

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On May 5, 2016 3:18:09 PM PDT, ty...@mit.edu wrote: >On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: linux/bitops.h

On May 6, 2016 1:07:13 PM PDT, Sasha Levin <sasha.le...@oracle.com> wrote: >On 05/04/2016 08:30 PM, H. Peter Anvin wrote: >> On 05/04/16 15:06, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >>>>> Beware that shifting by an amount

Re: linux/bitops.h

On May 6, 2016 1:07:13 PM PDT, Sasha Levin <sasha.le...@oracle.com> wrote: >On 05/04/2016 08:30 PM, H. Peter Anvin wrote: >> On 05/04/16 15:06, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >>>>> Beware that shifting by an amount

Re: linux/bitops.h

On May 4, 2016 6:20:32 PM PDT, Jeffrey Walton <noloa...@gmail.com> wrote: >On Wed, May 4, 2016 at 7:06 PM, Andi Kleen <a...@firstfloor.org> wrote: >> On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrot

Re: better patch for linux/bitops.h

On May 4, 2016 7:54:12 PM PDT, Jeffrey Walton <noloa...@gmail.com> wrote: >On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin <h...@zytor.com> wrote: >> On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton <noloa...@gmail.com> >wrote: >>>On Wed, May 4, 2016 at 5:5

Re: linux/bitops.h

On 05/04/16 15:06, John Denker wrote: On 05/04/2016 02:56 PM, H. Peter Anvin wrote: Beware that shifting by an amount >= the number of bits in the word remains Undefined Behavior. This construct has been supported as a rotate since at least gcc2. How then should we understand the st

Re: better patch for linux/bitops.h

On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >> On 05/04/2016 02:42 PM, I wrote: >> >>> I find it very odd that the other seven functions were not >>> upgraded. I suggest the attached fix-others.diff

Re: better patch for linux/bitops.h

On 05/04/16 21:03, Jeffrey Walton wrote: On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: ... But instead of arguing over what works and doesn't, let's just create the the test set and just try it on a wide range of compilers and architectures, hmmm? What are the

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > > So this is why I tend to take a much more pragmatic viewpoint on > things. Sure, it makes sense to pay attention to what the C standard > writers are trying to do to us; but if we need to suppress certain > optimizations to write sane kernel code

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On May 4, 2016 11:22:25 AM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 1:49 PM, wrote: >> On Wed, May 04, 2016 at 10:40:20AM -0400, Jeffrey Walton wrote: >>> > +static inline u32 rotl32(u32 v, u8 n) >>> > +{ >>> > + return (v << n) | (v >>

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

code, including some very counterintuitive >Bad Things. > >On Wed, May 04, 2016 at 11:29:57AM -0700, H. Peter Anvin wrote: >>> >>> If bitops.h doesn't do the right thing, we need to >>> fix bitops.h. > >Most of the ror and rol functions in linux/bitops.h >

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On 05/04/2016 12:07 PM, ty...@thunk.org wrote: > > If we are all agreed that what is in bitops.h is considered valid, > then we can start converting people over to using the version defined > in bitops.h, and if there is some compiler issue we need to work > around, at least we only need to put

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

On 06/29/16 07:42, Dan Carpenter wrote: > || and | behave basically the same here but || is intended. It causes a > static checker warning to mix up bitwise and logical operations. > > Signed-off-by: Dan Carpenter > > diff --git a/arch/x86/crypto/sha256-mb/sha256_mb.c

Re: [PATCH v6 0/5] /dev/random - a new approach

On 08/15/16 22:45, Stephan Mueller wrote: > Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin: > > Hi H, > >> On 08/11/16 05:24, Stephan Mueller wrote: >>> * prevent fast noise sources from dominating slow noise sources >>> >>> in

Re: [PATCH v6 0/5] /dev/random - a new approach

On 08/11/16 05:24, Stephan Mueller wrote: > * prevent fast noise sources from dominating slow noise sources > in case of /dev/random Can someone please explain if and why this is actually desirable, and if this assessment has been passed to someone who has actual experience with cryptography at

Re: [PATCH v6 0/5] /dev/random - a new approach

On 08/16/16 15:28, H. Peter Anvin wrote: > On 08/15/16 22:45, Stephan Mueller wrote: >> Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin: >> >> Hi H, >> >>> On 08/11/16 05:24, Stephan Mueller wrote: >>>> * prevent fast

Re: [PATCH] x86/crypto: fix %progbits -> @progbits

On 01/19/17 13:28, Denys Vlasenko wrote: > %progbits form is used on ARM (where @ is a comment char). > > x86 consistently uses @progbits everywhere else. However, it looks like %progbits works on all architectures (at least include/linux/init.h seems to imply so.) Perhaps a tree-wide

Re: [PATCH v6 0/5] /dev/random - a new approach

On 08/18/16 22:56, Herbert Xu wrote: > On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote: >> >> That really depends on the system. We can't assume that people are >> using systems with a 100Hz clock interrupt. More often than not >> people are using tickless kernels these days.

Re: Entropy sources (was: /dev/random - a new approach)

On 08/20/16 22:37, Jeffrey Walton wrote: >> >> The biggest problem there is that the timer interrupt adds *no* entropy >> unless there is a source of asynchronicity in the system. On PCs, >> traditionally the timer has been run from a completely different crystal >> (14.31818 MHz) than the CPU,

Re: Entropy sources

On 08/25/16 16:35, Sandy Harris wrote: > On Thu, Aug 25, 2016 at 5:30 PM, H. Peter Anvin <h...@zytor.com> wrote: > >> The network stack is a good source of entropy, *once it is online*. >> However, the most serious case is while the machine is still booting, >>

Re: [PATCH 2/7] Makefile, x86, LLVM: disable unsupported optimization flags

On 03/17/17 14:32, H. Peter Anvin wrote: > > NAK. Fix your compiler, or use a wrapper script or something. It is > absolutely *not* acceptable to disable this since future versions of > clang *should* support that. > > That being said, it might make sense to look for a key p

Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

On 04/13/17 16:14, Matthias Kaehlcke wrote: > El Mon, Apr 03, 2017 at 04:01:58PM -0700 Matthias Kaehlcke ha dit: > >> El Fri, Mar 17, 2017 at 04:50:19PM -0700 h...@zytor.com ha dit: >> >>> On March 16, 2017 5:15:16 PM PDT, Michael Davidson wrote: Suppress clang warnings

Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

lt;linux-a...@vger.kernel.org>,linux-spa...@vger.kernel.org,Kernel Hardening <kernel-harden...@lists.openwall.com> From: h...@zytor.com Message-ID: <0ef6faaa-a99c-4f0d-9e4a-ad25e9395...@zytor.com> On July 19, 2017 4:25:56 PM PDT, Thomas Garnier <thgar...@google.com> wrote: >On Wed

Re: [RFC 06/22] kvm: Adapt assembly for PIE support

>,linux-pm <linux...@vger.kernel.org>,linux-arch <linux-a...@vger.kernel.org>,Linux-Sparse <linux-spa...@vger.kernel.org>,Kernel Hardening <kernel-harden...@lists.openwall.com> From: h...@zytor.com Message-ID: <83ba7600-bc8d-4c91-812c-dd2a0bf44.

Re: [PATCH 5/7] x86, boot, LLVM: Use regparm=0 for memcpy and memset

On 03/17/17 05:08, Peter Zijlstra wrote: > On Thu, Mar 16, 2017 at 05:15:18PM -0700, Michael Davidson wrote: >> Use the standard regparm=0 calling convention for memcpy and >> memset when building with clang. >> >> This is a work around for a long standing clang bug >> (see