similar to: [RFC]: mm,power: introduce MADV_WIPEONSUSPEND

On Sat, Jul 4, 2020 at 12:44 AM Pavel Machek <pavel at ucw.cz> wrote: > > Cryptographic libraries carry pseudo random number generators to > > quickly provide randomness when needed. If such a random pool gets > > cloned, secrets may get revealed, as the same random number may get > > used multiple times. For fork, this was fixed using the WIPEONFORK > > madvise

On Tue 07-07-20 10:01:23, Alexander Graf wrote: > On 07.07.20 09:44, Michal Hocko wrote: > > On Mon 06-07-20 14:52:07, Jann Horn wrote: > > > On Mon, Jul 6, 2020 at 2:27 PM Alexander Graf <graf at amazon.com> wrote: > > > > Unless we create a vsyscall that returns both the PID as well as the > > > > epoch and thus handles fork *and* suspend. I need

On Mon, Jul 6, 2020 at 2:27 PM Alexander Graf <graf at amazon.com> wrote: > Unless we create a vsyscall that returns both the PID as well as the > epoch and thus handles fork *and* suspend. I need to think about this a > bit more :). You can't reliably detect forking by checking the PID if it is possible for multiple forks to be chained before the reuse check runs: - pid 1000

On Fri 2020-07-03 15:29:22, Jann Horn wrote: > On Fri, Jul 3, 2020 at 1:30 PM Michal Hocko <mhocko at kernel.org> wrote: > > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > > > This patch adds logic to the kernel power code to zero out contents of > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > to any suspend

On Fri, Jul 3, 2020 at 12:34 PM Catangiu, Adrian Costin <acatan at amazon.com> wrote: > Cryptographic libraries carry pseudo random number generators to > quickly provide randomness when needed. If such a random pool gets > cloned, secrets may get revealed, as the same random number may get > used multiple times. For fork, this was fixed using the WIPEONFORK > madvise flag

On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > This patch adds logic to the kernel power code to zero out contents of > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > to any suspend state equal or greater/deeper than Suspend-to-memory, > known as S3. How does the application learn that its memory got wiped? S2disk is an async operation and it can

On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > This patch adds logic to the kernel power code to zero out contents of > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > to any suspend state equal or greater/deeper than Suspend-to-memory, > known as S3. How does the application learn that its memory got wiped? S2disk is an async operation and it can

On Fri 03-07-20 15:29:22, Jann Horn wrote: > On Fri, Jul 3, 2020 at 1:30 PM Michal Hocko <mhocko at kernel.org> wrote: > > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > > > This patch adds logic to the kernel power code to zero out contents of > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > to any suspend

On Fri 03-07-20 15:29:22, Jann Horn wrote: > On Fri, Jul 3, 2020 at 1:30 PM Michal Hocko <mhocko at kernel.org> wrote: > > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > > > This patch adds logic to the kernel power code to zero out contents of > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > to any suspend

On Tue 07-07-20 10:07:26, Pavel Machek wrote: > Hi! > > > > > > This patch adds logic to the kernel power code to zero out contents of > > > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > > > to any suspend state equal or greater/deeper than Suspend-to-memory, > > > > > known as S3. > > >

On Tue 07-07-20 10:07:26, Pavel Machek wrote: > Hi! > > > > > > This patch adds logic to the kernel power code to zero out contents of > > > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > > > to any suspend state equal or greater/deeper than Suspend-to-memory, > > > > > known as S3. > > >

On Tue 2020-07-07 12:00:41, Colm MacCarthaigh wrote: > > > On 7 Jul 2020, at 9:37, Pavel Machek wrote: > > Please go through the thread and try to understand it. > > > > You'd need syscalls per get_randomness(), not per migration. > > I think one check per get_randomness() is sufficient, though putting it at > the end of the critical section rather than

Hi! > > > > This patch adds logic to the kernel power code to zero out contents of > > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > > to any suspend state equal or greater/deeper than Suspend-to-memory, > > > > known as S3. > > > > > > How does the application learn that its memory got wiped?

On Fri 03-07-20 18:45:06, Colm MacC?rthaigh wrote: > > > On 3 Jul 2020, at 4:30, Michal Hocko wrote: > > > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > > > This patch adds logic to the kernel power code to zero out contents > > > of > > > all MADV_WIPEONSUSPEND VMAs present in the system during its > > > transition > >

This fixes various problems that cropped up with the vdso patches. - Patch 1 fixes an information leak to userspace. - Patches 2 and 3 fix the kernel build on gold. - Patches 4 and 5 fix Xen (I hope). - Patch 6 (optional) adds a trace event to vsyscall emulation. It will make it easier to handle performance regression reports :) [1]

This fixes various problems that cropped up with the vdso patches. - Patch 1 fixes an information leak to userspace. - Patches 2 and 3 fix the kernel build on gold. - Patches 4 and 5 fix Xen (I hope). - Patch 6 (optional) adds a trace event to vsyscall emulation. It will make it easier to handle performance regression reports :) [1]

This fixes various problems that cropped up with the vdso patches. - Patch 1 fixes an information leak to userspace. - Patches 2 and 3 fix the kernel build on gold. - Patches 4 and 5 fix Xen (I hope). - Patch 6 (optional) adds a trace event to vsyscall emulation. It will make it easier to handle performance regression reports :) [1]

On Fri, Jul 3, 2020 at 1:30 PM Michal Hocko <mhocko at kernel.org> wrote: > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > > This patch adds logic to the kernel power code to zero out contents of > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > to any suspend state equal or greater/deeper than Suspend-to-memory, > > known

On Fri, Jul 3, 2020 at 1:30 PM Michal Hocko <mhocko at kernel.org> wrote: > > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > > This patch adds logic to the kernel power code to zero out contents of > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > to any suspend state equal or greater/deeper than Suspend-to-memory, > >

This fixes various problems that cropped up with the vdso patches. - Patch 1 fixes an information leak to userspace. - Patches 2 and 3 fix the kernel build on gold. - Patches 4 and 5 fix Xen (I hope). Konrad, could you could test these on Xen and run 'test_vsyscall test' [1]? I don't have a usable Xen setup. Also, I'd appreciate a review of patches 4 and 5 from some