linux-kernel - Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch

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: <alpine.DEB.2.00.1011071817560.24952@asgard.lang.hm>
Date:	Sun, 7 Nov 2010 18:32:40 -0800 (PST)
From:	david@...g.hm
To:	Davide Libenzi <davidel@...ilserver.org>
cc:	Matt Helsley <matthltc@...ibm.com>, Tejun Heo <tj@...nel.org>,
	Oren Laadan <orenl@...columbia.edu>,
	ksummit-2010-discuss@...ts.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch

On Sun, 7 Nov 2010, Davide Libenzi wrote:

> Please, do not compare things like single file systems, drivers, or
> otherwise fairly isolated components, with this "thing".
> This thing touches a freaky-large number of subsystems, effectively
> adding a glueage between them, which can might end up causing problems
> (and/or restrict design choices) in the future.

I've got a question about the ABI that would be created

I see two possible areas that could be considered an ABI

1. control of the C/R process

   This is very clearly a userspace ABI, to be figured out and locked down 
like any other ABI

2. the details of how things are stored and added back into a system

   This is not as clear. at one extreme, this could be like the module 
interface, (the checkpointed image is only guaranteed to work on a new 
system with a kernel compiled with the same config options as the system 
it was checkpointed from). At the other extreme, this could be something 
that allows you to ckeckpoint an image on 2.6.40 and restore it on 2.6.80. 
Or it could be something in between.

I don't see any way that it is sane to make the C/R image defiition and 
interface (#2) be an ABI that is guaranteed to never change without 
hurting future kernel development (exactly the type of things that Davide 
is worried about above), but what sort of guarantee are people interested 
in?

is it enough to sa that it must be the same kernel version compiled with 
the same options? (or at least the same options for some list of things 
that matter, most device drivers probably would not matter for example)

or would you need compatibility across all compile options for a kernel 
release?

would you require compatibility between 2.6.x.y and 2.6.x.z?

would you require compatibility between 2.6.x and 2.6.x+n (for some value 
of n)?

is this something that could go in with the weakest guarantee initially, 
and then as everyone is more comfortable with it, start extending the 
guarantee (and as-needed adding code to the kernel to maintain 
compatibility with old images)?

would you require compatibility between 2.6.x and 2.6.x-n?

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