[PATCH 5/9] cr: capabilities: define checkpoint and restore fns

[Andrew G. Morgan]

On Fri, Jun 5, 2009 at 12:41 PM, Serge E. Hallyn <serue at us.ibm.com> wrote:
> Quoting Andrew G. Morgan (morgan at kernel.org):
> ...
>> > Now you mention using kernel_cap_t's...  we can go partway
>> > down that road, but the inherent problem is serializing the
>> > relevant data so it can be streamed to some file.  So I
>> > think it's better if the subsystems are required to specify
>> > a useful format (like struct ckpt_capabilities) and define
>> > the checkpoint/restart helpers to serialize data into the
>> > struct.  We can try and get cute with dual mirrored
>> > struct defs, one which is defined in terms the caps code
>> > can understand, and one defined in more arch-independent
>> > terms (which is why we need __u64s and packed, for instance).
>> > But that seems more fragile than having clear and simple
>> > requirements for the $SUBYSTEM_checkpoint() and $SUBSYSTEM_restart()
>> > helpers.
>>
>> I like this $SUBSYSTEM_checkpoint() etc. thing.
>>
>> I like the ckpthdr.sed thing. I think a similar rule could be used to
>> generate the calls to the list of $SUBSYSTEM_checkpoint() functions.
>
> Sorry, I don't follow.  Could you say a bit more about this?

See sketch below.

>
>> For serialization, could a kernel "gcc -E checkpoint-headers.h >
>> this-kernel-checkpoint-file.h" build rule be enough?
>
> Again, I don't follow.  Do you mean to turn something like kernel_cap_t
> into something like struct ckpt_capabilities?

Yes, but without manual effort.

To return the the 1,2,3 breakdown. I think it should be possible for 1
to provide code like this:

$SUBSYSTEM_header.h:
  struct ckpt_$SUBSYSTEM_s {
     kernel_foo_t a, b, c;
  };

$SUBSYSTEM_code.c:
  void $SUBSYSTEM_checkpoint(struct *storage_ptr)
  {
  }

  int $SUBSYSTEM_restore(struct *storage_ptr)
  {
  }

2 would be 'sed'(perl) generated:

temp_header.h:
  foreach $x (sort @SUBSYSTEMS) {
    print "#include <$SUBSYSTEM_header.h>\n";
  }
  print "extern full_checkpoint();\n";
  print "struct uber_ckpt_struct {\n";
  foreach $x (sort @SUBSYSTEMS) {
    print "  struct ckpt_$x_s $x;\n";
  }
  print <<EOT;
};

#ifdef __kernel_source__
full_checkpoint()
{
EOT
  foreach $x (sort @SUBSYSTEMS) {
    print "  $x_checkpoint();\n";
  }
  print <<EOT;
}
#endif
EOT

"ditto for restore, but pay attention to return codes".

Then, for '3', gcc -E temp_header.h | sed 'cut from line after 'extern
full_checkpoint'.

That means:

  1. gets to define its checkpoint state with its own conventions
  2. gets generated with some perl/sed/whatever - low maintenance
  3. gets a plain C serialization of the checkpointed state.

The kernel code subsystem code is king here. It defines its
checkpoints in whatever manner it feels is natural for the specific
subsystem. The glue code is autogenerated. User space has full access
to the data in a plain C format. The user space code is where things
are fragile, if the user space code wants to manipulate the
checkpointed data in some way, but I think there will always be at
least one place in the system for fragility and user space is the best
place for it.

Cheers

Andrew

>
> thanks,
> -serge
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>