[PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Serge E. Hallyn]

It looks like Oren wanted ns c/r to "sort of work" with CONFIG_UTS_NS=n
but kernel/utsname.c is not compiled if CONFIG_UTS_NS=n.

Signed-off-by: Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
 include/linux/checkpoint.h |    5 +++++
 kernel/utsname.c           |   13 -------------
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/include/linux/checkpoint.h b/include/linux/checkpoint.h
index c2f04c5..ef4fc33 100644
--- a/include/linux/checkpoint.h
+++ b/include/linux/checkpoint.h
@@ -136,8 +136,13 @@ extern int checkpoint_ns(struct ckpt_ctx *ctx, void *ptr);
 extern void *restore_ns(struct ckpt_ctx *ctx);
 
 /* uts-ns */
+#ifdef CONFIG_UTS_NS
 extern int checkpoint_uts_ns(struct ckpt_ctx *ctx, void *ptr);
 extern void *restore_uts_ns(struct ckpt_ctx *ctx);
+#else
+#define checkpoint_uts_ns checkpoint_bad
+#define restore_uts_ns restore_bad
+#endif
 
 /* ipc-ns */
 #ifdef CONFIG_SYSVIPC
diff --git a/kernel/utsname.c b/kernel/utsname.c
index 76f9966..5c12ebb 100644
--- a/kernel/utsname.c
+++ b/kernel/utsname.c
@@ -130,11 +130,6 @@ static struct uts_namespace *do_restore_uts_ns(struct ckpt_ctx *ctx)
 	    h->domainname_len > sizeof(uts_ns->name.domainname))
 		goto out;
 
-	/*
-	 * If !CONFIG_UTS_NS, do not restore the global uts state, as
-	 * it is used by other processes.
-	 */
-#ifdef CONFIG_UTS_NS
 	ret = -ENOMEM;
 	uts_ns = create_uts_ns();
 	if (!uts_ns)
@@ -153,14 +148,6 @@ static struct uts_namespace *do_restore_uts_ns(struct ckpt_ctx *ctx)
 	up_read(&uts_sem);
 	if (ret < 0)
 		goto out;
-#else
-	ret = -EEXIST;
-	/* complain if image contains multiple namespaces */
-	if (ctx->stats.uts_ns)
-		goto out;
-	uts_ns = current->nsproxy->uts_ns;
-	get_uts_ns(uts_ns);
-#endif
 
 	ctx->stats.uts_ns++;
  out:
-- 
1.6.1

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Oren Laadan]

I think it's useful to be able to

1) checkpoint on a system with !CONFIG_UTS_NS,  and -
2) checkpoint on a system with CONFIG_UTS_NS and restart on a
system with !CONFIG_UTS_NS (as long as all tasks in the image
share a single uts-ns)

So I moved the code to checkpoint/namespace.c where it compiles
either way.

Oren

Serge E. Hallyn wrote:
> It looks like Oren wanted ns c/r to "sort of work" with CONFIG_UTS_NS=n
> but kernel/utsname.c is not compiled if CONFIG_UTS_NS=n.
> 
> Signed-off-by: Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> ---
>  include/linux/checkpoint.h |    5 +++++
>  kernel/utsname.c           |   13 -------------
>  2 files changed, 5 insertions(+), 13 deletions(-)
> 
> diff --git a/include/linux/checkpoint.h b/include/linux/checkpoint.h
> index c2f04c5..ef4fc33 100644
> --- a/include/linux/checkpoint.h
> +++ b/include/linux/checkpoint.h
> @@ -136,8 +136,13 @@ extern int checkpoint_ns(struct ckpt_ctx *ctx, void *ptr);
>  extern void *restore_ns(struct ckpt_ctx *ctx);
>  
>  /* uts-ns */
> +#ifdef CONFIG_UTS_NS
>  extern int checkpoint_uts_ns(struct ckpt_ctx *ctx, void *ptr);
>  extern void *restore_uts_ns(struct ckpt_ctx *ctx);
> +#else
> +#define checkpoint_uts_ns checkpoint_bad
> +#define restore_uts_ns restore_bad
> +#endif
>  
>  /* ipc-ns */
>  #ifdef CONFIG_SYSVIPC
> diff --git a/kernel/utsname.c b/kernel/utsname.c
> index 76f9966..5c12ebb 100644
> --- a/kernel/utsname.c
> +++ b/kernel/utsname.c
> @@ -130,11 +130,6 @@ static struct uts_namespace *do_restore_uts_ns(struct ckpt_ctx *ctx)
>  	    h->domainname_len > sizeof(uts_ns->name.domainname))
>  		goto out;
>  
> -	/*
> -	 * If !CONFIG_UTS_NS, do not restore the global uts state, as
> -	 * it is used by other processes.
> -	 */
> -#ifdef CONFIG_UTS_NS
>  	ret = -ENOMEM;
>  	uts_ns = create_uts_ns();
>  	if (!uts_ns)
> @@ -153,14 +148,6 @@ static struct uts_namespace *do_restore_uts_ns(struct ckpt_ctx *ctx)
>  	up_read(&uts_sem);
>  	if (ret < 0)
>  		goto out;
> -#else
> -	ret = -EEXIST;
> -	/* complain if image contains multiple namespaces */
> -	if (ctx->stats.uts_ns)
> -		goto out;
> -	uts_ns = current->nsproxy->uts_ns;
> -	get_uts_ns(uts_ns);
> -#endif
>  
>  	ctx->stats.uts_ns++;
>   out:

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Serge E. Hallyn]

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> 
> I think it's useful to be able to
> 
> 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
> 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
> system with !CONFIG_UTS_NS (as long as all tasks in the image
> share a single uts-ns)
> 
> So I moved the code to checkpoint/namespace.c where it compiles
> either way.

