Subject: compressed vnd, cgd and encryption
To: None <firstname.lastname@example.org>
From: Stephen Borrill <email@example.com>
Date: 06/23/2006 12:31:25
I've a need to have compressed vnds which aren't easily readable except by
the target system. The target system will vary in spec, but could be as
low as P100, 64MB RAM. I can think of a few scenarios:
1) makefs > vncompress > bdes encrypt. On target, bdes decrypt to mfs
and run from there (currently using this)
Pros: easy to generate
one-time decryption (so no per-access overhead)
No kernel size overhead
Cons: Expensive on RAM
2) makefs (to get image size for cgd) > make cgd in vnd > copy data >
vncompress. Run in-situ on target
Pros: No RAM overhead
Cons: cgd data won't compress well
kernel overhead for cgd
Potentially computationally heavy on low-end machine
3) As 2), but attempt to reverse order of cgd and vncompress
Pros: As 2), but should compress much better.
Cons: As 2), plus is it even possible?
4) makefs, vncompress, some form of basic encryption. Extend vnd to be
able to decrypt on fly before passing to uncompression.
Somewhere in compstrategy() in dev/vnd.c looks like the right place, just
before the /* uncompress the buffer */ line (row 1663).
Encryption could be similar to bdes or perhaps something more simple (even
EORing a repeated key).
Pros: Could hardwire key at compile time in kernel
Lightweight encryption not a big computational overhead
Little kernel size overhead
Will compress well
No RAM overhead
Cons: Requires kernel hacking
Does vnd's file access mechanisms allow this to be slotted in?
Option 4) seems best to me for my particular purposes. Thoughts?
(Please CC: me in on replies)