search for: jitterentropi

On Fri, Aug 10, 2018 at 08:33:00PM +0000, procmem wrote: >Hello. I'm a distro maintainer and was wondering about the efficacy of >entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the >authors of haveged [0] pointed out if the hardware cycles counter is >emulated and deterministic, and thus predictible. He therefore does not >recommend using HAVEGE on those

On Fri, Aug 10, 2018 at 08:33:00PM +0000, procmem wrote: > Hello. I'm a distro maintainer and was wondering about the efficacy of > entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the > authors of haveged [0] pointed out if the hardware cycles counter is > emulated and deterministic, and thus predictible. He therefore does not > recommend using HAVEGE on

Martin Kletzander: > On Fri, Aug 10, 2018 at 08:33:00PM +0000, procmem wrote: >> Hello. I'm a distro maintainer and was wondering about the efficacy of >> entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the >> authors of haveged [0] pointed out if the hardware cycles counter is >> emulated and deterministic, and thus predictible. He therefore does

Hello. I'm a distro maintainer and was wondering about the efficacy of entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the authors of haveged [0] pointed out if the hardware cycles counter is emulated and deterministic, and thus predictible. He therefore does not recommend using HAVEGE on those systems. Is this the case with KVM's counters? PS. I will be setting VM CPU

v5: - Break the btrfs patch out as a separate patch to be processed independently. - Update the commit log of patch 1 to make it less scary. - Add a kzfree backward compatibility macro in patch 2. v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary

As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or

As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or

As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or

v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree()

v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree()

This patchset makes a global rename of the kzfree() to kfree_sensitive() to highlight the fact buffer clearing is only needed if the data objects contain sensitive information like encrpytion key. The fact that kzfree() uses memset() to do the clearing isn't totally safe either as compiler may compile out the clearing in their optimizer. Instead, the new kfree_sensitive() uses