Re: Oops in authenc: 2.6.26.3

2008-08-21 Thread Henrique de Moraes Holschuh
Cc: [EMAIL PROTECTED] ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line unsubscribe

Re: Is kernel optimized with dead store removal?

2010-02-25 Thread Henrique de Moraes Holschuh
On Thu, 25 Feb 2010, Mikael Pettersson wrote: In the sha1_update() case I don't know whether the stack is recycled and leaked - it may be dependent on the calling function, but isn't it vulnerable? It's only vulnerable if the data leaks to a less trusted domain. If it is anything you

Re: [PATCH] crypto: twofish-avx - remove useless instruction

2012-07-05 Thread Henrique de Moraes Holschuh
On Thu, 05 Jul 2012, Johannes Goetzfried wrote: The register %rdx is written, but never read till the end of the encryption routine. Therefore let's delete the useless instruction. Is it useless, or is it there to harden against some side-channel attack? -- One disk to rule them all, One

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

2013-10-28 Thread Henrique de Moraes Holschuh
On Mon, 28 Oct 2013, Stephan Mueller wrote: If it is accepted that the CPU Jitter RNG delivers entropy, the latter update may now allow us to get rid of storing the seed file during shutdown and restoring it during the next boot sequence. That's a 4096-bit safety net (uncredited entropy)

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

2014-07-24 Thread Henrique de Moraes Holschuh
On Thu, 24 Jul 2014, Theodore Ts'o wrote: ERRORS EINVAL An invalid flag was passed to getrandom(2) EFAULT buf is outside the accessible address space. EAGAIN The requested entropy was not available, and getentropy(2) would

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

2014-07-24 Thread Henrique de Moraes Holschuh
On Thu, 24 Jul 2014, Theodore Ts'o wrote: On Thu, Jul 24, 2014 at 08:21:38AM -0700, Andy Lutomirski wrote: Should we add ESOMETHING to be able to deny access to GRND_RANDOM or some future extension ? This might actually be needed sooner rather than later. There are programs that

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

2014-07-25 Thread Henrique de Moraes Holschuh
On Thu, 24 Jul 2014, Theodore Ts'o wrote: On Thu, Jul 24, 2014 at 05:30:19PM -0300, Henrique de Moraes Holschuh wrote: I wouldn't add the error to the man page until we actually modify the kernel to add such a restriction. By then, it might be too late. It would be really sad to find

Re: [PATCH 2/2] ath9k: disable RNG by default

2016-08-09 Thread Henrique de Moraes Holschuh
On Tue, 09 Aug 2016, Stephan Mueller wrote: > RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools > then > broken (at least in those large distros)? Might I humbly suggest that the kernel start providing some metatada about the quality of the random source that userspace

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

2016-08-09 Thread Henrique de Moraes Holschuh
On Tue, 09 Aug 2016, Jason Cooper wrote: > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > sysfs interface for per device quality, rate, and enabled attributes. > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled} IMHO, this is mightly annoying to use from

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

2017-06-06 Thread Henrique de Moraes Holschuh
On Tue, 06 Jun 2017, Theodore Ts'o wrote: > It might be possible, for example, to store a cryptographic key in a > UEFI boot-services variable, where the key becomes inaccessible after > the boot-time services terminate. But you also need either a reliable > time-of-day clock, or a reliable

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

2017-06-07 Thread Henrique de Moraes Holschuh
On Wed, 07 Jun 2017, Stephan Müller wrote: > Am Mittwoch, 7. Juni 2017, 00:19:10 CEST schrieb Henrique de Moraes Holschuh: > > On that same idea, one could add an early_initramfs handler for entropy > > data. > > Any data that comes from outside during the boot proc