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

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Andrew G. Morgan (morgan@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?

> 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?

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