Re: encrypted root fs on a slug and crypto-modules
* Anders Lennartsson [EMAIL PROTECTED] [2008-03-09 23:54]: Thanks for your report. I'll add crypto-modules when we update the installer to 2.6.24. (Which will happen after beta1 is released, which should hopefully be soon.) Thanks for spotting my report and adding the modules. The module is now available for the daily installer images: http://people.debian.org/~kmuto/d-i/images/daily/ -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kexec on ARM? (Was Re: encrypted root fs on a slug and crypto-modules)
Hello, On Thu, 03 Apr 2008, Martin Michlmayr wrote: * Kapil Hari Paranjape [EMAIL PROTECTED] [2008-04-01 16:15]: However, I note that there is supposed to be some support for kexec on arm since 2.6.22 but it is not built-in for the Debian kernels. Is the reason for this documented somewhere? There's no good reason it's disabled apart from the fact that there has been no demand for it yet. Can you re-compile the Debian kernel with kexec (*) and tell me if it works. If so, I'm happy to enable it. I'll first see if kexec-tools can be compiled. This might take less time than compiling the kernel. ;-) Without kexec-tools the procedure I outlined wouldn't work anyway. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kexec on ARM? (Was Re: encrypted root fs on a slug and crypto-modules)
Hello, On Thu, 03 Apr 2008, Tomasz Chmielewski wrote: kexec and kexec-tools work on debian-arm - I use it on FSG-3: http://wpkg.org/Running_Debian_on_Freecom_FSG-3#kexec Great. I just managed to get kexec-tools compiled. Now I've to go and compile that kernel! Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kexec on ARM? (Was Re: encrypted root fs on a slug and crypto-modules)
Kapil Hari Paranjape schrieb: Hello, On Thu, 03 Apr 2008, Martin Michlmayr wrote: * Kapil Hari Paranjape [EMAIL PROTECTED] [2008-04-01 16:15]: However, I note that there is supposed to be some support for kexec on arm since 2.6.22 but it is not built-in for the Debian kernels. Is the reason for this documented somewhere? There's no good reason it's disabled apart from the fact that there has been no demand for it yet. Can you re-compile the Debian kernel with kexec (*) and tell me if it works. If so, I'm happy to enable it. I'll first see if kexec-tools can be compiled. This might take less time than compiling the kernel. ;-) Without kexec-tools the procedure I outlined wouldn't work anyway. kexec and kexec-tools work on debian-arm - I use it on FSG-3: http://wpkg.org/Running_Debian_on_Freecom_FSG-3#kexec -- Tomasz Chmielewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kexec on ARM? (Was Re: encrypted root fs on a slug and crypto-modules)
* Kapil Hari Paranjape [EMAIL PROTECTED] [2008-04-01 16:15]: I didn't check that kexec is currently not supported on arm under Debian. :-( However, I note that there is supposed to be some support for kexec on arm since 2.6.22 but it is not built-in for the Debian kernels. Is the reason for this documented somewhere? There's no good reason it's disabled apart from the fact that there has been no demand for it yet. Can you re-compile the Debian kernel with kexec (*) and tell me if it works. If so, I'm happy to enable it. (*) If you cannot compile your own kernel, I can prepare one for you to test. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
LUKS overhead (was Re: encrypted root fs on a slug and crypto-modules)
On Sun, Mar 09, 2008 at 11:54:29PM +0100, Anders Lennartsson wrote: As a further note on the subject of this thread, I did manage to install Debian Etch on a fully encrypted USB-stick (1 GB) with two partitions, one for root and one for swap. I used default settings for LUKS encryption which I belive is 128 bits. My impression is that it didn't really affect performance but I have not made any objective tests of this. I built a 2.4.24 armel system on my Thecus N2100 last night, and created a 100GB data partition to test this out. There are a few layers WDC5000KS - md (raid-1) - lvm2 - dm-crypt - ext3 - smb That's two more (lvm2; dm-crypt) than I'm used to on this machine. Copying a few GB onto the device via SMB resulted in kcryptd consuming a lot of CPU for several minutes after each transfer. I'm not sure if it impacted the speeds much, I got ~1.5MB/s which is far from great (100-base-t switch is the limiting factor ethernet wise) but I was getting roughly that (mostly over SSH rather than SMB) beforehand (with the old ABI). The machine didn't boot this morning, but if it does when I get back from work, I'll try and get some more figures on how much of an overhead LUKS proves. I'd expect things to be worse on the slug than the n2100. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LUKS overhead (was Re: encrypted root fs on a slug and crypto-modules)
to throw another number into the round, I got around 2-3 MByte/s on the new ABI. BTW: Does someone know a Mini-PCI crypto accelerator card fit for LUKS/device-mapper? I found some two solutiions the net, but all of them are very secret, that is you need probably a NDA to get more infos like datasheets or in which format the drivers are supplied ... (The best candidate so far would be the NITROX XL NMB Acceleration Boards, http://www.caviumnetworks.com/acceleration_boards_Mini-PCI.htm) signature.asc Description: This is a digitally signed message part
Re: LUKS overhead (was Re: encrypted root fs on a slug and crypto-modules)
Tobias Frost schrieb: to throw another number into the round, I got around 2-3 MByte/s on the new ABI. BTW: Does someone know a Mini-PCI crypto accelerator card fit for LUKS/device-mapper? I found some two solutiions the net, but all of them are very secret, that is you need probably a NDA to get more infos like datasheets or in which format the drivers are supplied ... (The best candidate so far would be the NITROX XL NMB Acceleration Boards, http://www.caviumnetworks.com/acceleration_boards_Mini-PCI.htm) VPN 1411 from Soekris could in theory help: http://soekris.com/vpn1401.htm In theory only, because there is no working driver for Linux 2.6 (there are sources for Linux 2.4 and OpenBSD/FreeBSD). -- Tomasz Chmielewski http://wpkg.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LUKS overhead (was Re: encrypted root fs on a slug and crypto-modules)
Yes, this is the other card I found. However, as written on some list (lost the URL), the 2.4 driver must be buggy as hell and datasheets are subject to NDAs. Boards, http://www.caviumnetworks.com/acceleration_boards_Mini-PCI.htm) VPN 1411 from Soekris could in theory help: http://soekris.com/vpn1401.htm In theory only, because there is no working driver for Linux 2.6 (there are sources for Linux 2.4 and OpenBSD/FreeBSD). -- Tomasz Chmielewski http://wpkg.org signature.asc Description: This is a digitally signed message part
Re: LUKS overhead (was Re: encrypted root fs on a slug and crypto-modules)
Tomasz Chmielewski wrote: Tobias Frost schrieb: to throw another number into the round, I got around 2-3 MByte/s on the new ABI. BTW: Does someone know a Mini-PCI crypto accelerator card fit for LUKS/device-mapper? I found some two solutiions the net, but all of them are very secret, that is you need probably a NDA to get more infos like datasheets or in which format the drivers are supplied ... (The best candidate so far would be the NITROX XL NMB Acceleration Boards, http://www.caviumnetworks.com/acceleration_boards_Mini-PCI.htm) VPN 1411 from Soekris could in theory help: http://soekris.com/vpn1401.htm In theory only, because there is no working driver for Linux 2.6 (there are sources for Linux 2.4 and OpenBSD/FreeBSD). (Slightly) OT, are there any HOWTOs or other general overviews of the crypto-related APIs in the kernel that appear to be getting significant attention the last few releases? It looks like there's more than an accelerator API there lately, I'm trying to get a sense of the motivations for its use--- as well as how to use it, of course. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Kexec on ARM? (Was Re: encrypted root fs on a slug and crypto-modules)
Hello, On Sun, 23 Mar 2008, I said a foolish thing when I wrote: 2. The sysadmin logs in via ssh and runs kexec to boot the real-file system. The key for the real file-system is given as a command line parameter to kexec (after the sysadmin has de-crypted it). I didn't check that kexec is currently not supported on arm under Debian. :-( However, I note that there is supposed to be some support for kexec on arm since 2.6.22 but it is not built-in for the Debian kernels. Is the reason for this documented somewhere? The reason for asking is that I was thinking of using kexec to boot into the armel debian installer without over-writing the existing arm flash on an NSLU2. Is that feasible? Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: encrypted root fs on a slug and crypto-modules
On Tue, 11 Mar 2008 at 07:13:41 +0100, Admir Trakic [EMAIL PROTECTED] wrote: snip Anders, Is there any way to incoporate this hint: http://www.debian-administration.org/articles/579 where usage of serial port would be avoided? ;-) After browsing the howto slightly my guess is that it would work. Busybox is available (in fact it is already in the initrd image) for the arm and so is dropbear. One concern is the available size on the flash in the NSLU2. Dropbear is a bit above 500 kB installed, but not all of it needs to be in the initrd image. I think it would fit. Another concern is the available RAM. I don't know exactly how much memory is required for the the slug to boot and start the apps from RAM. If the swap partition is also encrypted and needs to be unlocked before being used, it may be a problem. If so, a random key for the swap partition might help in that case, because then swap can be initiated before actually entering a LUKS passphrase for the root partition. I will not personally try this at the moment because one of my design goals is to _not_ run a ssh server and further require physical access for entering the passphrase at boot (via a serial port), which I think increases security and is suitable for my application. Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: encrypted root fs on a slug and crypto-modules
Hello, On Sat, 22 Mar 2008, Anders Lennartsson wrote: On Tue, 11 Mar 2008 at 07:13:41 +0100, Admir Trakic [EMAIL PROTECTED] wrote: snip Anders, Is there any way to incoporate this hint: http://www.debian-administration.org/articles/579 where usage of serial port would be avoided? ;-) After browsing the howto slightly my guess is that it would work. Busybox is available (in fact it is already in the initrd image) for the arm and so is dropbear. One concern is the available size on the flash in the NSLU2. Dropbear is a bit above 500 kB installed, but not all of it needs to be in the initrd image. I think it would fit. Here is an alternative approach. 1. Have an un-encrypted small bootable file system which contains the encrypted key for booting the real file-system and has ssh/dropbear installed. This file system is mounted read-only a la Live-CD's. 2. The sysadmin logs in via ssh and runs kexec to boot the real-file system. The key for the real file-system is given as a command line parameter to kexec (after the sysadmin has de-crypted it). Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: encrypted root fs on a slug and crypto-modules
* Anders Lennartsson [EMAIL PROTECTED] [2008-02-24 07:42]: Feb 23 19:03:55 anna[9635]: DEBUG: resolver (crypto-modules): package doesn't exist (ignored) and a short investigation gives that it seems natural because they are not built by the source package: http://packages.debian.org/source/etch/linux-kernel-di-arm-2.6 Thanks for your report. I'll add crypto-modules when we update the installer to 2.6.24. (Which will happen after beta1 is released, which should hopefully be soon.) -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: encrypted root fs on a slug and crypto-modules
On Mon, 2008-02-25, at 07:08:35 +0100, Rick Thomas wrote: I don't know how much load you're going to put on your proposed Kerberos KDC, but the extra CPU load placed on it by encrypting the filesystem may make it unresponsive, given the Slug's not-very-fast CPU. My production environment is a home network with five users. So the kdc load is not very big. Some would say kerberos is overkill there, and I might agree. But it is fun to use kerberos, ldap (on another server) etc. Anyway my goals for a KDC are: * separate computer for security * low power (I'd like to use my carbon footprint and money for other things) * possibility to log in through a console (serial port ok) then sshd would not be needed and remote access more difficult * preferrably low cost * while high availability is good I'm ready to trade that for low power in this application * ethernet I did look at some other single board computers. One idea was to use a SBC like a colibri or similar, mount it inside the chassi of my normal file/ldap/... server, which would provide shelter and electricity, and then have eth and serial/USB console available on the back where all PCI-card connectors are. Such a solution would meet many of the above goals. My experiment with encrypted file system was initiated simply see if it is possible to rasie security even higher, but mainly as a geek thing. If I get it installed and performance is to low, I will fall back to a normal ext3. Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: encrypted root fs on a slug and crypto-modules
I don't know how much load you're going to put on your proposed Kerberos KDC, but the extra CPU load placed on it by encrypting the filesystem may make it unresponsive, given the Slug's not-very-fast CPU. Let us know how it turns out. Rick On Feb 24, 2008, at 1:42 AM, Anders Lennartsson wrote: After using my slug for some time to serve files with Debian installed I thought I'd try using it for a kerberos kdc (tested and works ok) on an encrypted root file system (current experiment). Not much load and file access so this might be ok. But for encryption during a fresh install on the slug, it seems the installer fails to load some modules even though I have inserted an extra media with a swap partition and initiated this partition for swap before attempting to partition and encrypting the fs. In particular three modules are not found Feb 23 19:03:55 anna[9635]: DEBUG: resolver (ext2-modules): package doesn't exist (ignored) Feb 23 19:03:55 anna[9635]: DEBUG: resolver (crypto-modules): package doesn't exist (ignored) Feb 23 19:03:55 anna[9635]: DEBUG: resolver (libnewt0.52): package doesn't exist (ignored) and a short investigation gives that it seems natural because they are not built by the source package: http://packages.debian.org/source/etch/linux-kernel-di-arm-2.6 But is this the only problem or is there some other flaw in my plan on using an extra USB-memory for swap during the install? While the slug is not really up to the task of acting as an interactive workstation I have found that with swap it is surprisingly capable so I thought that it perhaps could do the install given enough swap. Thank you Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
