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

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

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 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 17.11.2013 00:22, Emil Velikov wrote: > On 04/10/13 01:54, Christoph Rudorff wrote: >> Am Donnerstag, den 03.10.2013, 23:50 +0100 schrieb Emil Velikov: >>> I'm not entirely sure this is correct. One needs to save and disable >>> accleration before suspending the fb. Please try the following >>> >>> - if (state == 0) >>> + if (state == 1)

Current code disables fbcon acceleration before fbcon is suspended, leading to corrupted console after resume from s2disk. In a similar fashion we must make sure that fbcon acceleration is enabled before we revive the console. With this patch s2disk works correctly on my MacBookPro6,2 with GT216 [GeForce GT 330M] hibernate: kernel: nouveau [ DRM] suspending fbcon... kernel: nouveau [

On Tue, Nov 19, 2013 at 05:59:13PM +0100, Christoph Rudorff wrote: > Current code disables fbcon acceleration before fbcon is suspended, > leading to corrupted console after resume from s2disk. In a similar > fashion we must make sure that fbcon acceleration is enabled before we > revive the console. > > With this patch s2disk works correctly on my MacBookPro6,2 with GT216 >

From: Michal Hocko <mhocko at suse.com> b92b1b89a33c ("virtio: force vring descriptors to be allocated from lowmem") tried to exclude highmem pages for descriptors so it cleared __GFP_HIGHMEM from a given gfp mask. The patch also cleared __GFP_HIGH which doesn't make much sense for this fix because __GFP_HIGH only controls access to memory reserves and it doesn't have any

From: Michal Hocko <mhocko at suse.com> b92b1b89a33c ("virtio: force vring descriptors to be allocated from lowmem") tried to exclude highmem pages for descriptors so it cleared __GFP_HIGHMEM from a given gfp mask. The patch also cleared __GFP_HIGH which doesn't make much sense for this fix because __GFP_HIGH only controls access to memory reserves and it doesn't have any

Am Donnerstag, den 03.10.2013, 23:50 +0100 schrieb Emil Velikov: > I'm not entirely sure this is correct. One needs to save and disable > accleration before suspending the fb. Please try the following > > - if (state == 0) > + if (state == 1) > nouveau_fbcon_save_disable_accel(dev); > fb_set_suspend(drm->fbcon->helper.fbdev, state); > - if (state == 1) > +

This patch is a revert of 'commit bb01b64cfab7 ("mm/balloon_compaction.c: enqueue zero page to balloon device")' Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and shouldn't be given to the host ksmd to scan. Therefore, it is not necessary to zero ballooned pages, which is very time consuming when the page amount is large. The ongoing fast balloon tests