That sounds good :)

-serge

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Nathan Lynch]

Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:

> I think it's useful to be able to
>
> 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
> 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
> system with !CONFIG_UTS_NS (as long as all tasks in the image
> share a single uts-ns)

In principle I agree, but what confidence can we have that meaningful
testing of such configurations (especially #2) will occur?

Flexibility is good, but the complexity involved in properly supporting
checkpoint with all possible combinations of CONFIG_*_NS seems daunting.
Just consider the build matrix (assuming CONFIG_CHECKPOINT=y):

+------ CONFIG_CGROUP_NS
|+----- CONFIG_UTS_NS
||+---- CONFIG_IPC_NS
|||+--- CONFIG_NET_NS
||||+-- CONFIG_USER_NS
|||||+- CONFIG_PID_NS
nnnnnn
ynnnnn
yynnnn
yyynnn
yyyynn
yyyyyn
....
nynnnn
nyynnn
nyyynn
nyyyyn
nyyyyy
...

You get the idea, I'm sure: at least 64 distinct build configurations
that are salient to checkpoint.  Is anybody building even a fraction of
those?

Add actual runtime testing of C/R to that workload and it quickly
becomes impractical to achieve decent test coverage.  And accommodating
C/R between kernels with different CONFIG_*_NS settings introduces a
combinatorial explosion of scenarios to test.

CONFIG_CHECKPOINT should just depend on all of CONFIG_*_NS.  Otherwise
we're going to have an abundance of corner cases at build time and (more
importantly) run time that never get exercised.

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Serge E. Hallyn]

Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
> Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:
> 
> > I think it's useful to be able to
> >
> > 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
> > 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
> > system with !CONFIG_UTS_NS (as long as all tasks in the image
> > share a single uts-ns)
> 
> In principle I agree, but what confidence can we have that meaningful
> testing of such configurations (especially #2) will occur?

History says, low confidence.  So far just 1 is bad enough.  It's
taking a lot of my time on the LSM c/r (with the various combinations
of CONFIG_SECURITY, CONFIG_IPC_NS, and CONFIG_CHECKPOINT), and things
like CONFIG_IPC_NS consistently break c/r anyway.

So for 2 i'm tempted to say let's encode a sha1sum of the .config
into the checkpoint header.  We'll keep *trying* to support (2), and
userspace can trivially rewrite the header if it really wants to believe
we've succeeded.

And for 1, I agree - most distros ship with namespaces enabled
anyway, and one day I expect we'll get rid of those configs, so
I see no reason to support CONFIG_CHECKPOINT if any namespaces are
turned off.

In fact, I thought that last week Dave suggested that, and Nathan
was against it?  :)

-serge

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Nathan Lynch]

"Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
> Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
>> Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:
>> 
>> > I think it's useful to be able to
>> >
>> > 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
>> > 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
>> > system with !CONFIG_UTS_NS (as long as all tasks in the image
>> > share a single uts-ns)
>> 
>> In principle I agree, but what confidence can we have that meaningful
>> testing of such configurations (especially #2) will occur?
>
> History says, low confidence.  So far just 1 is bad enough.  It's
> taking a lot of my time on the LSM c/r (with the various combinations
> of CONFIG_SECURITY, CONFIG_IPC_NS, and CONFIG_CHECKPOINT), and things
> like CONFIG_IPC_NS consistently break c/r anyway.
>
> So for 2 i'm tempted to say let's encode a sha1sum of the .config
> into the checkpoint header.  We'll keep *trying* to support (2), and
> userspace can trivially rewrite the header if it really wants to believe
> we've succeeded.

Are you suggesting having sys_restart code path consult the .config
sha1sum in the image?  Or is it just for the benefit of userspace?  If
the former, I'm having difficulty grasping the benefit.

>
> And for 1, I agree - most distros ship with namespaces enabled
> anyway, and one day I expect we'll get rid of those configs, so
> I see no reason to support CONFIG_CHECKPOINT if any namespaces are
> turned off.
>
> In fact, I thought that last week Dave suggested that, and Nathan
> was against it?  :)

I was against using select in the CHECKPOINT config item to force-enable
CONFIG_*_NS.  Making CHECKPOINT depend on the namespace options strikes
me as a sane tradeoff here.

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Oren Laadan]

Nathan Lynch wrote:
> Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:
> 
>> I think it's useful to be able to
>>
>> 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
>> 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
>> system with !CONFIG_UTS_NS (as long as all tasks in the image
>> share a single uts-ns)
> 
> In principle I agree, but what confidence can we have that meaningful
> testing of such configurations (especially #2) will occur?
> 

Given that the code works well with namespaces configured, what
does it take to allow #1 and #2 ?

#1 - Nothing. It can come for free in terms of extra code; Only
ensure that the code compiles (e.g. placing elsewhere).

#2 - It means that:
  (a) Fail if original checkpoint had more than one instance of
      a given namespace (i.e. not all tasks share the same namespace).
  (b) In restore_xxxx_ns(), don't create new namespace, but return
      a reference to the current one.
  (c) Don't restore "global" settings of the namespace (like UTS
      data, IPC knobs) - just consume that data from the input.


> Flexibility is good, but the complexity involved in properly supporting
> checkpoint with all possible combinations of CONFIG_*_NS seems daunting.
> Just consider the build matrix (assuming CONFIG_CHECKPOINT=y):
> 
> +------ CONFIG_CGROUP_NS

This option seems to be under extinction...

> |+----- CONFIG_UTS_NS
> ||+---- CONFIG_IPC_NS
> |||+--- CONFIG_NET_NS

These three options are entirely independent in meaning and in code.
Testing CONFIG_UTS_NS and !CONFIG_UTS_NS is self-sufficient, and
should not(*) affect or be affected by the others.

(*) "Should" - this very statement may require validation.

> ||||+-- CONFIG_USER_NS

I'm tempted to argue that this, too, can be tested independently
of the others.

> |||||+- CONFIG_PID_NS

Need not be tested: no special action for #1, and #2 will simply
fail in user space attempting to create the tasks hierarchy.

> nnnnnn
> ynnnnn
> yynnnn
> yyynnn
> yyyynn
> yyyyyn
> ....
> nynnnn
> nyynnn
> nyyynn
> nyyyyn
> nyyyyy
> ...
> 
> You get the idea, I'm sure: at least 64 distinct build configurations
> that are salient to checkpoint.  Is anybody building even a fraction of
> those?
> 
> Add actual runtime testing of C/R to that workload and it quickly
> becomes impractical to achieve decent test coverage.  And accommodating
> C/R between kernels with different CONFIG_*_NS settings introduces a
> combinatorial explosion of scenarios to test.
> 
> CONFIG_CHECKPOINT should just depend on all of CONFIG_*_NS.  Otherwise
> we're going to have an abundance of corner cases at build time and (more
> importantly) run time that never get exercised.
> 

IMHO testing N cases (N is number of namespaces) - each test will
"checkpoint on CONFIG_xxx_NS and restart on !CONFIG_xxx_NS" will
suffice to provide a high level of confidence (see * above).

The alleviate the complexity and cost of testing, we can add a knob
that will tell the c/r code to run as if !CONFIG_xxx_NS, so for a
runtime test no need to compile x2 and then repeat "boot -> checkpoint
-> boot -> restart", but instead compile x1 and boot, and then repeat
"unset knob -> checkpoint -> set knob -> restart".

