Subject: Re: compressed vnd, cgd and encryption
To: Daniel Carosone <dan@geek.com.au>
From: Stephen Borrill <netbsd@precedence.co.uk>
List: tech-kern
Date: 06/23/2006 13:23:31
On Fri, 23 Jun 2006, Daniel Carosone wrote:
> On Fri, Jun 23, 2006 at 09:54:05PM +1000, Daniel Carosone wrote:
>> On Fri, Jun 23, 2006 at 09:47:13PM +1000, Daniel Carosone wrote:
>>> cgd on vnd works
>>
>> but you wanted to know about vnd on cgd - this certainly also works.
>
> and finally I get what you were concerned about: will this work
> directly with vnd on the cgd device raw, without a filesystem in
> between?  no. vnd will need a filesystem to hold the file, cgd or not.
>
> However, you could use a pretty light-weight and simple filesystem in
> the cgd, especially given you're going to be read-only. I suggest
> cd9660 with the single vnd file inside.
>
> Of course, you wanted all of this to start with a file on the client,
> and you're still going to need that for the cgd, which means another
> vnd.
>
> So you'll wind up with:
>
> - makefs -t ffs
> - vndcompress
> - makefs -t cd9660
> - dd same file size
> - vnconfig
> - cgdconfig
> - dd cd9660 image into cgd
>
> and on the client machine,
> ffs-on-compressedvnd-on-cd9660-on-cgd-on-vnd.  Which will work, but
> will probably also drive you batty.

I could do with remaining sane :-)

I'm also concerned about overhead here on low-end CPU machines.

> What you really want is a
> compressed filesystem you can mount from the cgd directly.  I don't
> have any good suggestions for that, sorry.

ISTR cgd being CPU intensive hence me thinking about a lightweight 
encryption built into vnd at the point of decompression. I think I'll do a 
proof of concept say just EORing all the compressed vnd with a single 
value and seeing what I achieve.

> What are you storing in here? Can you really not do the decompression
> in userland, even counting tricks like gzexe?

I'm storing chunks of software, libraries and data (e.g. linux emulation 
or X). It's not sensitive data, it's more for copy protection.

-- 
Stephen