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. > > > > > > > > How does the application learn that its memory got wiped? S2disk is an > > > > async operation and it can happen at any time during the task execution. > > > > So how does the application work to prevent from corrupted state - e.g. > > > > when suspended between two memory loads? > > > > > > You can do it seqlock-style, kind of - you reserve the first byte of > > > the page or so as a "is this page initialized" marker, and after every > > > read from the page, you do a compiler barrier and check whether that > > > byte has been cleared. > > > > This is certainly possible yet wery awkwar interface to use IMHO. > > MADV_EXTERNALY_VOLATILE would express the actual semantic much better. > > I might not still understand the expected usecase but if the target > > application has to be changed anyway then why not simply use a > > transparent and proper signaling mechanism like poll on a fd. That > > The goal is to have cryprographically-safe get_random_number() with 0 > syscalls. > > You'd need to do: > > if (!poll(did_i_migrate)) { > use_prng_seed(); > if (poll(did_i_migrate)) { > /* oops_they_migrated_me_in_middle_of_computation, > lets_redo_it() */ > goto retry: > } > } > > Which means two syscalls..Is this a real problem though? Do we have any actual numbers? E.g. how often does the migration happen so that 2 syscalls would be visible in actual workloads? -- Michal Hocko SUSE Labs
Hi!> > > > You can do it seqlock-style, kind of - you reserve the first byte of > > > > the page or so as a "is this page initialized" marker, and after every > > > > read from the page, you do a compiler barrier and check whether that > > > > byte has been cleared. > > > > > > This is certainly possible yet wery awkwar interface to use IMHO. > > > MADV_EXTERNALY_VOLATILE would express the actual semantic much better. > > > I might not still understand the expected usecase but if the target > > > application has to be changed anyway then why not simply use a > > > transparent and proper signaling mechanism like poll on a fd. That > > > > The goal is to have cryprographically-safe get_random_number() with 0 > > syscalls. > > > > You'd need to do: > > > > if (!poll(did_i_migrate)) { > > use_prng_seed(); > > if (poll(did_i_migrate)) { > > /* oops_they_migrated_me_in_middle_of_computation, > > lets_redo_it() */ > > goto retry: > > } > > } > > > > Which means two syscalls.. > > Is this a real problem though? Do we have any actual numbers? E.g. how > often does the migration happen so that 2 syscalls would be visible in > actual workloads?Please go through the thread and try to understand it. You'd need syscalls per get_randomness(), not per migration. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20200707/f55a5242/attachment.sig>
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 the beginning helps.Yeah, well, one syscall is still enough to make it useless. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20200712/18b0be31/attachment.sig>
On Sun 12-07-20 09:22:28, Pavel Machek wrote:> 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 the beginning helps. > > Yeah, well, one syscall is still enough to make it useless.I am sorry but I really do not follow. Why would you want to call a syscall on each get_randomness invocation? Why is it not enough to simply have a flag that tells that an external event has happened and reinitialize if the flag is set? Yes this wouldn't be really sync operation but does that matter? Is using a few random numbers from the old pool just because the notifier hasn't processed and flag the situation a major security concern? Btw. let me just clarify that I am not by any means pushing a solution like that. All I am saying is that MADV_WIPEONSUSPEND is inherently subtle interface that we likely want to avoid. -- Michal Hocko SUSE Labs