Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Hi! On Tue 2017-07-18 21:51:33, Theodore Ts'o wrote: > On Tue, Jul 18, 2017 at 09:00:10PM -0400, Sandy Harris wrote: > > The only really good solution I know of is to find a way to provide a > > chunk of randomness early in the boot process. John Denker has a good > > discussion of doing this by

Re: [PATCH 0/3] Introduce AMD Secure Processor device

On Thu 2017-06-22 06:42:01, Brijesh Singh wrote: > CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, > which is not dedicated solely to crypto. The AMD Secure Processor includes > CCP and PSP (Platform Secure Processor) devices. > > This patch series adds a framework that

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

Hi! > > From my point of view, it would make sense to factor time from RTC and > > mac addresses into the initial hash. Situation in the paper was so bad > > some devices had _completely identical_ keys. We should be able to do > > better than that. > > We fixed that **years** ago. In fact, the

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

Hi! > As far as whether or not you can gather enough entropy at boot time, > what we're really talking about how how much entropy we want to assume > can be gathered from interrupt timings, since what you do in your code > is not all that different from what the current random driver is > doing.

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

On Fri 2016-07-08 10:19:26, Linus Torvalds wrote: > [ 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 > >

Re: [PATCH 7/7] random: add backtracking protection to the CRNG

On Mon 2016-06-13 11:48:39, Theodore Ts'o wrote: > Signed-off-by: Theodore Ts'o > --- > drivers/char/random.c | 54 > ++- > 1 file changed, 49 insertions(+), 5 deletions(-) > > diff --git a/drivers/char/random.c

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

Hi! > Yes, I understand the argument that the networking stack is now > requiring the crypto layer --- but not all IOT devices may necessarily > require the IP stack (they might be using some alternate wireless > communications stack) and I'd much rather not make things worse. > > > The final

Re: [PATCH v5 0/7] /dev/random - a new approach

Hi! > > On Sun 2016-06-19 17:58:41, Stephan Mueller wrote: > > > Hi Herbert, Ted, > > > > > > The following patch set provides a different approach to /dev/random which > > > I call Linux Random Number Generator (LRNG) to collect entropy within the > > > Linux kernel. The main improvements

Re: [PATCH v5 0/7] /dev/random - a new approach

On Sun 2016-06-19 17:58:41, Stephan Mueller wrote: > Hi Herbert, Ted, > > The following patch set provides a different approach to /dev/random which > I call Linux Random Number Generator (LRNG) to collect entropy within the > Linux > kernel. The main improvements compared to the legacy

Re: random(4) changes

Hi! > > > > When dropping the add_disk_randomness function in the legacy > > > > /dev/random, I > > > > would assume that without changes to add_input_randomness and > > > > add_interrupt_randomness, we become even more entropy-starved. > > > > > > Sure, but your system isn't doing anything

Re: random(4) changes

Hi1 > > When dropping the add_disk_randomness function in the legacy /dev/random, I > > would assume that without changes to add_input_randomness and > > add_interrupt_randomness, we become even more entropy-starved. > > Sure, but your system isn't doing anything magical here. The main >

Re: [RFC][PATCH 0/6] /dev/random - a new approach

Hi! > > So you are relying on high-resolution timestamps. Ok. then you do kind > > of the check on the timestamps... ok, why not. But then you mix in the > > data regardless, saying that "they are not dependent" and thus can't > > hurt. > > > > But you already know they _are_ dependent, that's

Re: [RFC][PATCH 0/6] /dev/random - a new approach

Hi! > Please find in [1] the full design discussion covering qualitative assessments > of the entropy collection and entropy flow. Furthermore, a full > testing of the I don't get it. # The # idea is that only after obtaining LRNG_POOL_SIZE_BITS healthy bits, # the #entropy pool is completely

Re: [PATCH] modsign: Fix GPL/OpenSSL licence incompatibility

On Tue 2015-09-15 16:03:36, David Howells wrote: > From: David Woodhouse > > The GPL does not permit us to link against the OpenSSL library. Use > LGPL for sign-file and extract-file instead. Actually GPL does permit you to link to "system libraries", and it looks like

Re: [PATCH] random: add random_initialized command line param

On Tue 2015-06-23 23:47:33, Stephan Mueller wrote: Am Dienstag, 23. Juni 2015, 22:44:11 schrieb Pavel Machek: Hi Pavel, On Mon 2015-05-18 18:25:25, Stephan Mueller wrote: Make the threshold at which the output entropy pools are considered to be initialized configurable via a kernel

Re: [PATCH] random: add random_initialized command line param

On Mon 2015-05-18 18:25:25, Stephan Mueller wrote: Make the threshold at which the output entropy pools are considered to be initialized configurable via a kernel command line option. The current integer value of 128 bits is a good default value. However, some user groups may want to use

Re: [PATCH v2] crypto: omap-sham: Check for return value from pm_runtime_get_sync

On Sun 2015-03-08 11:01:01, Pali Rohár wrote: Function pm_runtime_get_sync could fail and we need to check return value to prevent kernel crash. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky

Re: [PATCH 04/10] crypto: omap-sham: Check for return value from pm_runtime_get_sync

On Thu 2015-02-26 14:49:54, Pali Rohár wrote: Function pm_runtime_get_sync could fail and we need to check return value to prevent kernel crash. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky

Re: [PATCH 03/10] crypto: omap-sham: Add support for omap3 devices

On Thu 2015-02-26 14:49:53, Pali Rohár wrote: omap3 support is same as omap2, just with different IO address (specified in DT) Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz @@ -1792,6 +1792,10 @@ static const struct of_device_id omap_sham_of_match

Re: [PATCH 02/10] ARM: OMAP3: Fix crypto support for HS devices

and omap-sham linux drivers. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line

Re: [PATCH 05/10] ARM: dts: omap3 hs: Remove timer12

On Thu 2015-02-26 14:49:55, Pali Rohár wrote: Device timer12 is automatically disabled on all HS devices via DTS property ti,timer-secure in file omap3.dtsi so it can be safely removed. We do not need to disable it on another place. Dunno. Theoretically, Linux is not the only user of dts... so

Re: [PATCH 07/10] ARM: dts: n9/n950: Enable omap crypto support

pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi @@ -8,7 +8,7 @@ * published by the Free Software Foundation. */ -#include omap36xx-hs.dtsi +#include omap36xx.dtsi / { cpus

Re: [PATCH 10/10] ARM: dts: Remove files omap34xx-hs.dtsi and omap36xx-hs.dtsi

On Thu 2015-02-26 14:50:00, Pali Rohár wrote: These files are not used by any DTS file anymore. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz --- arch/arm/boot/dts/omap34xx-hs.dtsi | 12 arch/arm/boot/dts/omap36xx-hs.dtsi | 12

Re: [PATCH 06/10] ARM: dts: omap3: Add missing dmas for crypto

On Thu 2015-02-26 14:49:56, Pali Rohár wrote: This patch adds missing dma DTS definitions for omap aes and sham drivers. Without it kernel drivers do not work. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com

Re: [PATCH 08/10] ARM: dts: n900: Enable omap sham and include directly omap34xx.dtsi

for omap sham. There is no kernel crash with both official bootloader and crypto enable bootloader. So we can safely enable sham code. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz +/* + * Default secure signed bootloader (Nokia X-Loader) does

Re: [PATCH 09/10] ARM: dts: omap3-tao3530: Include directly omap34xx.dtsi

On Thu 2015-02-26 14:49:59, Pali Rohár wrote: This patch just move content of file omap34xx-hs.dtsi into omap3-tao3530.dts. There is no code change, patch is just preparation for removing -hs file. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz

Re: Nokia N900: omap aes is broken

On Tue 2015-02-24 09:37:34, Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150224 09:42]: On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150218 16:03]: --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++

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

On Thu 2014-07-31 10:06:37, Bernd Petrovitsch wrote: On Don, 2014-07-31 at 00:18 +0200, Pavel Machek wrote: On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote: On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote: Pavel. I have bit 'ol enterprise daemon running with established file

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

Hi! The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks, where the attacker consumes all available file descriptors, forcing the use of the fallback code where /dev/[u]random is not available. Since the fallback code is often not

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

On Wed 2014-07-23 14:10:16, Hannes Frederic Sowa wrote: On Wed, Jul 23, 2014, at 13:52, George Spelvin wrote: I keep wishing for a more general solution. For example, some way to have a spare extra fd that could be accessed with a special O_NOFAIL flag. That would allow any number

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

On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote: On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote: Pavel. I have bit 'ol enterprise daemon running with established file descriptors serving thousands of connections which periodically require entropy. Now I run out of descriptors. I

Re: [PATCH 0/2] Add in-kernel /dev/random equivalent

On Mon 2014-05-12 00:36:01, Stephan Mueller wrote: Hi, as discussed in thread [1], an in-kernel equivalent to the blocking /dev/random device behavior is suggested. This in-kernel blocking access to the RNG can be used to seed deterministic random number generators with random numbers

Re: [PATCH] crypto: x86/sha1: fix coverity CID 1195603

Hi! Most likely yes but I wanted to keep sha1_ssse3_mod_init consistent with sha256_ssse3_mod_init/sha512_ssse3_mod_init functions. Reported-by: scan-ad...@coverity.com Signed-off-by: Milos Vyletel milos.vyle...@gmail.com --- arch/x86/crypto/sha1_ssse3_glue.c | 22

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

Hi! BTW: MFENCE is not guaranteed to flush the instruction pipeline; you need CPUID for that. I was not aware of that. Can I simply call the CPUID instruction to read it or do I have to do something special? Simply call CPUID (warning, it clobbers some registers.).

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

Hi! Of course, some of the state in the CPU may not be unknown to the attacker, if it is derived by external events that are not visible to the attacker, such as a network interrupt. But if that's the case, why not measure network interrupts directly? We're much less likely to overestimate

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

Hi! I plugged that idea into my current Jitter RNG processing and disabled the other jitter measurements to get a clear, isolated picture. The result is also a white noise! And it is even quite fast. After doing some more research on this approach, I have to admit that the output not

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

Hi! Another friend of mine mentioned that he assumes the rise and fall times of transistors varies very slightly and could be the main reason for the jitter. I do not think that this is really the case, because our gates that form the CPU instructions comprise of many transistors. The

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

Hi! sense of where the unpredictability might be coming from, and whether the unpredictability is coming from something which is fundamentally arising from something which is chaotic or quantum effect, or just because we don't have a good way of modelling the behavior of the L1/L2 cache (for

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

On Sat 2013-11-02 12:01:12, Pavel Machek wrote: Hi! sense of where the unpredictability might be coming from, and whether the unpredictability is coming from something which is fundamentally arising from something which is chaotic or quantum effect, or just because we don't have a good

Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm

Hi! On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. This series is big enough already... and who is going to test it? The hash config not

Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot

Hi! For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. Maybe you want to

Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm

On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. This series is big enough already... and who is going to test it? There's no need to make hash

Re: [RFC PATCH 00/18 v3] Signature verification of hibernate snapshot

Hi! - Bootloader store the public key to EFI boottime variable by itself - Bootloader put The private key to S4SignKey EFI variable for forward to kernel. Is the UEFI NVRAM really suited for such regular updates? Yes, Matthew raised this concern at before. I

Re: [PATCH 11/18] Hibernate: introduced RSA key-pair to verify signature of snapshot

@@ -1205,6 +1290,10 @@ struct boot_params *efi_main(void *handle, efi_system_table_t *_table, setup_efi_pci(boot_params); +#ifdef CONFIG_SNAPSHOT_VERIFICATION + setup_s4_keys(boot_params); +#endif + Move ifdef inside the function? OK, I will define a

Re: [PATCH 17/18] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm

On Tue 2013-08-27 18:22:17, joeyli wrote: 於 日，2013-08-25 於 18:43 +0200，Pavel Machek 提到： On Thu 2013-08-22 19:01:56, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. v2

Re: [PATCH 11/18] Hibernate: introduced RSA key-pair to verify signature of snapshot

On Tue 2013-08-27 14:01:42, Manfred Hollstein wrote: On Tue, 27 Aug 2013, 13:29:43 +0200, Pavel Machek wrote: @@ -1205,6 +1290,10 @@ struct boot_params *efi_main(void *handle, efi_system_table_t *_table, setup_efi_pci(boot_params); +#ifdef

Re: [PATCH 02/18] asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa

On Thu 2013-08-22 19:01:41, Lee, Chun-Yi wrote: Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the first step of signature generation operation (RSASSA-PKCS1-v1_5-SIGN). Is this your own code, or did you copy it from somewhere? + if (!T) + goto error_T; +

Re: [PATCH 03/18] asymmetric keys: separate the length checking of octet string from RSA_I2OSP

On Thu 2013-08-22 19:01:42, Lee, Chun-Yi wrote: Due to RSA_I2OSP is not only used by signature verification path but also used in signature generation path. So, separate the length checking of octet string because it's not for generate 0x00 0x01 leading string when used in signature

Re: [PATCH 06/18] asymmetric keys: support parsing PKCS #8 private key information

On Thu 2013-08-22 19:01:45, Lee, Chun-Yi wrote: Add ASN.1 files and parser to support parsing PKCS #8 noncompressed private key information. It's better than direct parsing pure private key because PKCS #8 has a privateKeyAlgorithm to indicate the algorithm of private key, e.g. RSA from PKCS

Re: [PATCH 07/18] asymmetric keys: explicitly add the leading zero byte to encoded message

On Thu 2013-08-22 19:01:46, Lee, Chun-Yi wrote: Per PKCS1 spec, the EMSA-PKCS1-v1_5 encoded message is leading by 0x00 0x01 in its first 2 bytes. The leading zero byte is suppressed by MPI so we pass a pointer to the _preceding_ byte to RSA_verify() in original code, but it has risk for the

Re: [PATCH 08/18] Secure boot: Add new capability

On Thu 2013-08-22 19:01:47, Lee, Chun-Yi wrote: From: Matthew Garrett m...@redhat.com Secure boot adds certain policy requirements, including that root must not be able to do anything that could cause the kernel to execute arbitrary code. The simplest way to handle this would seem to be to

Re: [PATCH 09/18] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

You may want to check subject. If it does something, it is not dummy. --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2784,6 +2784,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Note: increases power

Re: [PATCH 10/18] efi: Enable secure boot lockdown automatically when enabled in firmware

On Thu 2013-08-22 19:01:49, Lee, Chun-Yi wrote: From: Matthew Garrett m...@redhat.com The firmware has a set of flags that indicate whether secure boot is enabled and enforcing. Use them to indicate whether the kernel should lock itself down. We also indicate the machine is in secure boot

Re: [PATCH 11/18] Hibernate: introduced RSA key-pair to verify signature of snapshot

On Thu 2013-08-22 19:01:50, Lee, Chun-Yi wrote: Introduced a hibernate_key.c file to query the key pair from EFI variables and maintain key pair for check signature of S4 snapshot image. We loaded the private key when snapshot image stored success. This patch introduced 2 EFI variables for

Re: [PATCH 12/18] Hibernate: generate and verify signature of snapshot

On Thu 2013-08-22 19:01:51, Lee, Chun-Yi wrote: This patch add the code for generate/verify signature of snapshot, it put the signature to snapshot header. This approach can support both on userspace hibernate and in-kernel hibernate. v2: - Due to loaded S4 sign key before ExitBootServices,

Re: [PATCH 13/18] Hibernate: Avoid S4 sign key data included in snapshot image

On Thu 2013-08-22 19:01:52, Lee, Chun-Yi wrote: This patch add swsusp_page_is_sign_key() method to hibernate_key.c and check the page is S4 sign key data when collect saveable page in snapshot.c to avoid sign key data included in snapshot image. Reviewed-by: Jiri Kosina jkos...@suse.cz

Re: [PATCH 15/18] Hibernate: adapt to UEFI secure boot with signature check

On Thu 2013-08-22 19:01:54, Lee, Chun-Yi wrote: In current solution, the snapshot signature check used the RSA key-pair that are generated by bootloader(e.g. shim) and pass the key-pair to kernel through EFI variables. I choice to binding the snapshot signature check mechanism with UEFI secure

Re: [PATCH 17/18] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm

On Thu 2013-08-22 19:01:56, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. v2: Add define check of oCONFIG_SNAPSHOT_VERIFICATION in snapshot.c before declare pkey_hash().

Re: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in rfc4106_set_hash_subkey().

On Mon 2011-02-07 19:24:43, Jesper Juhl wrote: On Mon, 7 Feb 2011, tadeusz.st...@intel.com wrote: From: Date: Sun, 16 Jan 2011 16:41:11 + Subject: RE: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in rfc4106_set_hash_subkey(). Hi Jesper, Thanks, but I think there is

Re: [PATCH 00/19] RFC, v2: New /dev/crypto user-space interface

Hi! Motivations for the extensions: governments are asking for more security features in the operating systems they procure, which make user-space implementations impractical. A few examples: * Advanced crypto module for OSPP for Common Criteria requires OS services implementing several

Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.

On Fri 2008-08-08 21:35:30, Herbert Xu wrote: Ulrich Drepper [EMAIL PROTECTED] wrote: I think you want to use #define SCALE_F sizeof(unsigned long) Yeah in general that's what we should do. However, this driver is specific to Intel x86 CPUs. I thought we support intel x86 cpus in

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

Hi! Now, this is not a complete solution by any means: the core kernel is not protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least controls) one relatively simple attack vector. Could we fix the /dev/*mem holes, first? They are already used by malicious modules (aka