linux-kernel - Re: [RFC v7][PATCH 2/9] General infrastructure for checkpoint restart

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] [day] [month] [year] [list]

Message-ID: <20081028183322.GA13684@us.ibm.com>
Date:	Tue, 28 Oct 2008 13:33:22 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	Oren Laadan <orenl@...columbia.edu>, linux-api@...r.kernel.org,
	containers@...ts.linux-foundation.org, mingo@...e.hu,
	linux-kernel@...r.kernel.org,
	Peter Chubb <peterc@...ato.unsw.edu.au>, linux-mm@...ck.org,
	hpa@...or.com, Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org, tglx@...utronix.de,
	viro@...iv.linux.org.uk
Subject: Re: [RFC v7][PATCH 2/9] General infrastructure for checkpoint
	restart

Quoting Dave Hansen (dave@...ux.vnet.ibm.com):
> On Mon, 2008-10-27 at 17:51 -0400, Oren Laadan wrote:
> > >       Instead, how about a flag to sys_checkpoint() -- DO_RISKY_CHECKPOINT --
> > > which checkpoints despite !may_checkpoint?
> > 
> > I also agree with Matt - so we have a quorum :)
> > 
> > so just to clarify: sys_checkpoint() is to fail (with what error ?) if the
> > deny-checkpoint test fails.
> > 
> > however, if the user is risky, she can specify CR_CHECKPOINT_RISKY to force
> > an attempt to checkpoint as is.
> 
> This sounds like an awful lot of policy to determine *inside* the
> kernel.  Everybody is going to have a different definition of risky, so
> this scheme will work for approximately 5 minutes until it gets
> patched. :)
> 
> Is it possible to enhance our interface such that users might have some
> kind of choice on these matters?

Well we could always just add a field to /proc/self/status, and let
userspace check that field (after freezing the task) for the
presence of CR_CHECKPOINT_RISKY and make up its own mind.

Though my preference is for simplicity - just refuse the checkpoint.
That way people might screan loudly enough for us to support the
features they want.  If we let them just bypass and hope for the
best that starts to dilute some of the intended effect of all this.

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