diff for duplicates of <1523978443.3310.3.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 308e437..d6c1d4b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -6,7 +6,7 @@ On Tue, 2018-04-17 at 07:07 -0700, Matthew Wilcox wrote: > > > > > On Sat, Apr 14, 2018 at 06:44:19PM -0400, Theodore Y. Ts'o > > > > > wrote: > > > > > > What needs to happen is freelist should get randomized much -> > > > > > later in the boot sequence.A A Doing it later will require +> > > > > > later in the boot sequence. Doing it later will require > > > > > > locking; I don't know enough about the slab/slub code to > > > > > > know whether the slab_mutex would be sufficient, or some > > > > > > other lock might need to be added. @@ -20,7 +20,7 @@ On Tue, 2018-04-17 at 07:07 -0700, Matthew Wilcox wrote: > > > apply to /dev/random for some entropy. > > > > Well, yes, but wouldn't qemu virtualize /dev/random anyway so the -> > guest A kernel can get it from the HWRNG provided by qemu? +> > guest kernel can get it from the HWRNG provided by qemu? > > The part of Ted's mail that I snipped explained that virtio-rng > relies on being able to kmalloc memory, so by definition it can't @@ -33,10 +33,10 @@ That sounds fixable ... > > > > You don't have to compromise the bootloader to influence this, you > > merely have to trick it into providing the random number you -> > wanted.A The bigger you make the attack surface (the more inputs) +> > wanted. The bigger you make the attack surface (the more inputs) > > the more likelihood of finding a trick that works. > > -> > > A A And also that we were free to mix in as many untrustworthy +> > > And also that we were free to mix in as many untrustworthy > > > bytes of alleged entropy into the random pool as we liked. > > > > No, entropy mixing ensures that all you do with bad entropy is @@ -44,9 +44,9 @@ That sounds fixable ... > > might at boot when you've no other entropy sources so you feed in > > 100% bad entropy), then the random sequences become predictable. > -> I don't understand that.A A If I estimate that I have 'k' bytes of +> I don't understand that. If I estimate that I have 'k' bytes of > entropy in my pool, and then I mix in 'n' entirely predictable bytes, -> I should still have k bytes of entropy in the pool.A A If I withdraw k +> I should still have k bytes of entropy in the pool. If I withdraw k > bytes from the pool, then yes the future output from the pool may be > entirely predictable, but I have to know what those k bytes were. diff --git a/a/content_digest b/N1/content_digest index 3341204..f533804 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -23,7 +23,7 @@ "> > > > > On Sat, Apr 14, 2018 at 06:44:19PM -0400, Theodore Y. Ts'o\n" "> > > > > wrote:\n" "> > > > > > What needs to happen is freelist should get randomized much\n" - "> > > > > > later in the boot sequence.A A Doing it later will require\n" + "> > > > > > later in the boot sequence.\302\240\302\240Doing it later will require\n" "> > > > > > locking; I don't know enough about the slab/slub code to\n" "> > > > > > know whether the slab_mutex would be sufficient, or some\n" "> > > > > > other lock might need to be added.\n" @@ -37,7 +37,7 @@ "> > > apply to /dev/random for some entropy.\n" "> > \n" "> > Well, yes, but wouldn't qemu virtualize /dev/random anyway so the\n" - "> > guest A kernel can get it from the HWRNG provided by qemu?\n" + "> > guest \302\240kernel can get it from the HWRNG provided by qemu?\n" "> \n" "> The part of Ted's mail that I snipped explained that virtio-rng\n" "> relies on being able to kmalloc memory, so by definition it can't\n" @@ -50,10 +50,10 @@ "> > \n" "> > You don't have to compromise the bootloader to influence this, you\n" "> > merely have to trick it into providing the random number you\n" - "> > wanted.A The bigger you make the attack surface (the more inputs)\n" + "> > wanted.\302\240 The bigger you make the attack surface (the more inputs)\n" "> > the more likelihood of finding a trick that works.\n" "> > \n" - "> > > A A And also that we were free to mix in as many untrustworthy\n" + "> > > \302\240\302\240And also that we were free to mix in as many untrustworthy\n" "> > > bytes of alleged entropy into the random pool as we liked.\n" "> > \n" "> > No, entropy mixing ensures that all you do with bad entropy is\n" @@ -61,9 +61,9 @@ "> > might at boot when you've no other entropy sources so you feed in\n" "> > 100% bad entropy), then the random sequences become predictable.\n" "> \n" - "> I don't understand that.A A If I estimate that I have 'k' bytes of\n" + "> I don't understand that.\302\240\302\240If I estimate that I have 'k' bytes of\n" "> entropy in my pool, and then I mix in 'n' entirely predictable bytes,\n" - "> I should still have k bytes of entropy in the pool.A A If I withdraw k\n" + "> I should still have k bytes of entropy in the pool.\302\240\302\240If I withdraw k\n" "> bytes from the pool, then yes the future output from the pool may be\n" "> entirely predictable, but I have to know what those k bytes were.\n" "\n" @@ -74,4 +74,4 @@ "\n" James -78896c594621c31d92f80e5bf4f61d1ec87cf6e6b1e080084673936b827e50f2 +9864142ce927f7044bbfbb6b76a2c97e391c6667c5483a8d71763be71c1e9573
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.