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

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 > >

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 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 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, > >

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 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 2020/10/30 ??3:45, Si-Wei Liu wrote: > This reverts commit 7ed9e3d97c32d969caded2dfb6e67c1a2cc5a0b1. > > Signed-off-by: Si-Wei Liu <si-wei.liu at oracle.com> > --- > drivers/vhost/vdpa.c | 119 +++++++++++++++++++++------------------------------ > 1 file changed, 48 insertions(+), 71 deletions(-) I saw this has been reverted there

Pinned pages are not properly accounted particularly when mapping error occurs on IOTLB update. Clean up dangling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have

Pinned pages are not properly accounted particularly when mapping error occurs on IOTLB update. Clean up dangling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have

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 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

Hi! > 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 [1]. > Unfortunately, the same problem surfaces when a virtual machine gets >

Hi! > 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 [1]. > Unfortunately, the same problem surfaces when a virtual machine gets >

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 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

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