diff for duplicates of <1523966232.3250.15.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 87c49a6..c643daf 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,7 +3,7 @@ On Tue, 2018-04-17 at 04:47 -0700, Matthew Wilcox wrote: > > On Sat, 2018-04-14 at 17:41 -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. @@ -22,7 +22,7 @@ Well, yes, but wouldn't qemu virtualize /dev/random anyway so the guest > > For example, if you compile in a TPM driver, the kernel will > > pick up 32 random entropy bytes from the TPM to seed the pool, but > > I think it happens too late to help with this problem -> > currently.A A IMA also needs the TPM very early in the boot sequence, +> > currently. IMA also needs the TPM very early in the boot sequence, > > so I was wondering about using the initial EFI driver, which is > > present on boot, and then transitioning to the proper kernel TPM > > driver later, which would mean we could seed the pool earlier. @@ -40,7 +40,7 @@ merely have to trick it into providing the random number you 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 bytes of +> 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 degrade diff --git a/a/content_digest b/N1/content_digest index d5e8e24..21041d4 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -18,7 +18,7 @@ "> > On Sat, 2018-04-14 at 17:41 -0700, Matthew Wilcox wrote:\n" "> > > On Sat, Apr 14, 2018 at 06:44:19PM -0400, Theodore Y. Ts'o 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 know\n" "> > > > whether the slab_mutex would be sufficient, or some other lock\n" "> > > > might need to be added.\n" @@ -37,7 +37,7 @@ "> > For example, if you compile in a TPM driver, the kernel will\n" "> > pick up 32 random entropy bytes from the TPM to seed the pool, but\n" "> > I think it happens too late to help with this problem\n" - "> > currently.A A IMA also needs the TPM very early in the boot sequence,\n" + "> > currently.\302\240\302\240IMA also needs the TPM very early in the boot sequence,\n" "> > so I was wondering about using the initial EFI driver, which is\n" "> > present on boot, and then transitioning to the proper kernel TPM\n" "> > driver later, which would mean we could seed the pool earlier.\n" @@ -55,7 +55,7 @@ "The bigger you make the attack surface (the more inputs) the more\n" "likelihood of finding a trick that works.\n" "\n" - "> A A And also that we were free to mix in as many untrustworthy bytes of\n" + "> \302\240\302\240And also that we were free to mix in as many untrustworthy bytes of\n" "> alleged entropy into the random pool as we liked.\n" "\n" "No, entropy mixing ensures that all you do with bad entropy is degrade\n" @@ -65,4 +65,4 @@ "\n" James -f001aa379063a14e32b7eb9e2e1d20ab7b0c4d16df269a9a9b2ef2870c500e01 +ca39343b7dca2cf2c447394bd04b383a7a408a663b2b74f4165a34524877820f
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.