Kernel subset design issues

[Greg Hudson]

On Tue, 2011-04-26 at 04:16 -0400, Sam Hartman wrote:
> Why not only use IOV and enable the #define to do everything in terms of
> iov instead of having iov and non-iov wrap implementations?

It's not quite that simple (the fallback you're thinking of is
implemented in the mechglue, and also there are no IOV versions of
get_mic/verify_mic), but with a little work I think it should be
possible to just have the IOV code in libkgss with wrappers for non-IOV
operations.  Based on the feedback so far, I'm assuming this is the
direction I should go.

Adding the IOV code raises another nitty detail, which is that the IOV
code makes three calls to gss_release_buffer() (because of
GSS_IOV_BUFFER_FLAG_ALLOCATE) which is implemented in the mechglue.  I
have a not-too-horrible workaround for that, which is to funnel two of
the calls through kg_release_iov() and have kg_release_iov do the buffer
manipulation directly.

Nico wrote:
> Why is that serialized krb5 context there at all??
[...]
> I never understood why we need to distinguish between "exported sec
> context" and "exported lucid sec context",

I'm not really prepared to defend the serialization approach to
gss_export_sec_context, but I'd also not prepared to throw it out within
the scope of this project.  (I realize that taking this attitude means
some stuff stays ugly for much longer than it really should, but it's
necessary to actually get things done on a reasonable schedule.)

> And you could minimize the need for internal krb5 APIs in the
> mechanism...  (this would be ideal, IMO).

We need at least krb5int_arcfour_gsscrypt(), as gss-krb5 doesn't use the
same RC4 token format as the RFC 3961 profile does.  We also need
krb5int_c_mandatory_cksumtype(), which should probably just be a public
API.

It's more that code in the krb5 tree includes k5-int.h as a matter of
course; that's just how we do platform portability, helper static inline
functions, etc..  It's very convenient in general, but for the current
purpose it might be nice if the files in the kernel subset were more
selective about what they included.  To make that possible, k5-int.h
will have to be decomposed a bit so that you can get access to, say, the
prototypes for the non-public libk5crypto APIs by themselves.

> Incidentally, will you implement a kernel-mode mechglue as well?  I
> imagine that's out of scope.

I wasn't planning on it; I don't feel like we could do a great job of
that.