linux-kernel - Re: Back to the future.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070503151047.GB3866@ucw.cz>
Date:	Thu, 3 May 2007 15:10:47 +0000
From:	Pavel Machek <pavel@....cz>
To:	Kyle Moffett <mrmacman_g4@....com>
Cc:	nigel@...el.suspend2.net,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Pekka J Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.

Hi!

> >>It makes it harder to debug (wouldn't it be *nice* to 
> >>just ssh in,  and do
> >>	gdb -p <snapshotter>
> >
> >Make the machine being suspended a VM and you can 
> >already do that.
> 
> >>when something goes wrong?) but we also *depend* on 
> >>user space for  various things (the same way we depend 
> >>on kernel threads, and why  it has been such a total 
> >>disaster to try to freeze the kernel  threads too!). 
> >>For example, if you want to do graphical stuff,  just 
> >>using X would be quite nice,  wouldn't it?
> >
> >But in doing so you make the contents of the disk 
> >inconsistent with  the state you've just snapshotted, 
> >leading to filesystem  corruption. Even if you modify 
> >filesystems to do checkpointing  (which is what we're 
> >really talking about), you still also have the  problem 
> >that your snapshot has to be stored somewhere before 
> >you  write it to disk, so you also have to either [snip]
> 
> Actually, it's a lot simpler than that.  We can just 
> combine the  device-mapper snapshot with a VM+kernel 
> snapshot system call and be  almost done:
> 
>   sys_snapshot(dev_t snapblockdev, int __user 
>   *snapshotfd);
> 
> When sys_snapshot is run, the kernel does:
> 
> 1)  Sequentially freeze mounted filesystems using 
> blockdev freezing.   If it's an fs that doesn't support 
> freezing then either fail or force- remount-ro that fs 
> and downgrade all its filedescriptors to RO.   Doesn't 
> need extra locking since process which try to do IO 
> either  succeed before the freeze call returns for that 
> blockdev or sleep on  the unfreeze of that blockdev.  
> Filesystems are synchronized and made  clean.

How mature is freezing filesystems -- will it work on at least ext2/3
and vfat?

What happens if you try to boot and filesystems are frozen from
previous run?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/