building Kerberos libraries for PalmOS
raeburn at MIT.EDU
Tue Feb 17 13:39:11 EST 2004
I'm interested in this too, but haven't had time to really pursue it
much. A few things do come to mind:
It'll need to be a multisegment app or library; the code space will be
*way* too large for a single segment.
I think there's some debugging code that writes to stdout or stderr.
You'll probably want to comment it out.
The PalmOS development package doesn't have all the standard C header
files. Some code may need new conditionals that aren't already there.
Alternatively, you could drop in fake versions of some standard C
headers that include the appropriate ones from the PalmOS dev kit.
You'll need to create the equivalent of the include/krb5/autoconf.h
file that gets generated on UNIX, or the win-mac.h file currently used
only for Windows.
Some of the crypto code (AES comes to mind) has simple preprocessor
options that will reduce the code/data size, at some cost in speed.
You'll probably want to use those. Changing DES, MD4, MD5 and SHA-1 to
generate smaller code is also not hard, but requires some actual code
changes; I've started on some of those, and may get them checked in (as
options) for the 1.4 code base. Haven't really looked at RC4.
MIT Kerberos 1.3 assumes that getaddrinfo() is available for name
lookups, and if not, fakes it with a static function to implement it in
each object file using it. For the platforms we support, most have
getaddrinfo already, and one old one that we're probably on the verge
of de-supporting (just my guess, we haven't made any decisions) loses
several kilobytes of code space in each of several object files to fake
it. The PalmOS libraries don't have getaddrinfo, and including the
support code as is will add quite a bit of code. We'll probably be
moving it to a separate support library for 1.4, and possibly adding
more caching of results.
The credentials cache needs to be handled differently. Perhaps an
in-memory cache (for a single application getting tickets and using
them and discarding them on exit), or a Palm database file (presumably
marked not for backup).
You probably don't care about the code for supporting application
servers -- the replay cache support, keytab support, code for
decrypting AP-REQ messages and encrypting AP-REP messages, some of the
GSSAPI code, etc. From what I've seen, CW wants you to add each file
separately, so you can just leave out a bunch of them, though offhand I
don't have a list. Or, if you just add everything, and get it all to
compile, the linker should leave out unneeded parts of an archive
library when building an executable.
We've got recursion and large stack frames in places, and PalmOS apps
have fixed, generally small stack sizes. Some of the stack frames
could undoubtedly be made smaller, and the recursion cases might be
converted to iteration without a huge amount of difficulty, but they
have to be found, first. (I've got some ideas on tweaking GCC for
PalmOS so as to provide some of this information.)
Long-term memory management on the Palm is supposed to be done through
MemHandle objects, instead of through malloc and free. These handles
allow PalmOS to shift memory around while objects aren't being actively
referenced, to counter fragmentation. The MIT Kerberos code isn't set
up for this sort of indirection. You can use malloc and free, but your
application might run out of memory faster.
The config data, currently stored in krb5.conf, needs to be put
somewhere. A database might be one option, but you'd have to replace a
lot of the profile library code for accessing it. A memo with a magic
first line of "krb5.conf" is another sort of approach I've seen used;
just look for the memo and parse the body as the contents of the file
would be parsed. We've made some changes towards being able to work
without a krb5.conf file at all, but we're not completely there yet,
and there are some security issues that need to be considered.
I've written up some code for finding the local network addresses, as
an experiment in dealing with PalmOS code. That functionality is
needed for the Kerberos library; I'll see if I can dig up my sample
As you might gather, I don't believe this will be a trivial project.
Personally, I'm more interested in seeing it happen in a way compatible
with the GNU tools, in part because maintaining data for multiple build
systems means more work, and partly because I'm a free software guy and
I've done development work on the GNU tools. But the GNU tools for
PalmOS have a few problems.
Would MIT accept code changes related to this? Maybe, if they're clean
and general enough. Changes to a huge number of source files (e.g.,
the section annotations that would be needed for functions if we used
the GNU tools for PalmOS, which otherwise would be my preferred
approach) wouldn't be very desirable. Clean changes implementing an
"optimize for code size" option might be okay. Other changes...I don't
know, but we can talk about them.
On Monday, Feb 16, 2004, at 15:19 US/Eastern, Chaitanya Desai wrote:
> I am trying to build kerberos libraries for PDAs (Palm OS in
> My goal is to have library/libraries defining functions that simple
> applications that run on PDAs can call into.
> I am using Codewarrior for Palm as the IDE. Any suggestions on where I
> could start would be greatly appreciated.
> Chaitanya Desai.
> krbdev mailing list krbdev at mit.edu
More information about the krbdev