Oren.

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Oren Laadan]

Nathan Lynch wrote:
> "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
>> Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
>>> Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:
>>>
>>>> I think it's useful to be able to
>>>>
>>>> 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
>>>> 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
>>>> system with !CONFIG_UTS_NS (as long as all tasks in the image
>>>> share a single uts-ns)
>>> In principle I agree, but what confidence can we have that meaningful
>>> testing of such configurations (especially #2) will occur?
>> History says, low confidence.  So far just 1 is bad enough.  It's
>> taking a lot of my time on the LSM c/r (with the various combinations
>> of CONFIG_SECURITY, CONFIG_IPC_NS, and CONFIG_CHECKPOINT), and things
>> like CONFIG_IPC_NS consistently break c/r anyway.
>>
>> So for 2 i'm tempted to say let's encode a sha1sum of the .config
>> into the checkpoint header.  We'll keep *trying* to support (2), and
>> userspace can trivially rewrite the header if it really wants to believe
>> we've succeeded.
> 
> Are you suggesting having sys_restart code path consult the .config
> sha1sum in the image?  Or is it just for the benefit of userspace?  If
> the former, I'm having difficulty grasping the benefit.

A similar topic came up on the futex thread, so I'm bringing the
point I made there to this thread instead:

I think it is useful to encode somehow (some of) the configuration
of the kernel used when a checkpoint is taken.

This information would indicate, in a sense, the set of assumptions
on the environments that can possibly restart from that checkpoint.

This can be checked by user space against the current kernel at
restart, and at the very least issue a warning about possible
incompatibility. (Just like we will need to encode the minimal
CPU capabilities for a restart to succeed).

If an incompatibility is suspected, user could override and proceed
as is, or modify the image, etc.

I wasn't thinking of a sha1, though, because that does not give
knowledge about what is different between the environments, and is
likely to be too restrictive.

And I agree with Nathan that it makes less sense to do this in the
kernel. (For the kernel, garbage-in-garbage-out.)  It can be very
useful to do this in user space, where the user/caller can adjust
before passing an incompatible image to the kernel.

Oren.

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Serge E. Hallyn]

Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
> "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
> > Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
> >> Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:
> >> 
> >> > I think it's useful to be able to
> >> >
> >> > 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
> >> > 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
> >> > system with !CONFIG_UTS_NS (as long as all tasks in the image
> >> > share a single uts-ns)
> >> 
> >> In principle I agree, but what confidence can we have that meaningful
> >> testing of such configurations (especially #2) will occur?
> >
> > History says, low confidence.  So far just 1 is bad enough.  It's
> > taking a lot of my time on the LSM c/r (with the various combinations
> > of CONFIG_SECURITY, CONFIG_IPC_NS, and CONFIG_CHECKPOINT), and things
> > like CONFIG_IPC_NS consistently break c/r anyway.
> >
> > So for 2 i'm tempted to say let's encode a sha1sum of the .config
> > into the checkpoint header.  We'll keep *trying* to support (2), and
> > userspace can trivially rewrite the header if it really wants to believe
> > we've succeeded.
> 
> Are you suggesting having sys_restart code path consult the .config
> sha1sum in the image?

Yup.

> Or is it just for the benefit of userspace?  If
> the former, I'm having difficulty grasping the benefit.

Well we could also do it in userspace, but it seemed easier to actually
store the sha1sum in a char buf in the c/r code in the kernel, stick it
in the header at checkpoint, and verify it at restart.

The benefit?  Well...  really I feel opposite today.  Along the lines
of supporting unprivileged restart as long as possible to make us
consider security, I guess I'd argue we should support heterogenous
(in terms of config :) c/r as long as possible.  The reason I was
thinking otherwise yesterday is that I have to special-case things
like the task->security objref when CONFIG_SECURITY=n.  It felt
hacky yesterday, but the end result looks pretty good and is i 
think better thought out than it would have been were we doing the
sha1sum thing.

-serge

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Nathan Lynch]

"Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:

> Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
>> "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
>> > Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
>> >> Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:
>> >> 
>> >> > I think it's useful to be able to
>> >> >
>> >> > 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
>> >> > 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
>> >> > system with !CONFIG_UTS_NS (as long as all tasks in the image
>> >> > share a single uts-ns)
>> >> 
>> >> In principle I agree, but what confidence can we have that meaningful
>> >> testing of such configurations (especially #2) will occur?
>> >
>> > History says, low confidence.  So far just 1 is bad enough.  It's
>> > taking a lot of my time on the LSM c/r (with the various combinations
>> > of CONFIG_SECURITY, CONFIG_IPC_NS, and CONFIG_CHECKPOINT), and things
>> > like CONFIG_IPC_NS consistently break c/r anyway.
>> >
>> > So for 2 i'm tempted to say let's encode a sha1sum of the .config
>> > into the checkpoint header.  We'll keep *trying* to support (2), and
>> > userspace can trivially rewrite the header if it really wants to believe
>> > we've succeeded.
>> 
>> Are you suggesting having sys_restart code path consult the .config
>> sha1sum in the image?
>
> Yup.
>
>> Or is it just for the benefit of userspace?  If
>> the former, I'm having difficulty grasping the benefit.
>
> Well we could also do it in userspace, but it seemed easier to actually
> store the sha1sum in a char buf in the c/r code in the kernel, stick it
> in the header at checkpoint, and verify it at restart.
>
> The benefit?  Well...  really I feel opposite today.  Along the lines
> of supporting unprivileged restart as long as possible to make us
> consider security, I guess I'd argue we should support heterogenous
> (in terms of config :) c/r as long as possible.  The reason I was
> thinking otherwise yesterday is that I have to special-case things
> like the task->security objref when CONFIG_SECURITY=n.  It felt
> hacky yesterday, but the end result looks pretty good and is i 
> think better thought out than it would have been were we doing the
> sha1sum thing.

Okay.  My thought was that the sha1sum would be as subject to tampering
as anything else in the image, so the restart path couldn't really rely
on it to convey accurate information about the image contents.  But I
suppose it's moot now.

Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Serge E. Hallyn]

Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
> "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
> 
> > Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
> >> "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
> >> > Quoting Nathan Lynch (ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org):
> >> >> Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:
> >> >> 
> >> >> > I think it's useful to be able to
> >> >> >
> >> >> > 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
> >> >> > 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
> >> >> > system with !CONFIG_UTS_NS (as long as all tasks in the image
> >> >> > share a single uts-ns)
> >> >> 
> >> >> In principle I agree, but what confidence can we have that meaningful
> >> >> testing of such configurations (especially #2) will occur?
> >> >
> >> > History says, low confidence.  So far just 1 is bad enough.  It's
> >> > taking a lot of my time on the LSM c/r (with the various combinations
> >> > of CONFIG_SECURITY, CONFIG_IPC_NS, and CONFIG_CHECKPOINT), and things
> >> > like CONFIG_IPC_NS consistently break c/r anyway.
> >> >
> >> > So for 2 i'm tempted to say let's encode a sha1sum of the .config
> >> > into the checkpoint header.  We'll keep *trying* to support (2), and
> >> > userspace can trivially rewrite the header if it really wants to believe
> >> > we've succeeded.
> >> 
> >> Are you suggesting having sys_restart code path consult the .config
> >> sha1sum in the image?
> >
> > Yup.
> >
> >> Or is it just for the benefit of userspace?  If
> >> the former, I'm having difficulty grasping the benefit.
> >
> > Well we could also do it in userspace, but it seemed easier to actually
> > store the sha1sum in a char buf in the c/r code in the kernel, stick it
> > in the header at checkpoint, and verify it at restart.
> >
> > The benefit?  Well...  really I feel opposite today.  Along the lines
> > of supporting unprivileged restart as long as possible to make us
> > consider security, I guess I'd argue we should support heterogenous
> > (in terms of config :) c/r as long as possible.  The reason I was
> > thinking otherwise yesterday is that I have to special-case things
> > like the task->security objref when CONFIG_SECURITY=n.  It felt
> > hacky yesterday, but the end result looks pretty good and is i 
> > think better thought out than it would have been were we doing the
> > sha1sum thing.
> 
> Okay.  My thought was that the sha1sum would be as subject to tampering
> as anything else in the image, so the restart path couldn't really rely
> on it to convey accurate information about the image contents.  But I
> suppose it's moot now.

whoa, I was in no way suggesting this as a way to stop userspace from
loading such an image.  As I said in an earlier email, it would be
trivial - and be a feature - for userspace to rewrite the ckpt image
with the new kernels' sha1sum(config).

So the sha1sum would be to protect userspace from itself.  To actually
prevent userspace from loading such a ckpt image at all, we would need
to ask the TPM to sign the ckpt image with a private key stored only on
the TPM.

-serge