[openbeos] Re: Networking Wish-list & File Systems
- From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 19 Oct 2001 14:11:39 CDT
Hmmm, I think I'll chime in on this one...
I think this discussion is covering some really cool ideas. But I don't
think it's too important, certainly not for OBv1.0.
Think about natively compressed/encrypted disks: What is the benefit?
For the compression, you save disk space. I've seen this implemented
for small embedded devices. But for a desktop OS, this is of little
concern -- hard disks are becoming as cheap as they are huge. Then you
have encryption. This is a security feature that some would like to
have. But then again, how many desktop OS's come out with support for
native file system encryption? Is this an item badly needed by or
greatly requested from the BeOS user base?
Don't misunderstand. I do think this is cool and worth doing down the
road aways. And it wouldn't hurt for those designing the kernel, file
systems, etc. to keep these ideas in mind while they implement the
code. But I would hate to see the kernel development bogged down, for
example, with testing and bug chasing an encrypted boot volume. I
highly recommend that any encryption features we create should be
designed so that they could be "dropped in" (or yanked out) at any
time, and not create a fundamental dependency in the basic system.
>
>Robert Medeiros <robert.medeiros@xxxxxxxxxxxx> wrote
>on Fri, 19 Oct 2001 05:22:20 -0400:
>>> There should be plugins for different encryption methods/strengths
>>> IMHO. A seperate kit (server?) would work for normal applications,
>>> but if the filesystem during booting is to rely on a server not
>>> started yet... problem... :-/ Or is there a more elegant
>>> solution?
>
>There are two obvious choices: a block level device that does
>encryption and thus lets you use any file system you want. Easy
>to write too. Or one which is a pass-thru file system that
>handles the encryption of individual data files that are each
>stored on some other file system.
>
>> I've seen crypto done quite nicely using the translation kit
>> (which makes a lot of sense when you think about it), but
>> sticking it in a CryptoKit just sort of graces the whole thing
>> with officialness - it's part of the OS that way.
>
>I like the idea of using it as a translator. Same thing should be
>done for compression libraries. The trouble is that translators
>aren't callable from kernel mode (I assume). At least not
>directly, there would have to be a user mode stub program that
>communicates with the kernel via shared memory or message buffers
>to do the actual encryption. This means an extra buffer copy
>step (has to copy the decrypted data to the shared memory buffer
>and the kernel mode code copies that into the calling program's
>buffer, rather than decrypting directly into the caller's buffer).
>Probably worth the trouble as it lets all programs get access
>to the same encryption code via translators.
>
>> From that perspective it's more an issue of appearances than a
>> question of where the code actually lives. But I see your point
>> about boot time troubles. Maybe separate logical encrypted
>> volumes, like what PGPdisk does, would be a good way to tackle
>> this.
>
>Then you'd need to stick the boot file system or block driver into
>the boot image somehow. Or have a non-encrypted initial boot volume.
>Guess you could actually do that with openbeos!
>
>- Alex
>
Other related posts:
