Notices

see http://www.truecrypt.org/docs/?s=une...ed-data-in-ram
the faq is mostly for windows, but many statements are true for any OS.

meaning, high-security apps should take proper percautions to avoid memory leaks and plaintext memory anyways. this doesn't only apply to swap but also to memory in general.
and as the link states, truecrypt does not care about swap or memory, it only encrypts "disk" drives.

I'm aware of that. However, when the 256MB of ram is depleted "unused" pages get transferred to swap. That could be background processes or apps you might have running and with them, the potential of truecrypt's master key & cleartext data from the encrypted partition.

This has nothing to do with memory leaks: data will always be available unencrypted in RAM so applications can use it. I should add that when swap is no longer needed, references to it are deleted but data still remains on the flash module which you can easily retrieve with dd.

This is why all (or most) linux distributions encrypt swap with a random key on boot if you enable encryption when installing.

You can make a encrypted swap on linux several way. However, I don't believe the required stuff has been recompiled yet for the n900.

As for Truecrypt; the only reason I converted it is I have used TC since before it was called TC on my windows machines. So, I prefer to be able to allow my newest device to also access the same files all the other computers can. For those who don't have legacy; their are other methods to do encryption on the linux that would probably be better.

Nathan

To permanently enable the module, do
this will trigger automatic loading of the cifs module at bootup.[/QUOTE]

This doesn't work, the cifs.ko module isn't automatically loaded...

How must this be done?

digitalvoid, did you do this:

if yes, try echo "cifs.ko" instead of echo "cifs", but usually that shouldn't be necessary.

Still doesn't work...

LOL, it should work; but apparently the init code is broken that loads it.

I just tracked down how it is supposed to load via "module-init-tools" and that script references "/etc/default/rcS" which doesn't exist causing the script to abort out.

I have another method that might work.

Nathan

you're right, apparently Maemo doesn't honor /etc/modules
i just tested it, and couldn't even get stock modules to load automatically.

/etc/init.d/module-init-tools should take care of that, but apparently it doesn't... possibly a bug?

edit:
nathan tracked it down faster

To Fix (I've update the Page 1 instructions).

You need to be root.
Ergh, still didn't work. Give me a couple more minutes.

Nathan

looks like /etc/event.d is the actual boot facility. it does start an init.d script, /etc/init.d/rcS, but that doesn't care particularly about /etc/modules

/etc/init.d/rcS itself contains an array of modules in $MODULES, one could add "cifs" as a new line there between somewhere (be careful not to break the string!), then it gets loaded at startup.

i just verified this works, while i also got to test the alternative boot video

it's not a very elegant solution, though. it probably would make sense to file a bug about the old init.d startup scripts, since /etc/event.d/rcS specifically mentions "the old sysv-rc startup scripts", but only calls init.d/rcS