linux-kernel - Re: [PATCH -mm] kexec jump -v9

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:	Wed, 12 Mar 2008 08:59:18 +1100
From:	Nigel Cunningham <ncunningham@...a.org.au>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	"Huang, Ying" <ying.huang@...el.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Pavel Machek <pavel@....cz>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	Kexec Mailing List <kexec@...ts.infradead.org>
Subject: Re: [PATCH -mm] kexec jump -v9

Hi all.

I hope kexec turns out to be a good, usable solution. Unfortunately,
however, I still have some areas where I'm not convinced that kexec is
going to work or work well:

1. Reliability.

It's being sold as a replacement for freezing processes, yet AFAICS it's
still going to require the freezer in order to be reliable. In the
normal case, there isn't much of an issue with freeing memory or
allocating swap, and so these steps can be expected to progress without
pain. Imagine, however, the situation where another process or processes
are trying to allocate large amounts of memory at the same time, or the
system is swapping heavily. Although such situations will not be common,
they are entirely conceivable, and any implementation ought to be able
to handle such a situation efficiently. If the freezer is removed, any
hibernation implementation - not just kexec - is going to have a much
harder job of being reliable in all circumstances. AFAICS, the only way
a kexec based solution is going to be able to get around this will be to
not have to allocate memory, but that will require permanent allocation
of memory for the kexec kernel and it's work area as well as the
permanent, exclusive allocation of storage for the kexec hibernation
implementation that's currently in place (making the LCA complaint about
not being able to hibernate to swap on NTFS on fuse equally relevant). 

While this might be feasible on machines with larger amounts of memory
(you might validly be able to argue that a user won't miss 10MB of RAM),
it does make hibernation less viable or unviable for systems with less
memory (embedded!). It also means that there are 10MB of RAM (or
whatever amount) that the user has paid good money for, but which are
probably only used for 30s at a time a couple of times a day.

Any attempt to start to use storage available to the hibernating kernel
is also going to have these race issues.

2. Lack of ACPI support.

At the moment, noone is going to want to use kexec based hibernation if
they have an ACPI system. This needs to be addressed before it can be
considered a serious contender.

3. Usability.

Right now, kexec based hibernation looks quite complicated to configure,
and the user is apparently going to have to remember to boot a different
kernel or at least a different bootloader entry in order to resume. Not
a plus. It would be good if you could find a way to use one bootloader
entry, resuming if there's an image, booting normally if there's not.

Nigel

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