linux-kernel - Re: [linux-pm] [PATCH -mm 1/2] kexec jump -v12: kexec jump

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]

Date:	Fri, 11 Jul 2008 20:50:12 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, <nigel@...el.suspend2.net>,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, Pavel Machek <pavel@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	<linux-pm@...ts.linux-foundation.org>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [linux-pm] [PATCH -mm 1/2] kexec jump -v12: kexec jump

Alan Stern <stern@...land.harvard.edu> writes:

> On Fri, 11 Jul 2008, Eric W. Biederman wrote:
>
>> I just realized with a little care the block layer does have support for this,
>> or something very close.
>> 
>> You setup a software raid mirror with one disk device.    The physical
>> device can come in and out while the filesystems depend on the real device.
>
> Do you mean "the filesystems depend on the logical RAID device"?  

Oh yes. Thinko.

> What's to prevent userspace from accessing the physical device 
> directly?

Nothing.

> What this amounts to, in the end, is having a way to distinguish the
> set of I/O requests coming from the hibernation code (reading or
> writing the memory image) from the set of all other I/O requests.  The
> driver or the block layer has to be set up to allow the first set
> through while blocking the second set.  (And don't forget about the 
> complications caused by error-recovery I/O during the hibernation 
> activity!)

I guess this problem exists but it is not at all the problem I was
thinking of.

> Forcing the second set of requests to filter through an extra software 
> layer is a clumsy way of accomplishing this.  There ought to be a 
> better approach.

The point was something different.  The reasons we can not store the
state of the system with the hardware devices logically hot unplugged
(and thus reuse all of the find device hotplug methods) is because
things like the filesystem layer don't know how to cope with their
block devices going away an coming back.

That is the problem inserting an virtual software device in the middle
can solve.  If that works should there be a better way?  Certainly but
to prove it out starting with a block device wrapper is a trivial way to
go.

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