From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
Cc: Linux Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>
Subject: Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n
Date: Fri, 19 Jun 2009 09:56:06 -0500 [thread overview]
Message-ID: <20090619145606.GB22381@us.ibm.com> (raw)
In-Reply-To: <m3zlc5kugu.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
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
next prev parent reply other threads:[~2009-06-19 14:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-17 0:17 [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n Serge E. Hallyn
[not found] ` <20090617001723.GA9452-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-06-18 16:46 ` Oren Laadan
[not found] ` <4A3A6F61.5030401-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-06-18 17:09 ` Serge E. Hallyn
2009-06-18 18:25 ` Nathan Lynch
[not found] ` <m3ws79h01p.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2009-06-18 22:32 ` Serge E. Hallyn
[not found] ` <20090618223213.GA13179-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-06-18 23:12 ` Nathan Lynch
[not found] ` <m3zlc5kugu.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2009-06-19 4:14 ` Oren Laadan
2009-06-19 14:56 ` Serge E. Hallyn [this message]
[not found] ` <20090619145606.GB22381-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-06-19 17:10 ` Nathan Lynch
[not found] ` <m3ljnogneb.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2009-06-19 17:53 ` Serge E. Hallyn
2009-06-19 4:06 ` Oren Laadan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090619145606.GB22381@us.ibm.com \
--to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.