From owner-linux-crypto@nl.linux.org Thu Feb 1 15:20:59 2001 Received: by humbolt.nl.linux.org id ; Thu, 1 Feb 2001 15:20:22 +0100 Received: from d12lmsgate-2.de.ibm.com ([195.212.91.200]:65155 "EHLO d12lmsgate-2.de.ibm.com") by humbolt.nl.linux.org with ESMTP id ; Thu, 1 Feb 2001 15:19:27 +0100 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id PAA17212 for ; Thu, 1 Feb 2001 15:19:03 +0100 Received: from hobbes.linet (simlingert.vienna.at.ibm.com [9.244.18.73]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id PAA109238 for ; Thu, 1 Feb 2001 15:19:02 +0100 Received: (from dejan@localhost) by hobbes.linet (8.11.1/8.11.1/Debian 8.11.0-6) id f11EIvf01295 for linux-crypto@humbolt.nl.linux.org; Thu, 1 Feb 2001 15:18:57 +0100 Date: Thu, 1 Feb 2001 15:18:57 +0100 From: Dejan Muhamedagic To: linux-crypto@nl.linux.org Subject: Re: segfault on kernel v2.4.0 Message-ID: <20010201151857.A1259@smtp.chello.at> Reply-To: Dejan Muhamedagic Mail-Followup-To: linux-crypto@humbolt.nl.linux.org References: <20010130100332.A1151@smtp.chello.at> <20010130103625.A10170@kuklewicz.MIT.EDU> <20010131010135.A1963@smtp.chello.at> <3A7847B1.93FFB74B@Mutz.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <3A7847B1.93FFB74B@Mutz.com>; from Marc@Mutz.com on Wed, Jan 31, 2001 at 05:13:21PM +0000 Organization: XSoft GmbH Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I've put together a tiny script to check ciphers. On my box only blowfish and rc6 make the losetup segfault. You'll find the script attached. It has not been thoroughly tested but it should be OK. Michael Driscoll reported that he can use the cipher after it has been insmod-ed. It is not the case here: it doesn't matter if I do an insmod first or not, losetup always segfaults when trying to initialize the modules. I also pinpointed the same ioctl where losetup segfaults: lomount.c:362: (void) ioctl (fd, LOOP_SET_STATUS, loopinfo); On Wed, Jan 31, 2001 at 05:13:21PM +0000, Marc Mutz wrote: > Dejan Muhamedagic wrote: > > > > I'll try to clarify: > > > > 1. It is a segfault (in losetup). No oopses. > > > > I had that, too. When trying to losetup in 2.2.18.4pre1, which uses the > same techniques as 2.4.x.y. I was also using Blowfish. Well, I'm not sure whether this is an oops too or not. It does occur in the kernel space, but it doesn't say Oops :) Can somebody clarify on the terminology which should be used? > > 2. The kernel (2.4.0) seems to be OK. loop devices work fine. > > Don't you see the loop device hangs reported by other people? Or do you > have Jens Axboe's loop-3 patch applied? Loop devices work fine here. I have no idea about the patch though. The utils are stock util-linux-2.10o (i.e. from ftp.kernel.org) with the crypto patch applied. > > 4. All ciphers are compiled as modules. > > dto. > > > So, I can switch to IDEA. Is it advisable to use this cipher in a > > production? Any reports about its stability? About the > > international patch? Or should I stay put with the v2.2.x kernels > > for the time being? > > > You should try to use serpent. You can use it free of charge (unlike > IDEA, for which you must pay royalties if used commercially). Thanks. I'll give it a try. > Also, if someone out there could test through the ciphers and check > which of them make losetup segfault, this would be much appreciated. I'm > still stuck w/ 2.2.x, but will reboot into 2.2.18.4pre1 and strace > losetup. Here are my results: kernel: 2.4.0 intpatch: 2.4.0.3 utils: 2.10o libc6: 2.2 (debian v2.2-6) hobbes:~# ./testcrypto start testing aes Password : Password : end testing aes start testing blowfish ./testcrypto: line 14: 2066 Segmentation fault losetup -k 128 -e $crypto $loopdev crypto.fs oopsie start testing dfc Password : Password : end testing dfc start testing idea Password : Password : end testing idea start testing mars Password : Password : end testing mars start testing rc5 Password : Password : end testing rc5 start testing rc6 ./testcrypto: line 14: 2176 Segmentation fault losetup -k 128 -e $crypto $loopdev crypto.fs oopsie start testing serpent Password : Password : end testing serpent start testing twofish Password : Password : end testing twofish I'd advise rebooting after running the script. Cheers. Dejan -- Dejan Muhamedagic mailto:dejan@xsoft.at Xsoft GmbH http://www.xsoft.at Modecenterstr. 14, 1030 Vienna, Austria +43 1 7963636 676 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=testcrypto # LOOPDEVS="0 1 2 3 4 5 6" function getloopdev { for i in $LOOPDEVS; do if losetup /dev/loop$i 2>&1 | grep -qs "No such device"; then echo /dev/loop$i return fi done } function testcr { [ ! -f crypto.fs -o ! -f secret.md5 ] && { echo please create secret.md5 and/or crypto.fs echo secret.md5: data used for testing echo crypto.fs: a container-file for the filesystem return } crypto=$1 loopdev=`getloopdev` [ -z "$loopdev" ] && { echo >&2 sorry, no loop devices available return } echo start testing $crypto losetup -k 128 -e $crypto $loopdev crypto.fs if [ $? -ne 0 ]; then echo oopsie; return fi mke2fs $loopdev >/dev/null 2>&1 mount $loopdev /mnt cp secret.md5 /mnt umount /mnt losetup -d $loopdev if [ $? -ne 0 ]; then echo oopsie return fi losetup -k 128 -e $crypto $loopdev crypto.fs if [ $? -ne 0 ]; then echo oopsie return fi mount $loopdev /mnt cmp secret.md5 /mnt/secret.md5 umount /mnt losetup -d $loopdev echo end testing $crypto } [ ! -f crypto.fs ] && { dd if=/dev/zero of=crypto.fs bs=1k count=256 || { echo sorry, not able to create crypto.fs exit } } testcr aes testcr blowfish testcr dfc testcr idea testcr mars testcr rc5 testcr rc6 testcr serpent testcr twofish --VbJkn9YxBvnuCH5J-- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Feb 8 02:03:40 2001 Received: by humbolt.nl.linux.org id ; Thu, 8 Feb 2001 02:02:52 +0100 Received: from rhinocomputing.com ([161.58.241.147]:10757 "EHLO rhinocomputing.com") by humbolt.nl.linux.org with ESMTP id ; Thu, 8 Feb 2001 02:02:22 +0100 Received: from rhino.thrillseeker.net (root@ci176196-a.grnvle1.sc.home.com [24.4.120.228]) by rhinocomputing.com (8.8.8) id SAA12096; Wed, 7 Feb 2001 18:03:35 -0700 (MST) Received: (from weh@localhost) by rhino.thrillseeker.net (8.11.2/8.11.2/Debian 8.11.2-1) id f18128p13522; Wed, 7 Feb 2001 20:02:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14977.61456.680691.926157@rhino.thrillseeker.net> Date: Wed, 7 Feb 2001 20:02:08 -0500 (EST) From: Billy Harvey To: linux-kernel@vger.kernel.org, linux-crypto@nl.linux.org Subject: Re: 2.4.1-ac5 - The loopback hang saga continues In-Reply-To: Wednesday, 7 February 2001 17:45:13 -0500 References: X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list > It appears that the loopback-hang parasite is alive and well in 2.4.1-ac5. > I've done several tests and I thus provide the following information: > > The bug is independent of UP or SMP configured.. it hung both ways, but the > box itself is UP. > > It appears to hang when internal buffers get filled. The way I see it, copying > files from disk to the loopback device (which is a file on the same disk) > begins to read from the disk. When the internal read buffer is full, the > kernel's queued writes start activating and the data gets copied to the > loopback file. This process repeats over and over, as it should normally. > > Sometimes however, during a read from the disk, it fills up its buffers and > then never makes the accompanying write. In fact, the entire device freezes on > the read. > > I was able to lessen the frequency of hanging by using the -v flag and tapping > ^S and ^Q to temporarily 'pause' copying. This ensures that the read buffer > will never become full to the point where it could cause the hang, and appears > to work -- until it came across the libc.a file. There was no way to pause it > here because nothing is being outputted to the screen while it's copying > libc.a. Unfortunately, it fills the buffer too quick and hangs 100% every time. > The disk is totally nonresponsive at this point, and a hard reset is necessary. > > I hope this helps anyone who is still tracking down the loopback problem. > > Regards, > Byron > > -- > Byron Stanoszek Ph: (330) 644-3059 I can confirm this. The system totally locks when this occurs. I let it sit all night when it did this the last time, and it didn't recover. It requires a large file transfer to usually invoke it. Billy Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Feb 8 03:46:20 2001 Received: by humbolt.nl.linux.org id ; Thu, 8 Feb 2001 03:45:17 +0100 Received: from smtp-rt-14.wanadoo.fr ([193.252.19.224]:29612 "EHLO adansonia.wanadoo.fr") by humbolt.nl.linux.org with ESMTP id ; Thu, 8 Feb 2001 03:44:41 +0100 Received: from antholoma.wanadoo.fr (193.252.19.153) by adansonia.wanadoo.fr; 8 Feb 2001 03:44:40 +0100 Received: from pcg.localdomain (193.249.44.18) by antholoma.wanadoo.fr; 8 Feb 2001 03:44:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14978.2306.408780.856419@pcg.localdomain> Date: Thu, 8 Feb 2001 03:48:34 +0100 From: Pascal Brisset To: Billy Harvey Cc: linux-kernel@vger.kernel.org, linux-crypto@nl.linux.org Subject: Re: 2.4.1-ac5 - The loopback hang saga continues (not me ?) In-Reply-To: <14977.61456.680691.926157@rhino.thrillseeker.net> References: <14977.61456.680691.926157@rhino.thrillseeker.net> X-Mailer: VM 6.87 under Emacs 20.5.1 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list FYI following hints from the linux-crypto mailing-list archives, I am using the following configuration : linux-2.4.0 patch-int-2.4.0.3 http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-1.gz http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-bdev-inc-1.gz util-linux-2.10o Documentation/crypto/util-linux-2.10o.patch I setup an encrypted 2097152000 byte loopback partition and moved 800MB of data there, including a 90MB file. My only problems are: - rc.d/init.d/S01reboot sometimes fails to unmount partitions with loop files on them (this already happened with 2.2.17). - losetup after losetup -d sometimes fails. -- Pascal Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Feb 8 06:05:04 2001 Received: by humbolt.nl.linux.org id ; Thu, 8 Feb 2001 06:04:16 +0100 Received: from viemta06.chello.at ([195.34.133.56]:50337 "EHLO viemta06.chello.at") by humbolt.nl.linux.org with ESMTP id ; Thu, 8 Feb 2001 06:03:52 +0100 Received: from hobbes.linet ([62.178.10.36]) by viemta06.chello.at (InterMail vK.4.03.01.00 201-232-122 license 9caa03a7df1d31c048ffcc0d31ac5855) with ESMTP id <20010208050350.GOCM10358.viemta06@hobbes.linet>; Thu, 8 Feb 2001 06:03:50 +0100 Received: (from dejan@localhost) by hobbes.linet (8.11.1/8.11.1/Debian 8.11.0-6) id f1853oX01723; Thu, 8 Feb 2001 06:03:50 +0100 Date: Thu, 8 Feb 2001 06:03:49 +0100 From: Dejan Muhamedagic To: linux-kernel@vger.kernel.org, linux-crypto@nl.linux.org Subject: Re: 2.4.1-ac5 - The loopback hang saga continues (not me ?) Message-ID: <20010208060349.D1416@smtp.chello.at> Reply-To: Dejan Muhamedagic Mail-Followup-To: linux-kernel@vger.kernel.org, linux-crypto@nl.linux.org References: <14977.61456.680691.926157@rhino.thrillseeker.net> <14978.2306.408780.856419@pcg.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <14978.2306.408780.856419@pcg.localdomain>; from Pascal.Brisset@wanadoo.fr on Thu, Feb 08, 2001 at 03:48:34AM +0100 Organization: XSoft GmbH Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list The same here. I have had no problems with either 2.4.0 or 2.4.1, and I don't even have the Axboe's patch applied. Which makes me wonder where is the problem. I am also using encryption (patch-int-2.4.0.3, idea cipher) and util-linux-2.10o. The container file is not as big, only 256MB with 65MB of data, and the largest file is ~30MB. I had to convert from the blowfish and used dump|restore. There were no problems whatsoever. Dejan On Thu, Feb 08, 2001 at 03:48:34AM +0100, Pascal Brisset wrote: > FYI following hints from the linux-crypto mailing-list archives, I am > using the following configuration : > > linux-2.4.0 > patch-int-2.4.0.3 > http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-1.gz > http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-bdev-inc-1.gz > util-linux-2.10o > Documentation/crypto/util-linux-2.10o.patch > > I setup an encrypted 2097152000 byte loopback partition and moved > 800MB of data there, including a 90MB file. > > My only problems are: > - rc.d/init.d/S01reboot sometimes fails to unmount partitions with > loop files on them (this already happened with 2.2.17). > - losetup after losetup -d sometimes fails. > > -- Pascal > > > Linux-crypto: cryptography in and on the Linux system > Archive: http://mail.nl.linux.org/linux-crypto/ Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Fri Feb 9 01:34:26 2001 Received: by humbolt.nl.linux.org id ; Fri, 9 Feb 2001 01:33:38 +0100 Received: from quechua.inka.de ([212.227.14.2]:12148 "EHLO mail.inka.de") by humbolt.nl.linux.org with ESMTP id ; Fri, 9 Feb 2001 01:33:15 +0100 Received: from bigred.inka.de (uucp@) by mail.inka.de with local-bsmtp id 14R1Ur-0005RH-00; Fri, 9 Feb 2001 01:33:09 +0100 Received: from bigred.inka.de (bigred [172.20.48.42]) by g212.hadiko.de with esmtp id 14R1OK-0005KM-00 for ; Fri, 09 Feb 2001 01:26:24 +0100 To: linux-crypto@nl.linux.org Subject: Endianness issues in Blowfish and IDEA Organization: private Linux site, southern Germany Date: Fri, 09 Feb 2001 01:26:20 +0100 From: Olaf Titz Message-Id: Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list I'm developing a version of CIPE which will use the modular crypto API. From my first interoperability tests, it looks like both the Blowfish and the IDEA modules in the current international kernel get endian-ness in their encryption functions wrong. CIPE historically uses Blowfish in little-endian mode. With that I mean that the plaintext/ciphertext blocks are assumed to consist of two 32-bit units which are fetched and stored in little-endian order.[1] This was a result of a misunderstanding and following coding error on my part, and it has been preserved for compatibility - I now use a Blowfish implementation which gives the choice of little and big endian mode and CIPE uses the little-endian one. This means it can not talk to a regular Blowfish which by the spec is big-endian. But it does talk to the crypto API cipher-blowfish module, so the latter looks to me to be against the spec. Indeed, the blowfish_encrypt routine in cipher-blowfish.c converts its data like this: input is const u8 *in8 this is assigned to u32 *in_blk = (u32 *)in8; the rounds have this assignment yl = *(in_blk++); yr = *(in_blk++); The internal variables yl, yr are supposed to be in native byte order. Because the input is assumed to big endian, here the canonicalization is missing. This is the same error I made with my Blowfish and I suspect/fear it is rather common in other implementations.[2] I know well what the author meant by the comment "This function mustn't respect endianness", because I once ran into the same trap ;-) Nevertheless, it is not correct. The code as it is assumes native byte order for the plaintext/ciphertext blocks and thus will not interoperate between big-endian and little-endian hosts. Another problem appears to exist in the cipher-idea module: the ideaCipher function explicitly swaps bytes in the input for non-little-endian hosts (#ifndef LITTLE_ENDIAN_HOST), iow. canonicalizes to little-endian, which is just the wrong direction. This has to be a coding mistake, as even the comment at the head of the file talks about big-endianness. Other implementations of IDEA (e.g. the one found in OpenSSL, see the file crypto/idea/idea_lcl.h) seem to agree with me[3] that IDEA is assumed big-endian, too. This means the code will interoperate with itself on any host, but not with other IDEA implementations. As long as this is only used for encrypted file systems, interoperability is not that vital, but for networking this will have to be fixed somehow. Olaf [1] or in other words, the Blowfish encrypt routine has an initial and final permutation of the bytes 01234567 -> 32107654. [2] OpenSSL does it right, although the code is extremely non-obvious. [3] It is nowhere explicitly specified, but the reference implementation I adapted for CIPE has ntohs conversions. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Feb 13 01:32:40 2001 Received: by humbolt.nl.linux.org id ; Tue, 13 Feb 2001 01:31:59 +0100 Received: from ns.caldera.de ([212.34.180.1]:61448 "EHLO ns.caldera.de") by humbolt.nl.linux.org with ESMTP id ; Tue, 13 Feb 2001 01:30:39 +0100 Received: (from hch@localhost) by ns.caldera.de (8.9.3/8.9.3) id BAA27343; Tue, 13 Feb 2001 01:29:57 +0100 Date: Tue, 13 Feb 2001 01:29:57 +0100 From: Christoph Hellwig To: Alexander Kjeldaas Cc: linux-crypto@nl.linux.org Subject: [PATCH] cleanups for patch-int-2.4.0-3 Message-ID: <20010213012957.A26936@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hi Astor, this patch moves all the initialization for the kerneli-patch to the newstyle module_{init,exit} version. It does also work for 2.2.18, the most recent Linux 2.2 version, so I don't think it causes branching headaches. Once requiring 2.2.18 one proc support function in cryptoapi.c can also be removed. Christoph -- Of course it doesn't work. We've performed a software upgrade. diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-aes.c linux/crypto/cipher-aes.c --- linux-2.4.2-pre3/crypto/cipher-aes.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-aes.c Sun Feb 11 23:52:37 2001 @@ -424,11 +424,7 @@ struct cipher_implementation aes_cbc; -#ifdef MODULE - int __init init_module(void) -#else - int __init init_rijndael(void) -#endif +static int __init init_rijndael(void) { gen_tabs(); memcpy(&aes_ecb, &rijndael_ecb, sizeof(struct cipher_implementation)); @@ -449,8 +445,7 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_rijndael(void) { #ifdef CONFIG_CIPHER_RIJNDAEL if (unregister_cipher(&rijndael_ecb)) @@ -463,5 +458,6 @@ if (unregister_cipher(&aes_cbc)) printk(KERN_WARNING "Couldn't unregister aes-cbc encryption\n"); } -#endif +module_init(init_rijndael); +module_exit(cleanup_rijndael); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-blowfish.c linux/crypto/cipher-blowfish.c --- linux-2.4.2-pre3/crypto/cipher-blowfish.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-blowfish.c Sun Feb 11 23:53:19 2001 @@ -491,11 +491,7 @@ INIT_CIPHER_OPS(blowfish) }; -#ifdef MODULE -int __init init_module(void) -#else -int __init init_blowfish(void) -#endif +static int __init init_blowfish(void) { if (register_cipher(&blowfish_ecb)) printk(KERN_WARNING "Couldn't register blowfish-ecb encryption\n"); @@ -505,12 +501,13 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_blowfish(void) { if (unregister_cipher(&blowfish_ecb)) printk(KERN_WARNING "Couldn't unregister blowfish-ecb encryption\n"); if (unregister_cipher(&blowfish_cbc)) printk(KERN_WARNING "Couldn't unregister blowfish-cbc encryption\n"); } -#endif + +module_init(init_blowfish); +module_exit(cleanup_blowfish); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-des-ede3.c linux/crypto/cipher-des-ede3.c --- linux-2.4.2-pre3/crypto/cipher-des-ede3.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-des-ede3.c Mon Feb 12 00:42:32 2001 @@ -1303,11 +1303,7 @@ INIT_CIPHER_OPS(des_ede3) }; -#ifdef MODULE -int __init init_module(void) -#else -int __init init_des_ede3(void) -#endif +static int __init init_des_ede3(void) { if (register_cipher(&des_ede3_ecb)) printk(KERN_WARNING "Couldn't register des_ede3-ecb encryption\n"); @@ -1317,12 +1313,13 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_des_ede3(void) { if (unregister_cipher(&des_ede3_ecb)) printk(KERN_WARNING "Couldn't unregister des_ede3-ecb encryption\n"); if (unregister_cipher(&des_ede3_cbc)) printk(KERN_WARNING "Couldn't unregister des_ede3-cbc encryption\n"); } -#endif + +module_init(init_des_ede3); +module_exit(cleanup_des_ede3); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-des.c linux/crypto/cipher-des.c --- linux-2.4.2-pre3/crypto/cipher-des.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-des.c Sun Feb 11 23:54:40 2001 @@ -1216,11 +1216,7 @@ INIT_CIPHER_OPS(des) }; -#ifdef MODULE -int __init init_module(void) -#else -int __init init_des(void) -#endif +static int __init init_des(void) { if (register_cipher(&des_ecb)) printk(KERN_WARNING "Couldn't register des-ecb encryption\n"); @@ -1230,12 +1226,13 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_des(void) { if (unregister_cipher(&des_ecb)) printk(KERN_WARNING "Couldn't unregister des-ecb encryption\n"); if (unregister_cipher(&des_cbc)) printk(KERN_WARNING "Couldn't unregister des-cbc encryption\n"); } -#endif + +module_init(init_des); +module_exit(cleanup_des); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-dfc.c linux/crypto/cipher-dfc.c --- linux-2.4.2-pre3/crypto/cipher-dfc.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-dfc.c Sun Feb 11 23:55:27 2001 @@ -464,11 +464,7 @@ }; -#ifdef MODULE - int __init init_module(void) -#else - int __init init_dfc(void) -#endif +static int __init init_dfc(void) { if (register_cipher(&dfc_ecb)) printk(KERN_WARNING "Couldn't register dfc-ecb encryption\n"); @@ -478,13 +474,13 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_dfc(void) { if (unregister_cipher(&dfc_ecb)) printk(KERN_WARNING "Couldn't unregister dfc-ecb encryption\n"); if (unregister_cipher(&dfc_cbc)) printk(KERN_WARNING "Couldn't unregister dfc-cbc encryption\n"); } -#endif +module_init(init_dfc); +module_exit(cleanup_dfc); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-idea.c linux/crypto/cipher-idea.c --- linux-2.4.2-pre3/crypto/cipher-idea.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-idea.c Sun Feb 11 23:56:16 2001 @@ -391,11 +391,7 @@ INIT_CIPHER_OPS(idea) }; -#ifdef MODULE -int __init init_module(void) -#else -int __init init_idea(void) -#endif +static int __init init_idea(void) { if (register_cipher(&idea_ecb)) printk(KERN_WARNING "Couldn't register idea-ecb encryption\n"); @@ -404,12 +400,13 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_idea(void) { if (unregister_cipher(&idea_ecb)) printk(KERN_WARNING "Couldn't unregister idea-ecb encryption\n"); if (unregister_cipher(&idea_cbc)) printk(KERN_WARNING "Couldn't unregister idea-cbc encryption\n"); } -#endif + +module_init(init_idea); +module_exit(cleanup_idea); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-mars.c linux/crypto/cipher-mars.c --- linux-2.4.2-pre3/crypto/cipher-mars.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-mars.c Sun Feb 11 23:57:12 2001 @@ -454,11 +454,7 @@ }; -#ifdef MODULE - int __init init_module(void) -#else - int __init init_mars(void) -#endif +static int __init init_mars(void) { if (register_cipher(&mars_ecb)) printk(KERN_WARNING "Couldn't register mars-ecb encryption\n"); @@ -468,12 +464,13 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_mars(void) { if (unregister_cipher(&mars_ecb)) printk(KERN_WARNING "Couldn't unregister mars-ecb encryption\n"); if (unregister_cipher(&mars_cbc)) printk(KERN_WARNING "Couldn't unregister mars-cbc encryption\n"); } -#endif + +module_init(init_mars); +module_exit(cleanup_mars); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-rc5.c linux/crypto/cipher-rc5.c --- linux-2.4.2-pre3/crypto/cipher-rc5.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-rc5.c Sun Feb 11 23:58:00 2001 @@ -209,11 +209,7 @@ }; -#ifdef MODULE -int __init init_module(void) -#else -int __init init_rc5(void) -#endif +static int __init init_rc5(void) { if (register_cipher(&rc5_ecb)) printk(KERN_WARNING "Couldn't register RC5-ecb encryption\n"); @@ -223,12 +219,13 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_rc5(void) { if (unregister_cipher(&rc5_ecb)) printk(KERN_WARNING "Couldn't unregister RC5_ecb encryption\n"); if (unregister_cipher(&rc5_cbc)) printk(KERN_WARNING "Couldn't unregister RC5-cbc encryption\n"); } -#endif + +module_init(init_rc5); +module_exit(cleanup_rc5); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-rc6.c linux/crypto/cipher-rc6.c --- linux-2.4.2-pre3/crypto/cipher-rc6.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-rc6.c Sun Feb 11 23:58:45 2001 @@ -193,11 +193,7 @@ INIT_CIPHER_OPS(rc6) }; -#ifdef MODULE - int __init init_module(void) -#else - int __init init_rc6(void) -#endif +static int __init init_rc6(void) { if (register_cipher(&rc6_ecb)) printk(KERN_WARNING "Couldn't register rc6-ecb encryption\n"); @@ -207,12 +203,13 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_rc6(void) { if (unregister_cipher(&rc6_ecb)) printk(KERN_WARNING "Couldn't unregister rc6-ecb encryption\n"); if (unregister_cipher(&rc6_cbc)) printk(KERN_WARNING "Couldn't unregister rc6-cbc encryption\n"); } -#endif + +module_init(init_rc6); +module_exit(cleanup_rc6); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-serpent.c linux/crypto/cipher-serpent.c --- linux-2.4.2-pre3/crypto/cipher-serpent.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-serpent.c Sun Feb 11 23:59:27 2001 @@ -1027,11 +1027,7 @@ INIT_CIPHER_OPS(serpent) }; -#ifdef MODULE -int __init init_module(void) -#else -int __init init_serpent(void) -#endif +static int __init init_serpent(void) { if (register_cipher(&serpent_ecb)) printk(KERN_WARNING "Couldn't register serpent-ecb encryption\n"); @@ -1041,13 +1037,13 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit cleanup_serpent(void) { if (unregister_cipher(&serpent_ecb)) printk(KERN_WARNING "Couldn't unregister serpent-ecb encryption\n"); if (unregister_cipher(&serpent_cbc)) printk(KERN_WARNING "Couldn't unregister serpent-cbc encryption\n"); } -#endif +module_init(init_serpent); +module_exit(cleanup_serpent); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cipher-twofish.c linux/crypto/cipher-twofish.c --- linux-2.4.2-pre3/crypto/cipher-twofish.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cipher-twofish.c Mon Feb 12 00:00:55 2001 @@ -442,11 +442,7 @@ INIT_CIPHER_OPS(twofish) }; -#ifdef MODULE - int __init init_module(void) -#else - int __init init_twofish(void) -#endif +static int __init init_twofish(void) { if (register_cipher(&twofish_ecb)) printk(KERN_WARNING "Couldn't register twofish-ecb encryption\n"); @@ -456,8 +452,7 @@ return 0; } -#ifdef MODULE -void cleanup_module(void) +static void cleanup_twofish(void) { if (unregister_cipher(&twofish_ecb)) printk(KERN_WARNING "Couldn't unregister twofish-ecb encryption\n"); @@ -465,4 +460,5 @@ printk(KERN_WARNING "Couldn't unregister twofish-cbc encryption\n"); } -#endif +module_init(init_twofish); +module_exit(cleanup_twofish); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/cryptoapi.c linux/crypto/cryptoapi.c --- linux-2.4.2-pre3/crypto/cryptoapi.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/cryptoapi.c Mon Feb 12 00:05:06 2001 @@ -6,9 +6,6 @@ * 2000-10-15 Harald Welte * - ported to Linux 2.4 * - * This module is still using old 2.2 module_init/exit semantics for - * backwards compatibility - HW - * * Copyright 1998 by Alexander Kjeldaas. Redistribution of this file * is permitted under the GNU Public License. */ @@ -58,8 +55,8 @@ int count, int *eof, void *data); #endif -LIST_HEAD(ciphers); -LIST_HEAD(digests); +static LIST_HEAD(ciphers); +static LIST_HEAD(digests); static struct transform_group transforms[MAX_TRANSFORM] = { /* digest */ @@ -76,40 +73,7 @@ } }; -#ifdef CONFIG_PROC_FS -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18) -/* We have to emulate the 2.4 function proc_mkdir, because it is not - * present in 2.2 - HW */ -static struct proc_dir_entry * -proc_mkdir(const char *name, struct proc_dir_entry *parent) -{ - struct proc_dir_entry *ent = NULL; - const char *fn = name; - int len; - - if (!parent) - parent = &proc_root; - len = strlen(fn); - - ent = kmalloc(sizeof(struct proc_dir_entry) + len + 1, GFP_KERNEL); - if (!ent) - goto out; - memset(ent, 0, sizeof(struct proc_dir_entry)); - memcpy(((char *) ent) + sizeof(*ent), fn, len + 1); - ent->name = ((char *) ent) + sizeof(*ent); - ent->namelen = len; - ent->ops = NULL; - ent->nlink = 2; - ent->mode = S_IFDIR | S_IRUGO | S_IXUGO; - - proc_register(parent, ent); - -out: - return ent; -} -#endif - -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0) +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0) && defined(CONFIG_PROC_FS) static struct proc_dir_entry * create_proc_read_entry(const char *name, mode_t mode, struct proc_dir_entry *base, @@ -124,7 +88,6 @@ } #endif -#endif /** @@ -459,11 +422,8 @@ #endif -#ifdef MODULE -int __init init_module(void) -#else -int __init cryptoapi_init(void) -#endif +static int __init +init_cryptoapi(void) { int i; @@ -475,52 +435,11 @@ proc_mkdir(transforms[i].tg_name, proc_crypto); } #endif - -#ifdef CONFIG_DIGEST_MD5 - init_md5(); -#endif -#ifdef CONFIG_DIGEST_SHA1 - init_sha1(); -#endif -#ifdef CONFIG_CIPHER_AES - init_rijndael(); -#endif -#ifdef CONFIG_CIPHER_TWOFISH - init_twofish(); -#endif -#ifdef CONFIG_CIPHER_SERPENT - init_serpent(); -#endif -#ifdef CONFIG_CIPHER_RC5 - init_rc5(); -#endif -#ifdef CONFIG_CIPHER_RC6 - init_rc6(); -#endif -#ifdef CONFIG_CIPHER_MARS - init_mars(); -#endif -#ifdef CONFIG_CIPHER_DFC - init_dfc(); -#endif -#ifdef CONFIG_CIPHER_BLOWFISH - init_blowfish(); -#endif -#ifdef CONFIG_CIPHER_IDEA - init_idea(); -#endif -#ifdef CONFIG_CIPHER_DES - init_des(); -#endif -#ifdef CONFIG_CIPHER_DES_EDE3 - init_des_ede3(); -#endif - return 0; } -#ifdef MODULE -void cleanup_module(void) +static void __exit +cleanup_cryptoapi(void) { int i; @@ -533,7 +452,9 @@ #endif } -#endif + +module_init(init_cryptoapi); +module_exit(cleanup_cryptoapi); EXPORT_SYMBOL(find_transform_by_name); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/digest-md5.c linux/crypto/digest-md5.c --- linux-2.4.2-pre3/crypto/digest-md5.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/digest-md5.c Mon Feb 12 00:01:42 2001 @@ -85,20 +85,17 @@ INIT_DIGEST_OPS(md5) }; -#ifdef MODULE -#define init_md5 init_module -#endif - -int __init init_md5 (void) +static int __init init_md5 (void) { printk ("MD5 Message Digest Algorithm (c) RSA Systems, Inc\n"); register_digest (&md5); return 0; } -#ifdef MODULE -void cleanup_module (void) +static void __exit cleanup_md5 (void) { unregister_digest (&md5); } -#endif + +module_init(init_md5); +module_exit(cleanup_md5); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/crypto/digest-sha1.c linux/crypto/digest-sha1.c --- linux-2.4.2-pre3/crypto/digest-sha1.c Mon Feb 12 00:06:37 2001 +++ linux/crypto/digest-sha1.c Mon Feb 12 00:02:24 2001 @@ -84,19 +84,16 @@ INIT_DIGEST_OPS(sha1) }; -#ifdef MODULE -#define init_sha1 init_module -#endif - -int __init init_sha1 (void) +static int __init init_sha1 (void) { register_digest (&sha1); return 0; } -#ifdef MODULE -void cleanup_module (void) +static void __exit cleanup_sha1 (void) { unregister_digest (&sha1); } -#endif + +module_init(init_sha1); +module_exit(cleanup_sha1); diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/include/linux/crypto.h linux/include/linux/crypto.h --- linux-2.4.2-pre3/include/linux/crypto.h Mon Feb 12 00:06:37 2001 +++ linux/include/linux/crypto.h Mon Feb 12 00:05:59 2001 @@ -249,31 +249,6 @@ int unregister_cipher(struct cipher_implementation *ci); int unregister_digest(struct digest_implementation *ci); -/* System initialization */ -extern int cryptoapi_init(void); - -/* Cipher implementations */ - -extern int init_cast256(void); -extern int init_crypton(void); -extern int init_serpent(void); -extern int init_mars(void); -extern int init_rc5(void); -extern int init_rc6(void); -extern int init_dfc(void); -extern int init_rijndael(void); -extern int init_blowfish(void); -extern int init_twofish(void); -extern int init_idea(void); -extern int init_des(void); -extern int init_des_ede3(void); - - -/* Digest implementations */ - -extern int init_md5(void); -extern int init_sha1(void); - /* Utility macros */ diff -uNr --exclude-from=dontdiff linux-2.4.2-pre3/init/main.c linux/init/main.c --- linux-2.4.2-pre3/init/main.c Mon Feb 12 00:06:37 2001 +++ linux/init/main.c Sun Feb 11 23:51:29 2001 @@ -67,10 +67,6 @@ #include #endif -#ifdef CONFIG_CRYPTO -#include -#endif - /* * Versions of gcc older than that listed below may actually compile * and link okay, but the end product can have subtle run time bugs. @@ -730,11 +726,6 @@ filesystem_setup(); -#ifdef CONFIG_CRYPTO - /* .. crypto .. */ - cryptoapi_init(); -#endif - #ifdef CONFIG_IRDA irda_device_init(); /* Must be done after protocol initialization */ #endif Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Feb 19 18:08:03 2001 Received: by humbolt.nl.linux.org id ; Mon, 19 Feb 2001 18:07:12 +0100 Received: from [194.46.8.33] ([194.46.8.33]:5638 "EHLO angusbay.vnl.com") by humbolt.nl.linux.org with ESMTP id ; Mon, 19 Feb 2001 18:06:52 +0100 Received: from amon by angusbay.vnl.com with local (Exim 3.20 #1) id 14Utmk-00048u-00 (Debian); Mon, 19 Feb 2001 17:07:38 +0000 Date: Mon, 19 Feb 2001 17:07:37 +0000 From: Dale Amon To: linux-crypto@nl.linux.org Subject: timeline for 2.4.1 patches? Message-ID: <20010219170736.E30296@vnl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-Operating-System: Linux, the choice of a GNU generation Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Just curious. I'd like to use reiserfs on a large file system I have to set up soon. -- ------------------------------------------------------ Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste. Belfast, Northern Ireland ------------------------------------------------------ Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Mon Feb 19 22:42:32 2001 Received: by humbolt.nl.linux.org id ; Mon, 19 Feb 2001 22:41:51 +0100 Received: from p3E9BCE9E.dip.t-dialin.net ([62.155.206.158]:62103 "EHLO bierkasten.org") by humbolt.nl.linux.org with ESMTP id ; Mon, 19 Feb 2001 22:41:30 +0100 Received: from pc-runner (pc-runner.sign.lan [192.168.1.1]) by bierkasten.org (Postfix) with SMTP id 52CAA1E06 for ; Mon, 19 Feb 2001 22:41:28 +0100 (MET) Date: Mon, 19 Feb 2001 22:41:28 +0100 From: pacman To: linux-crypto@nl.linux.org Subject: max size of a partition Message-Id: <20010219224128.4f4c7677.pacman@bierkasten.org> X-Mailer: Sylpheed version 0.4.61 (GTK+ 1.2.8; Linux 2.4.0; i686) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list hi, i have problems with the encryption of my partition (28gb). i always get a kernel panic while i create. if the partition has a size of 2gb it works perfectly. so is there a limit of the size? and if, is there a workaround or a solution to solve this problem. --- Sincerly Michael Walle In den Rohrwiesen 1a 66440 Blieskastel Deutschland pacman@bierkasten.org http://pacman.yi.org --- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Feb 20 02:56:53 2001 Received: by humbolt.nl.linux.org id ; Tue, 20 Feb 2001 02:56:22 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:1965 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Tue, 20 Feb 2001 02:56:05 +0100 Received: from Mutz.com (ppp36-245.hrz.uni-bielefeld.de [129.70.36.245]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G9100D3M9DE9N@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Tue, 20 Feb 2001 02:56:03 +0100 (MET) Date: Tue, 20 Feb 2001 01:48:07 +0000 From: Marc Mutz Subject: Re: max size of a partition To: pacman Cc: linux-crypto@nl.linux.org Message-id: <3A91CCD7.A8059C02@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18-0001 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20010219224128.4f4c7677.pacman@bierkasten.org> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list pacman wrote: > > hi, > i have problems with the encryption of my partition (28gb). i always get a kernel panic while i create. if the partition has a size of 2gb it works perfectly. so is there a limit of the size? and if, is there a workaround or a solution to solve this problem. > What kernel version? Please describe your setup more _detailed_ (exact commands, entries in fstab, you know...) Marc -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Feb 20 21:02:01 2001 Received: by humbolt.nl.linux.org id ; Tue, 20 Feb 2001 20:59:12 +0100 Received: from pop.gmx.net ([194.221.183.20]:47295 "HELO mail.gmx.net") by humbolt.nl.linux.org with SMTP id ; Tue, 20 Feb 2001 20:50:57 +0100 Received: (qmail 27403 invoked by uid 0); 20 Feb 2001 15:50:47 -0000 Received: from p3ee01d5c.dip.t-dialin.net (HELO pc-runner) (62.224.29.92) by mail.gmx.net (mp006-rz3) with SMTP; 20 Feb 2001 15:50:47 -0000 Date: Tue, 20 Feb 2001 16:50:47 +0100 From: Pacman To: Marc Mutz Cc: linux-crypto@nl.linux.org Subject: Re: max size of a partition Message-Id: <20010220165047.38734690.cia_pacman@gmx.net> In-Reply-To: <3A91CCD7.A8059C02@Mutz.com> References: <20010219224128.4f4c7677.pacman@bierkasten.org> <3A91CCD7.A8059C02@Mutz.com> X-Mailer: Sylpheed version 0.4.61 (GTK+ 1.2.8; Linux 2.4.0; i686) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Tue__20_Feb_2001_16:50:47_+0100_081cfd18" Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list This is a multi-part message in MIME format. --Multipart_Tue__20_Feb_2001_16:50:47_+0100_081cfd18 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit i tried kernel ver 2.4.0 with reiserfs patch (3.6.25), -ac12, 2.4.1, -ac18 all with crypto patch 2.4.0.3. /etc/fstab: /dev/hda8 /mnt/crypto ext2 defaults,noauto,loop,encryption=aes,user 0 0 what i did: losetup (patched ver. s) losetup -e aes /dev/loop0 /dev/hda8 mke2fs /dev/loop0 ==> kernel panic if hda > 2gb kernel config ist attached. -- Sincerly Michael Walle In den Rohrwiesen 1a 66440 Blieskastel Deutschland pacman@bierkasten.org http://pacman.yi.org --- On Tue, 20 Feb 2001 01:48:07 +0000 Marc Mutz wrote: > pacman wrote: > > > > hi, > > i have problems with the encryption of my partition (28gb). i always get a kernel panic while i create. if the partition has a size of 2gb it works perfectly. so is there a limit of the size? and if, is there a workaround or a solution to solve this problem. > > > > > What kernel version? > Please describe your setup more _detailed_ (exact commands, entries in > fstab, you know...) > > Marc > > -- > Marc Mutz http://EncryptionHOWTO.sourceforge.net/ > University of Bielefeld, Dep. of Mathematics / Dep. of Physics > > PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) > > > Linux-crypto: cryptography in and on the Linux system > Archive: http://mail.nl.linux.org/linux-crypto/ --Multipart_Tue__20_Feb_2001_16:50:47_+0100_081cfd18 Content-Type: application/octet-stream; name="kernelconfig" Content-Disposition: attachment; filename="kernelconfig" Content-Transfer-Encoding: base64 IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGJ5IG1ha2UgbWVudWNvbmZpZzogZG9uJ3QgZWRp dAojCkNPTkZJR19YODY9eQpDT05GSUdfSVNBPXkKIyBDT05GSUdfU0JVUyBpcyBub3Qgc2V0CkNP TkZJR19VSUQxNj15CgojCiMgQ29kZSBtYXR1cml0eSBsZXZlbCBvcHRpb25zCiMKQ09ORklHX0VY UEVSSU1FTlRBTD15CgojCiMgTG9hZGFibGUgbW9kdWxlIHN1cHBvcnQKIwpDT05GSUdfTU9EVUxF Uz15CkNPTkZJR19NT0RWRVJTSU9OUz15CiMgQ09ORklHX0tNT0QgaXMgbm90IHNldAoKIwojIFBy b2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcwojCiMgQ09ORklHX00zODYgaXMgbm90IHNldAojIENP TkZJR19NNDg2IGlzIG5vdCBzZXQKIyBDT05GSUdfTTU4NiBpcyBub3Qgc2V0CiMgQ09ORklHX001 ODZUU0MgaXMgbm90IHNldAojIENPTkZJR19NNTg2TU1YIGlzIG5vdCBzZXQKIyBDT05GSUdfTTY4 NiBpcyBub3Qgc2V0CkNPTkZJR19NNjg2RlhTUj15CiMgQ09ORklHX01QRU5USVVNNCBpcyBub3Qg c2V0CiMgQ09ORklHX01LNiBpcyBub3Qgc2V0CiMgQ09ORklHX01LNyBpcyBub3Qgc2V0CiMgQ09O RklHX01DUlVTT0UgaXMgbm90IHNldAojIENPTkZJR19NV0lOQ0hJUEM2IGlzIG5vdCBzZXQKIyBD T05GSUdfTVdJTkNISVAyIGlzIG5vdCBzZXQKIyBDT05GSUdfTVdJTkNISVAzRCBpcyBub3Qgc2V0 CkNPTkZJR19YODZfV1BfV09SS1NfT0s9eQpDT05GSUdfWDg2X0lOVkxQRz15CkNPTkZJR19YODZf Q01QWENIRz15CkNPTkZJR19YODZfQlNXQVA9eQpDT05GSUdfWDg2X1BPUEFEX09LPXkKQ09ORklH X1g4Nl9MMV9DQUNIRV9TSElGVD01CkNPTkZJR19YODZfVFNDPXkKQ09ORklHX1g4Nl9HT09EX0FQ SUM9eQpDT05GSUdfWDg2X1BHRT15CkNPTkZJR19YODZfVVNFX1BQUk9fQ0hFQ0tTVU09eQpDT05G SUdfWDg2X0ZYU1I9eQpDT05GSUdfWDg2X1hNTT15CiMgQ09ORklHX1RPU0hJQkEgaXMgbm90IHNl dAojIENPTkZJR19NSUNST0NPREUgaXMgbm90IHNldAojIENPTkZJR19YODZfTVNSIGlzIG5vdCBz ZXQKIyBDT05GSUdfWDg2X0NQVUlEIGlzIG5vdCBzZXQKQ09ORklHX05PSElHSE1FTT15CiMgQ09O RklHX0hJR0hNRU00RyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJR0hNRU02NEcgaXMgbm90IHNldApD T05GSUdfTVRSUj15CiMgQ09ORklHX1NNUCBpcyBub3Qgc2V0CkNPTkZJR19YODZfVVBfSU9BUElD PXkKQ09ORklHX1g4Nl9JT19BUElDPXkKQ09ORklHX1g4Nl9MT0NBTF9BUElDPXkKCiMKIyBHZW5l cmFsIHNldHVwCiMKQ09ORklHX05FVD15CiMgQ09ORklHX1ZJU1dTIGlzIG5vdCBzZXQKQ09ORklH X1BDST15CiMgQ09ORklHX1BDSV9HT0JJT1MgaXMgbm90IHNldApDT05GSUdfUENJX0dPRElSRUNU PXkKIyBDT05GSUdfUENJX0dPQU5ZIGlzIG5vdCBzZXQKQ09ORklHX1BDSV9ESVJFQ1Q9eQpDT05G SUdfUENJX05BTUVTPXkKIyBDT05GSUdfRUlTQSBpcyBub3Qgc2V0CiMgQ09ORklHX01DQSBpcyBu b3Qgc2V0CkNPTkZJR19IT1RQTFVHPXkKCiMKIyBQQ01DSUEvQ2FyZEJ1cyBzdXBwb3J0CiMKIyBD T05GSUdfUENNQ0lBIGlzIG5vdCBzZXQKQ09ORklHX1NZU1ZJUEM9eQojIENPTkZJR19CU0RfUFJP Q0VTU19BQ0NUIGlzIG5vdCBzZXQKQ09ORklHX1NZU0NUTD15CkNPTkZJR19LQ09SRV9FTEY9eQoj IENPTkZJR19LQ09SRV9BT1VUIGlzIG5vdCBzZXQKQ09ORklHX0JJTkZNVF9BT1VUPXkKQ09ORklH X0JJTkZNVF9FTEY9eQpDT05GSUdfQklORk1UX01JU0M9eQpDT05GSUdfUE09eQojIENPTkZJR19B Q1BJIGlzIG5vdCBzZXQKQ09ORklHX0FQTT15CiMgQ09ORklHX0FQTV9JR05PUkVfVVNFUl9TVVNQ RU5EIGlzIG5vdCBzZXQKQ09ORklHX0FQTV9ET19FTkFCTEU9eQpDT05GSUdfQVBNX0NQVV9JRExF PXkKIyBDT05GSUdfQVBNX0RJU1BMQVlfQkxBTksgaXMgbm90IHNldAojIENPTkZJR19BUE1fUlRD X0lTX0dNVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FQTV9BTExPV19JTlRTIGlzIG5vdCBzZXQKIyBD T05GSUdfQVBNX1JFQUxfTU9ERV9QT1dFUl9PRkYgaXMgbm90IHNldAoKIwojIE1lbW9yeSBUZWNo bm9sb2d5IERldmljZXMgKE1URCkKIwojIENPTkZJR19NVEQgaXMgbm90IHNldAoKIwojIFBhcmFs bGVsIHBvcnQgc3VwcG9ydAojCkNPTkZJR19QQVJQT1JUPXkKQ09ORklHX1BBUlBPUlRfUEM9eQpD T05GSUdfUEFSUE9SVF9QQ19GSUZPPXkKIyBDT05GSUdfUEFSUE9SVF9QQ19TVVBFUklPIGlzIG5v dCBzZXQKIyBDT05GSUdfUEFSUE9SVF9BTUlHQSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBUlBPUlRf TUZDMyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBUlBPUlRfQVRBUkkgaXMgbm90IHNldAojIENPTkZJ R19QQVJQT1JUX1NVTkJQUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBUlBPUlRfT1RIRVIgaXMgbm90 IHNldAojIENPTkZJR19QQVJQT1JUXzEyODQgaXMgbm90IHNldAoKIwojIENyeXB0byBvcHRpb25z CiMKQ09ORklHX0NSWVBUTz15CkNPTkZJR19DSVBIRVJTPXkKQ09ORklHX0NJUEhFUl9BRVM9eQoj IENPTkZJR19DSVBIRVJfUklKTkRBRUwgaXMgbm90IHNldApDT05GSUdfQ0lQSEVSX1RXT0ZJU0g9 eQojIENPTkZJR19DSVBIRVJfTUFSUyBpcyBub3Qgc2V0CkNPTkZJR19DSVBIRVJfUkM2PXkKIyBD T05GSUdfQ0lQSEVSX1NFUlBFTlQgaXMgbm90IHNldAojIENPTkZJR19DSVBIRVJfREZDIGlzIG5v dCBzZXQKQ09ORklHX0NJUEhFUl9CTE9XRklTSD15CiMgQ09ORklHX0NJUEhFUl9JREVBIGlzIG5v dCBzZXQKIyBDT05GSUdfQ0lQSEVSX1JDNSBpcyBub3Qgc2V0CkNPTkZJR19DSVBIRVJfREVTX0VE RTM9eQojIENPTkZJR19DSVBIRVJfREVTIGlzIG5vdCBzZXQKIyBDT05GSUdfRElHRVNUIGlzIG5v dCBzZXQKCiMKIyBQbHVnIGFuZCBQbGF5IGNvbmZpZ3VyYXRpb24KIwojIENPTkZJR19QTlAgaXMg bm90IHNldAojIENPTkZJR19JU0FQTlAgaXMgbm90IHNldAoKIwojIEJsb2NrIGRldmljZXMKIwpD T05GSUdfQkxLX0RFVl9GRD15CiMgQ09ORklHX0JMS19ERVZfWEQgaXMgbm90IHNldAojIENPTkZJ R19QQVJJREUgaXMgbm90IHNldAojIENPTkZJR19CTEtfQ1BRX0RBIGlzIG5vdCBzZXQKIyBDT05G SUdfQkxLX0NQUV9DSVNTX0RBIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9EQUM5NjAgaXMg bm90IHNldApDT05GSUdfTE9PUF9ERVA9eQpDT05GSUdfQkxLX0RFVl9MT09QPXkKQ09ORklHX0JM S19ERVZfTE9PUF9HRU49eQojIENPTkZJR19CTEtfREVWX05CRCBpcyBub3Qgc2V0CiMgQ09ORklH X0JMS19ERVZfUkFNIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9JTklUUkQgaXMgbm90IHNl dAoKIwojIE11bHRpLWRldmljZSBzdXBwb3J0IChSQUlEIGFuZCBMVk0pCiMKIyBDT05GSUdfTUQg aXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX01EIGlzIG5vdCBzZXQKIyBDT05GSUdfTURfTElO RUFSIGlzIG5vdCBzZXQKIyBDT05GSUdfTURfUkFJRDAgaXMgbm90IHNldAojIENPTkZJR19NRF9S QUlEMSBpcyBub3Qgc2V0CiMgQ09ORklHX01EX1JBSUQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfQkxL X0RFVl9MVk0gaXMgbm90IHNldAojIENPTkZJR19MVk1fUFJPQ19GUyBpcyBub3Qgc2V0CgojCiMg TmV0d29ya2luZyBvcHRpb25zCiMKQ09ORklHX1BBQ0tFVD15CiMgQ09ORklHX1BBQ0tFVF9NTUFQ IGlzIG5vdCBzZXQKQ09ORklHX05FVExJTks9eQpDT05GSUdfUlRORVRMSU5LPXkKIyBDT05GSUdf TkVUTElOS19ERVYgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVIgaXMgbm90IHNldAojIENP TkZJR19GSUxURVIgaXMgbm90IHNldApDT05GSUdfVU5JWD15CkNPTkZJR19JTkVUPXkKQ09ORklH X0lQX01VTFRJQ0FTVD15CiMgQ09ORklHX0lQX0FEVkFOQ0VEX1JPVVRFUiBpcyBub3Qgc2V0CiMg Q09ORklHX0lQX1BOUCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9JUElQIGlzIG5vdCBzZXQKIyBD T05GSUdfTkVUX0lQR1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTVJPVVRFIGlzIG5vdCBzZXQK IyBDT05GSUdfQVJQRCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfRUNOIGlzIG5vdCBzZXQKIyBD T05GSUdfU1lOX0NPT0tJRVMgaXMgbm90IHNldApDT05GSUdfSVBWNj15CkNPTkZJR19JUFY2X0VV STY0PXkKQ09ORklHX0lQVjZfTk9fUEI9eQojIENPTkZJR19LSFRUUEQgaXMgbm90IHNldAojIENP TkZJR19BVE0gaXMgbm90IHNldAojIENPTkZJR19JUFggaXMgbm90IHNldAojIENPTkZJR19BVEFM SyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQ05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0JSSURHRSBp cyBub3Qgc2V0CiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0CiMgQ09ORklHX0xBUEIgaXMgbm90IHNl dAojIENPTkZJR19MTEMgaXMgbm90IHNldAojIENPTkZJR19ORVRfRElWRVJUIGlzIG5vdCBzZXQK IyBDT05GSUdfRUNPTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfV0FOX1JPVVRFUiBpcyBub3Qgc2V0 CiMgQ09ORklHX05FVF9GQVNUUk9VVEUgaXMgbm90IHNldAojIENPTkZJR19ORVRfSFdfRkxPV0NP TlRST0wgaXMgbm90IHNldAoKIwojIFFvUyBhbmQvb3IgZmFpciBxdWV1ZWluZwojCiMgQ09ORklH X05FVF9TQ0hFRCBpcyBub3Qgc2V0CgojCiMgVGVsZXBob255IFN1cHBvcnQKIwojIENPTkZJR19Q SE9ORSBpcyBub3Qgc2V0CiMgQ09ORklHX1BIT05FX0lYSiBpcyBub3Qgc2V0CgojCiMgQVRBL0lE RS9NRk0vUkxMIHN1cHBvcnQKIwpDT05GSUdfSURFPXkKCiMKIyBJREUsIEFUQSBhbmQgQVRBUEkg QmxvY2sgZGV2aWNlcwojCkNPTkZJR19CTEtfREVWX0lERT15CiMgQ09ORklHX0JMS19ERVZfSERf SURFIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBub3Qgc2V0CkNPTkZJR19CTEtf REVWX0lERURJU0s9eQojIENPTkZJR19JREVESVNLX01VTFRJX01PREUgaXMgbm90IHNldAojIENP TkZJR19CTEtfREVWX0lERURJU0tfVkVORE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9J REVESVNLX0ZVSklUU1UgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0lERURJU0tfSUJNIGlz IG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9JREVESVNLX01BWFRPUiBpcyBub3Qgc2V0CiMgQ09O RklHX0JMS19ERVZfSURFRElTS19RVUFOVFVNIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9J REVESVNLX1NFQUdBVEUgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0lERURJU0tfV0QgaXMg bm90IHNldAojIENPTkZJR19CTEtfREVWX0NPTU1FUklBTCBpcyBub3Qgc2V0CiMgQ09ORklHX0JM S19ERVZfVElWTyBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfSURFQ1MgaXMgbm90IHNldApD T05GSUdfQkxLX0RFVl9JREVDRD15CiMgQ09ORklHX0JMS19ERVZfSURFVEFQRSBpcyBub3Qgc2V0 CiMgQ09ORklHX0JMS19ERVZfSURFRkxPUFBZIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9J REVTQ1NJIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9DTUQ2NDAgaXMgbm90IHNldAojIENP TkZJR19CTEtfREVWX0NNRDY0MF9FTkhBTkNFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZf SVNBUE5QIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9SWjEwMDAgaXMgbm90IHNldApDT05G SUdfQkxLX0RFVl9JREVQQ0k9eQpDT05GSUdfSURFUENJX1NIQVJFX0lSUT15CkNPTkZJR19CTEtf REVWX0lERURNQV9QQ0k9eQojIENPTkZJR19CTEtfREVWX09GRkJPQVJEIGlzIG5vdCBzZXQKQ09O RklHX0lERURNQV9QQ0lfQVVUTz15CkNPTkZJR19CTEtfREVWX0lERURNQT15CiMgQ09ORklHX0lE RURNQV9QQ0lfV0lQIGlzIG5vdCBzZXQKIyBDT05GSUdfSURFRE1BX05FV19EUklWRV9MSVNUSU5H UyBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfQUVDNjJYWCBpcyBub3Qgc2V0CiMgQ09ORklH X0FFQzYyWFhfVFVOSU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9BTEkxNVgzIGlzIG5v dCBzZXQKIyBDT05GSUdfV0RDX0FMSTE1WDMgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0FN RDc0MDkgaXMgbm90IHNldAojIENPTkZJR19BTUQ3NDA5X09WRVJSSURFIGlzIG5vdCBzZXQKIyBD T05GSUdfQkxLX0RFVl9DTUQ2NFggaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0NZODJDNjkz IGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9DUzU1MzAgaXMgbm90IHNldAojIENPTkZJR19C TEtfREVWX0hQVDM0WCBpcyBub3Qgc2V0CiMgQ09ORklHX0hQVDM0WF9BVVRPRE1BIGlzIG5vdCBz ZXQKIyBDT05GSUdfQkxLX0RFVl9IUFQzNjYgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1BJ SVggaXMgbm90IHNldAojIENPTkZJR19QSUlYX1RVTklORyBpcyBub3Qgc2V0CiMgQ09ORklHX0JM S19ERVZfTlM4NzQxNSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfT1BUSTYyMSBpcyBub3Qg c2V0CiMgQ09ORklHX0JMS19ERVZfUERDMjAyWFggaXMgbm90IHNldAojIENPTkZJR19QREMyMDJY WF9CVVJTVCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfT1NCNCBpcyBub3Qgc2V0CiMgQ09O RklHX0JMS19ERVZfU0lTNTUxMyBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfU0xDOTBFNjYg aXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1RSTTI5MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JM S19ERVZfVklBODJDWFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfSURFX0NISVBTRVRTIGlzIG5vdCBz ZXQKQ09ORklHX0lERURNQV9BVVRPPXkKIyBDT05GSUdfSURFRE1BX0lWQiBpcyBub3Qgc2V0CiMg Q09ORklHX0RNQV9OT05QQ0kgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0lERV9NT0RFUyBp cyBub3Qgc2V0CgojCiMgU0NTSSBzdXBwb3J0CiMKQ09ORklHX1NDU0k9eQpDT05GSUdfQkxLX0RF Vl9TRD15CkNPTkZJR19TRF9FWFRSQV9ERVZTPTQwCiMgQ09ORklHX0NIUl9ERVZfU1QgaXMgbm90 IHNldAojIENPTkZJR19DSFJfREVWX09TU1QgaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl9TUj15 CiMgQ09ORklHX0JMS19ERVZfU1JfVkVORE9SIGlzIG5vdCBzZXQKQ09ORklHX1NSX0VYVFJBX0RF VlM9MgpDT05GSUdfQ0hSX0RFVl9TRz15CkNPTkZJR19TQ1NJX0RFQlVHX1FVRVVFUz15CkNPTkZJ R19TQ1NJX01VTFRJX0xVTj15CkNPTkZJR19TQ1NJX0NPTlNUQU5UUz15CiMgQ09ORklHX1NDU0lf TE9HR0lORyBpcyBub3Qgc2V0CgojCiMgU0NTSSBsb3ctbGV2ZWwgZHJpdmVycwojCiMgQ09ORklH X0JMS19ERVZfM1dfWFhYWF9SQUlEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV83MDAwRkFTU1Qg aXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FDQVJEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9B SEExNTJYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9BSEExNTQyIGlzIG5vdCBzZXQKIyBDT05G SUdfU0NTSV9BSEExNzQwIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfQUlDN1hYWD15CkNPTkZJR19B SUM3WFhYX1RDUV9PTl9CWV9ERUZBVUxUPXkKQ09ORklHX0FJQzdYWFhfQ01EU19QRVJfREVWSUNF PTgKQ09ORklHX0FJQzdYWFhfUFJPQ19TVEFUUz15CkNPTkZJR19BSUM3WFhYX1JFU0VUX0RFTEFZ PTUKIyBDT05GSUdfU0NTSV9BRFZBTlNZUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSU4yMDAw IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9BTTUzQzk3NCBpcyBub3Qgc2V0CiMgQ09ORklHX1ND U0lfTUVHQVJBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0JVU0xPR0lDIGlzIG5vdCBzZXQK IyBDT05GSUdfU0NTSV9DUFFGQ1RTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9ETVgzMTkxRCBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRFRDMzI4MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lf RUFUQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRUFUQV9ETUEgaXMgbm90IHNldAojIENPTkZJ R19TQ1NJX0VBVEFfUElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9GVVRVUkVfRE9NQUlOIGlz IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9HRFRIIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9HRU5F UklDX05DUjUzODAgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lQUyBpcyBub3Qgc2V0CiMgQ09O RklHX1NDU0lfSU5JVElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9JTklBMTAwIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0NTSV9QUEEgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lNTSBpcyBub3Qg c2V0CiMgQ09ORklHX1NDU0lfTkNSNTNDNDA2QSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTkNS NTNDN3h4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9OQ1I1M0M4WFggaXMgbm90IHNldAojIENP TkZJR19TQ1NJX1NZTTUzQzhYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUEFTMTYgaXMgbm90 IHNldAojIENPTkZJR19TQ1NJX1BDSTIwMDAgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1BDSTIy MjBJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9QU0kyNDBJIGlzIG5vdCBzZXQKIyBDT05GSUdf U0NTSV9RTE9HSUNfRkFTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNfSVNQIGlzIG5v dCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNfRkMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1FM T0dJQ18xMjgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TRUFHQVRFIGlzIG5vdCBzZXQKIyBD T05GSUdfU0NTSV9TSU03MTAgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1NZTTUzQzQxNiBpcyBu b3Qgc2V0CiMgQ09ORklHX1NDU0lfREMzOTBUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9UMTI4 IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9VMTRfMzRGIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT SV9VTFRSQVNUT1IgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0RFQlVHIGlzIG5vdCBzZXQKCiMK IyBJRUVFIDEzOTQgKEZpcmVXaXJlKSBzdXBwb3J0CiMKIyBDT05GSUdfSUVFRTEzOTQgaXMgbm90 IHNldAoKIwojIEkyTyBkZXZpY2Ugc3VwcG9ydAojCiMgQ09ORklHX0kyTyBpcyBub3Qgc2V0CiMg Q09ORklHX0kyT19QQ0kgaXMgbm90IHNldAojIENPTkZJR19JMk9fQkxPQ0sgaXMgbm90IHNldAoj IENPTkZJR19JMk9fTEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJPX1NDU0kgaXMgbm90IHNldAoj IENPTkZJR19JMk9fUFJPQyBpcyBub3Qgc2V0CgojCiMgTmV0d29yayBkZXZpY2Ugc3VwcG9ydAoj CkNPTkZJR19ORVRERVZJQ0VTPXkKCiMKIyBBUkNuZXQgZGV2aWNlcwojCiMgQ09ORklHX0FSQ05F VCBpcyBub3Qgc2V0CiMgQ09ORklHX0RVTU1ZIGlzIG5vdCBzZXQKIyBDT05GSUdfQk9ORElORyBp cyBub3Qgc2V0CiMgQ09ORklHX0VRVUFMSVpFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1RVTiBpcyBu b3Qgc2V0CiMgQ09ORklHX0VUSEVSVEFQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NCMTAwMCBp cyBub3Qgc2V0CgojCiMgRXRoZXJuZXQgKDEwIG9yIDEwME1iaXQpCiMKQ09ORklHX05FVF9FVEhF Uk5FVD15CkNPTkZJR19ORVRfVkVORE9SXzNDT009eQojIENPTkZJR19FTDEgaXMgbm90IHNldAoj IENPTkZJR19FTDIgaXMgbm90IHNldAojIENPTkZJR19FTFBMVVMgaXMgbm90IHNldAojIENPTkZJ R19FTDE2IGlzIG5vdCBzZXQKIyBDT05GSUdfRUwzIGlzIG5vdCBzZXQKIyBDT05GSUdfM0M1MTUg aXMgbm90IHNldAojIENPTkZJR19FTE1DIGlzIG5vdCBzZXQKIyBDT05GSUdfRUxNQ19JSSBpcyBu b3Qgc2V0CkNPTkZJR19WT1JURVg9eQojIENPTkZJR19MQU5DRSBpcyBub3Qgc2V0CiMgQ09ORklH X05FVF9WRU5ET1JfU01DIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9SQUNBTCBpcyBu b3Qgc2V0CiMgQ09ORklHX0FUMTcwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFUENBIGlzIG5vdCBz ZXQKIyBDT05GSUdfSFAxMDAgaXMgbm90IHNldAojIENPTkZJR19ORVRfSVNBIGlzIG5vdCBzZXQK Q09ORklHX05FVF9QQ0k9eQojIENPTkZJR19QQ05FVDMyIGlzIG5vdCBzZXQKIyBDT05GSUdfQURB UFRFQ19TVEFSRklSRSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDMzIwMCBpcyBub3Qgc2V0CiMgQ09O RklHX0FQUklDT1QgaXMgbm90IHNldAojIENPTkZJR19DUzg5eDAgaXMgbm90IHNldAojIENPTkZJ R19UVUxJUCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFNFg1IGlzIG5vdCBzZXQKIyBDT05GSUdfREdS UyBpcyBub3Qgc2V0CiMgQ09ORklHX0RNOTEwMiBpcyBub3Qgc2V0CiMgQ09ORklHX0VFUFJPMTAw IGlzIG5vdCBzZXQKIyBDT05GSUdfRUVQUk8xMDBfUE0gaXMgbm90IHNldAojIENPTkZJR19MTkUz OTAgaXMgbm90IHNldAojIENPTkZJR19OQVRTRU1JIGlzIG5vdCBzZXQKQ09ORklHX05FMktfUENJ PXkKIyBDT05GSUdfTkUzMjEwIGlzIG5vdCBzZXQKIyBDT05GSUdfRVMzMjEwIGlzIG5vdCBzZXQK IyBDT05GSUdfODEzOVRPTyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUTDgxMjkgaXMgbm90IHNldAoj IENPTkZJR19TSVM5MDAgaXMgbm90IHNldAojIENPTkZJR19FUElDMTAwIGlzIG5vdCBzZXQKIyBD T05GSUdfU1VOREFOQ0UgaXMgbm90IHNldAojIENPTkZJR19UTEFOIGlzIG5vdCBzZXQKIyBDT05G SUdfVklBX1JISU5FIGlzIG5vdCBzZXQKIyBDT05GSUdfV0lOQk9ORF84NDAgaXMgbm90IHNldAoj IENPTkZJR19IQVBQWU1FQUwgaXMgbm90IHNldAojIENPTkZJR19ORVRfUE9DS0VUIGlzIG5vdCBz ZXQKCiMKIyBFdGhlcm5ldCAoMTAwMCBNYml0KQojCiMgQ09ORklHX0FDRU5JQyBpcyBub3Qgc2V0 CiMgQ09ORklHX0hBTUFDSEkgaXMgbm90IHNldAojIENPTkZJR19ZRUxMT1dGSU4gaXMgbm90IHNl dAojIENPTkZJR19TSzk4TElOIGlzIG5vdCBzZXQKIyBDT05GSUdfRkRESSBpcyBub3Qgc2V0CiMg Q09ORklHX0hJUFBJIGlzIG5vdCBzZXQKIyBDT05GSUdfUExJUCBpcyBub3Qgc2V0CiMgQ09ORklH X1BQUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NMSVAgaXMgbm90IHNldAoKIwojIFdpcmVsZXNzIExB TiAobm9uLWhhbXJhZGlvKQojCiMgQ09ORklHX05FVF9SQURJTyBpcyBub3Qgc2V0CgojCiMgVG9r ZW4gUmluZyBkZXZpY2VzCiMKIyBDT05GSUdfVFIgaXMgbm90IHNldAojIENPTkZJR19ORVRfRkMg aXMgbm90IHNldAojIENPTkZJR19SQ1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NIQVBFUiBpcyBu b3Qgc2V0CgojCiMgV2FuIGludGVyZmFjZXMKIwojIENPTkZJR19XQU4gaXMgbm90IHNldAoKIwoj IEFtYXRldXIgUmFkaW8gc3VwcG9ydAojCiMgQ09ORklHX0hBTVJBRElPIGlzIG5vdCBzZXQKCiMK IyBJckRBIChpbmZyYXJlZCkgc3VwcG9ydAojCiMgQ09ORklHX0lSREEgaXMgbm90IHNldAoKIwoj IElTRE4gc3Vic3lzdGVtCiMKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0CgojCiMgT2xkIENELVJP TSBkcml2ZXJzIChub3QgU0NTSSwgbm90IElERSkKIwojIENPTkZJR19DRF9OT19JREVTQ1NJIGlz IG5vdCBzZXQKCiMKIyBJbnB1dCBjb3JlIHN1cHBvcnQKIwpDT05GSUdfSU5QVVQ9eQojIENPTkZJ R19JTlBVVF9LRVlCREVWIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01PVVNFREVWPXkKQ09ORklH X0lOUFVUX01PVVNFREVWX1NDUkVFTl9YPTEwMjQKQ09ORklHX0lOUFVUX01PVVNFREVWX1NDUkVF Tl9ZPTc2OApDT05GSUdfSU5QVVRfSk9ZREVWPXkKIyBDT05GSUdfSU5QVVRfRVZERVYgaXMgbm90 IHNldAoKIwojIENoYXJhY3RlciBkZXZpY2VzCiMKQ09ORklHX1ZUPXkKQ09ORklHX1ZUX0NPTlNP TEU9eQpDT05GSUdfU0VSSUFMPXkKIyBDT05GSUdfU0VSSUFMX0NPTlNPTEUgaXMgbm90IHNldAoj IENPTkZJR19TRVJJQUxfRVhURU5ERUQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfTk9OU1RB TkRBUkQgaXMgbm90IHNldApDT05GSUdfVU5JWDk4X1BUWVM9eQpDT05GSUdfVU5JWDk4X1BUWV9D T1VOVD0yNTYKQ09ORklHX1BSSU5URVI9eQojIENPTkZJR19MUF9DT05TT0xFIGlzIG5vdCBzZXQK IyBDT05GSUdfUFBERVYgaXMgbm90IHNldAoKIwojIEkyQyBzdXBwb3J0CiMKQ09ORklHX0kyQz15 CkNPTkZJR19JMkNfQUxHT0JJVD15CiMgQ09ORklHX0kyQ19QSElMSVBTUEFSIGlzIG5vdCBzZXQK IyBDT05GSUdfSTJDX0VMViBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19WRUxMRU1BTiBpcyBub3Qg c2V0CiMgQ09ORklHX0kyQ19BTEdPUENGIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19NQUlOQk9BUkQ9 eQojIENPTkZJR19JMkNfQUxJMTVYMyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19IWURSQSBpcyBu b3Qgc2V0CiMgQ09ORklHX0kyQ19BTUQ3NTYgaXMgbm90IHNldAojIENPTkZJR19JMkNfSTgwMSBp cyBub3Qgc2V0CiMgQ09ORklHX0kyQ19JODEwIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19QSUlYND15 CiMgQ09ORklHX0kyQ19WSUEgaXMgbm90IHNldAojIENPTkZJR19JMkNfVklBUFJPIGlzIG5vdCBz ZXQKIyBDT05GSUdfSTJDX1ZPT0RPTyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19JU0EgaXMgbm90 IHNldApDT05GSUdfSTJDX0NIQVJERVY9eQoKIwojIEhhcmR3YXJlIHNlbnNvcnMgc3VwcG9ydAoj CkNPTkZJR19TRU5TT1JTPXkKIyBDT05GSUdfU0VOU09SU19BRE0xMDIxIGlzIG5vdCBzZXQKIyBD T05GSUdfU0VOU09SU19BRE0xMDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE05MjQw IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNNIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTc1IGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VOU09SU19MTTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgw IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTg3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19TSVM1NTk1IGlzIG5vdCBzZXQKIyBDT05GSUdfVEhNQzUwIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19WSUE2ODZBIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfVzgzNzgxRD15CiMg Q09ORklHX1NFTlNPUlNfT1RIRVIgaXMgbm90IHNldAoKIwojIE1pY2UKIwojIENPTkZJR19CVVNN T1VTRSBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFIGlzIG5vdCBzZXQKCiMKIyBKb3lzdGlja3MK IwojIENPTkZJR19KT1lTVElDSyBpcyBub3Qgc2V0CiMgQ09ORklHX1FJQzAyX1RBUEUgaXMgbm90 IHNldAoKIwojIFdhdGNoZG9nIENhcmRzCiMKIyBDT05GSUdfV0FUQ0hET0cgaXMgbm90IHNldAoj IENPTkZJR19JTlRFTF9STkcgaXMgbm90IHNldAojIENPTkZJR19OVlJBTSBpcyBub3Qgc2V0CkNP TkZJR19SVEM9eQojIENPTkZJR19EVExLIGlzIG5vdCBzZXQKIyBDT05GSUdfUjM5NjQgaXMgbm90 IHNldAojIENPTkZJR19BUFBMSUNPTSBpcyBub3Qgc2V0CgojCiMgRnRhcGUsIHRoZSBmbG9wcHkg dGFwZSBkZXZpY2UgZHJpdmVyCiMKIyBDT05GSUdfRlRBUEUgaXMgbm90IHNldAojIENPTkZJR19B R1AgaXMgbm90IHNldAojIENPTkZJR19EUk0gaXMgbm90IHNldAoKIwojIE11bHRpbWVkaWEgZGV2 aWNlcwojCkNPTkZJR19WSURFT19ERVY9eQoKIwojIFZpZGVvIEZvciBMaW51eAojCkNPTkZJR19W SURFT19QUk9DX0ZTPXkKIyBDT05GSUdfSTJDX1BBUlBPUlQgaXMgbm90IHNldApDT05GSUdfVklE RU9fQlQ4NDg9eQojIENPTkZJR19WSURFT19QTVMgaXMgbm90IHNldAojIENPTkZJR19WSURFT19C V1FDQU0gaXMgbm90IHNldAojIENPTkZJR19WSURFT19DUUNBTSBpcyBub3Qgc2V0CiMgQ09ORklH X1ZJREVPX0NQSUEgaXMgbm90IHNldAojIENPTkZJR19WSURFT19TQUE1MjQ5IGlzIG5vdCBzZXQK IyBDT05GSUdfVFVORVJfMzAzNiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NUUkFESVMgaXMg bm90IHNldAojIENPTkZJR19WSURFT19aT1JBTiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0JV WiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1pSMzYxMjAgaXMgbm90IHNldAoKIwojIFJhZGlv IEFkYXB0ZXJzCiMKIyBDT05GSUdfUkFESU9fQ0FERVQgaXMgbm90IHNldAojIENPTkZJR19SQURJ T19SVFJBQ0sgaXMgbm90IHNldAojIENPTkZJR19SQURJT19SVFJBQ0syIGlzIG5vdCBzZXQKIyBD T05GSUdfUkFESU9fQVpURUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFESU9fR0VNVEVLIGlzIG5v dCBzZXQKIyBDT05GSUdfUkFESU9fTUFFU1RSTyBpcyBub3Qgc2V0CiMgQ09ORklHX1JBRElPX01J Uk9QQ00yMCBpcyBub3Qgc2V0CiMgQ09ORklHX1JBRElPX1NGMTZGTUkgaXMgbm90IHNldAojIENP TkZJR19SQURJT19URVJSQVRFQyBpcyBub3Qgc2V0CiMgQ09ORklHX1JBRElPX1RSVVNUIGlzIG5v dCBzZXQKIyBDT05GSUdfUkFESU9fVFlQSE9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX1JBRElPX1pP TFRSSVggaXMgbm90IHNldAoKIwojIEZpbGUgc3lzdGVtcwojCiMgQ09ORklHX1FVT1RBIGlzIG5v dCBzZXQKIyBDT05GSUdfQVVUT0ZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0FVVE9GUzRfRlM9eQpD T05GSUdfUkVJU0VSRlNfRlM9eQojIENPTkZJR19SRUlTRVJGU19DSEVDSyBpcyBub3Qgc2V0CiMg Q09ORklHX0FERlNfRlMgaXMgbm90IHNldAojIENPTkZJR19BREZTX0ZTX1JXIGlzIG5vdCBzZXQK IyBDT05GSUdfQUZGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hGU19GUyBpcyBub3Qgc2V0CiMg Q09ORklHX0JGU19GUyBpcyBub3Qgc2V0CkNPTkZJR19GQVRfRlM9eQojIENPTkZJR19NU0RPU19G UyBpcyBub3Qgc2V0CiMgQ09ORklHX1VNU0RPU19GUyBpcyBub3Qgc2V0CkNPTkZJR19WRkFUX0ZT PXkKIyBDT05GSUdfRUZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSkZGU19GUyBpcyBub3Qgc2V0 CiMgQ09ORklHX0NSQU1GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1JBTUZTIGlzIG5vdCBzZXQKQ09O RklHX0lTTzk2NjBfRlM9eQpDT05GSUdfSk9MSUVUPXkKQ09ORklHX01JTklYX0ZTPXkKIyBDT05G SUdfTlRGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX05URlNfUlcgaXMgbm90IHNldAojIENPTkZJ R19IUEZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHX1BST0NfRlM9eQojIENPTkZJR19ERVZGU19GUyBp cyBub3Qgc2V0CiMgQ09ORklHX0RFVkZTX01PVU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfREVWRlNf REVCVUcgaXMgbm90IHNldApDT05GSUdfREVWUFRTX0ZTPXkKIyBDT05GSUdfUU5YNEZTX0ZTIGlz IG5vdCBzZXQKIyBDT05GSUdfUU5YNEZTX1JXIGlzIG5vdCBzZXQKIyBDT05GSUdfUk9NRlNfRlMg aXMgbm90IHNldApDT05GSUdfRVhUMl9GUz15CiMgQ09ORklHX1NZU1ZfRlMgaXMgbm90IHNldAoj IENPTkZJR19TWVNWX0ZTX1dSSVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfVURGX0ZTIGlzIG5vdCBz ZXQKIyBDT05GSUdfVURGX1JXIGlzIG5vdCBzZXQKIyBDT05GSUdfVUZTX0ZTIGlzIG5vdCBzZXQK IyBDT05GSUdfVUZTX0ZTX1dSSVRFIGlzIG5vdCBzZXQKCiMKIyBOZXR3b3JrIEZpbGUgU3lzdGVt cwojCiMgQ09ORklHX0NPREFfRlMgaXMgbm90IHNldApDT05GSUdfTkZTX0ZTPXkKQ09ORklHX05G U19WMz15CiMgQ09ORklHX1JPT1RfTkZTIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZTRCBpcyBub3Qg c2V0CiMgQ09ORklHX05GU0RfVjMgaXMgbm90IHNldApDT05GSUdfU1VOUlBDPXkKQ09ORklHX0xP Q0tEPXkKQ09ORklHX0xPQ0tEX1Y0PXkKQ09ORklHX1NNQl9GUz15CiMgQ09ORklHX1NNQl9OTFNf REVGQVVMVCBpcyBub3Qgc2V0CiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX05D UEZTX1BBQ0tFVF9TSUdOSU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfTkNQRlNfSU9DVExfTE9DS0lO RyBpcyBub3Qgc2V0CiMgQ09ORklHX05DUEZTX1NUUk9ORyBpcyBub3Qgc2V0CiMgQ09ORklHX05D UEZTX05GU19OUyBpcyBub3Qgc2V0CiMgQ09ORklHX05DUEZTX09TMl9OUyBpcyBub3Qgc2V0CiMg Q09ORklHX05DUEZTX1NNQUxMRE9TIGlzIG5vdCBzZXQKIyBDT05GSUdfTkNQRlNfTkxTIGlzIG5v dCBzZXQKIyBDT05GSUdfTkNQRlNfRVhUUkFTIGlzIG5vdCBzZXQKCiMKIyBQYXJ0aXRpb24gVHlw ZXMKIwojIENPTkZJR19QQVJUSVRJT05fQURWQU5DRUQgaXMgbm90IHNldApDT05GSUdfTVNET1Nf UEFSVElUSU9OPXkKQ09ORklHX1NNQl9OTFM9eQpDT05GSUdfTkxTPXkKCiMKIyBOYXRpdmUgTGFu Z3VhZ2UgU3VwcG9ydAojCkNPTkZJR19OTFNfREVGQVVMVD0iaXNvODg1OS0xIgojIENPTkZJR19O TFNfQ09ERVBBR0VfNDM3IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzczNyBpcyBu b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV83NzUgaXMgbm90IHNldApDT05GSUdfTkxTX0NP REVQQUdFXzg1MD15CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTIgaXMgbm90IHNldAojIENPTkZJ R19OTFNfQ09ERVBBR0VfODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NyBp cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldAojIENPTkZJR19O TFNfQ09ERVBBR0VfODYxIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MiBpcyBu b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjMgaXMgbm90IHNldAojIENPTkZJR19OTFNf Q09ERVBBR0VfODY0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NSBpcyBub3Qg c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E RVBBR0VfODY5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg3NCBpcyBub3Qgc2V0 CiMgQ09ORklHX05MU19DT0RFUEFHRV85MzIgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBB R0VfOTM2IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk0OSBpcyBub3Qgc2V0CiMg Q09ORklHX05MU19DT0RFUEFHRV85NTAgaXMgbm90IHNldApDT05GSUdfTkxTX0lTTzg4NTlfMT15 CiMgQ09ORklHX05MU19JU084ODU5XzIgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8z IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNCBpcyBub3Qgc2V0CiMgQ09ORklHX05M U19JU084ODU5XzUgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV82IGlzIG5vdCBzZXQK IyBDT05GSUdfTkxTX0lTTzg4NTlfNyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5Xzgg aXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT X0lTTzg4NTlfMTQgaXMgbm90IHNldApDT05GSUdfTkxTX0lTTzg4NTlfMTU9eQojIENPTkZJR19O TFNfS09JOF9SIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX1VURjggaXMgbm90IHNldAoKIwojIENv bnNvbGUgZHJpdmVycwojCkNPTkZJR19WR0FfQ09OU09MRT15CkNPTkZJR19WSURFT19TRUxFQ1Q9 eQojIENPTkZJR19NREFfQ09OU09MRSBpcyBub3Qgc2V0CgojCiMgRnJhbWUtYnVmZmVyIHN1cHBv cnQKIwojIENPTkZJR19GQiBpcyBub3Qgc2V0CgojCiMgU291bmQKIwpDT05GSUdfU09VTkQ9eQoj IENPTkZJR19TT1VORF9DTVBDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NPVU5EX0VNVTEwSzEgaXMg bm90IHNldAojIENPTkZJR19TT1VORF9GVVNJT04gaXMgbm90IHNldAojIENPTkZJR19TT1VORF9D UzQyODEgaXMgbm90IHNldAojIENPTkZJR19TT1VORF9FUzEzNzAgaXMgbm90IHNldApDT05GSUdf U09VTkRfRVMxMzcxPXkKIyBDT05GSUdfU09VTkRfRVNTU09MTzEgaXMgbm90IHNldAojIENPTkZJ R19TT1VORF9NQUVTVFJPIGlzIG5vdCBzZXQKIyBDT05GSUdfU09VTkRfU09OSUNWSUJFUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1NPVU5EX1RSSURFTlQgaXMgbm90IHNldAojIENPTkZJR19TT1VORF9N U05EQ0xBUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NPVU5EX01TTkRQSU4gaXMgbm90IHNldAojIENP TkZJR19TT1VORF9WSUE4MkNYWFggaXMgbm90IHNldAojIENPTkZJR19TT1VORF9PU1MgaXMgbm90 IHNldAojIENPTkZJR19TT1VORF9UVk1JWEVSIGlzIG5vdCBzZXQKCiMKIyBVU0Igc3VwcG9ydAoj CkNPTkZJR19VU0I9eQojIENPTkZJR19VU0JfREVCVUcgaXMgbm90IHNldApDT05GSUdfVVNCX0RF VklDRUZTPXkKIyBDT05GSUdfVVNCX0JBTkRXSURUSCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfVUhD SV9BTFQ9eQojIENPTkZJR19VU0JfT0hDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BVURJTyBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9CTFVFVE9PVEggaXMgbm90IHNldAojIENPTkZJR19VU0Jf U1RPUkFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BQ00gaXMgbm90IHNldAojIENPTkZJR19V U0JfUFJJTlRFUiBpcyBub3Qgc2V0CkNPTkZJR19VU0JfSElEPXkKIyBDT05GSUdfVVNCX1dBQ09N IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0RDMlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01E QzgwMCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfU0NBTk5FUj1tCkNPTkZJR19VU0JfTUlDUk9URUs9 bQojIENPTkZJR19VU0JfSUJNQ0FNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09WNTExIGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX0RTQlIgaXMgbm90IHNldAojIENPTkZJR19VU0JfREFCVVNCIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX1BMVVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1BFR0FT VVMgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUMTA4MCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT Ql9VU1M3MjAgaXMgbm90IHNldAoKIwojIFVTQiBTZXJpYWwgQ29udmVydGVyIHN1cHBvcnQKIwoj IENPTkZJR19VU0JfU0VSSUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qg c2V0CgojCiMgS2VybmVsIGhhY2tpbmcKIwojIENPTkZJR19NQUdJQ19TWVNSUSBpcyBub3Qgc2V0 Cg== --Multipart_Tue__20_Feb_2001_16:50:47_+0100_081cfd18-- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Feb 20 21:06:06 2001 Received: by humbolt.nl.linux.org id ; Tue, 20 Feb 2001 21:01:42 +0100 Received: from imladris.infradead.org ([194.205.184.45]:38156 "EHLO infradead.org") by humbolt.nl.linux.org with ESMTP id ; Tue, 20 Feb 2001 20:56:53 +0100 Received: from [194.46.8.33] (helo=angusbay.vnl.com) by infradead.org with esmtp (Exim 3.20 #2) id 14VFmu-0004FX-00 for linux-crypto@nl.linux.org; Tue, 20 Feb 2001 16:37:16 +0000 Received: from amon by angusbay.vnl.com with local (Exim 3.20 #1) id 14VFnm-0005oY-00 (Debian); Tue, 20 Feb 2001 16:38:10 +0000 Date: Tue, 20 Feb 2001 16:38:09 +0000 From: Dale Amon To: linux-crypto@nl.linux.org Subject: Re: max size of a partition Message-ID: <20010220163808.N16525@vnl.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.3.12i X-Operating-System: Linux, the choice of a GNU generation Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I sent this to Mark earlier and forgot to cc the list. Additionally, I have since tried it a second time after installing a slightly different kernel and going to the absolute most recent bleeding debian edge with a sid dist update. Results are the same within experimental error :-) Machine locked up while writing inodes in a mkfs, but this time got further: host1:/etc/ssh# mkfs -t ext2 /dev/loop0 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 2240224 inodes, 4480096 blocks 224004 blocks (5.00%) reserved for the super user First data block=0 137 block groups 32768 blocks per group, 32768 fragments per group 16352 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000 Writing inode tables: 120/137 I do not yet have any info on what the final state of the machine is; it is off in a dusty corner of an NSP on the other side of town... -- ------------------------------------------------------ Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste. Belfast, Northern Ireland ------------------------------------------------------ --r5Pyd7+fXNt84Ff3 Content-Type: message/rfc822 Content-Disposition: inline Date: Tue, 20 Feb 2001 12:52:56 +0000 From: Dale Amon To: Marc Mutz Cc: bhughes@vnl.com Subject: Re: max size of a partition Message-ID: <20010220125254.F16525@vnl.com> References: <20010219224128.4f4c7677.pacman@bierkasten.org> <3A91CCD7.A8059C02@Mutz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <3A91CCD7.A8059C02@Mutz.com>; from Marc@Mutz.com on Tue, Feb 20, 2001 at 01:48:07AM +0000 X-Operating-System: Linux, the choice of a GNU generation On Tue, Feb 20, 2001 at 01:48:07AM +0000, Marc Mutz wrote: > pacman wrote: > > > > hi, > > i have problems with the encryption of my partition (28gb). i always get a kernel panic while i create. if the partition has a size of 2gb it works perfectly. so is there a limit of the size? and if, is there a workaround or a solution to solve this problem. > > > What kernel version? > Please describe your setup more _detailed_ (exact commands, entries in > fstab, you know...) > Hot off the presses as it were: I may be having a similar problem. The 2.4.0 kernel is monolithic and has the 3rd international patch set applied; I built and installed losetup, mount and umount applying the o patch set to version q (which applied with offsets). All of the above were built on a local machine that has developer tools. The target system does not. (well it has some tools, but they will eventually be removed as well.) The losetup worked fine: losetup -e thecipher /dev/loop0 /dev/md0 Then I started the mkfs: host1:/etc# mkfs -t ext2 -c -v /dev/loop0 mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 2240224 inodes, 4480096 blocks 224004 blocks (5.00%) reserved for the super user First data block=0 137 block groups 32768 blocks per group, 32768 fragments per group 16352 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000 Running command: badblocks -b 4096 -s /dev/loop0 4480096 Checking for bad blocks (read-only test): done Writing inode tables: 10/137 Stopped dead about here... The raw raid partition /dev/md0 is 18GB with two drives in RAID1 configuration. It was initialized to zero before any of the above was done. I had someone check the machine (on the other side of town) and the best I could was that the console messages said that it tried to kill kernel idle task; this was followed by a kernel panic. I realize that doing a loopback crypto on a raw RAID1 might be a bit unusual, but I see no reason it should not work and it eliminates an unnecessary layer of abstraction (unless someone can tell me a good reason why I should layer disks -> raid -> ext2 -> loopback file -> ext2 instead of disks -> raid -> raw device loopback -> ext2 -- ------------------------------------------------------ Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste. Belfast, Northern Ireland ------------------------------------------------------ --r5Pyd7+fXNt84Ff3-- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Feb 20 21:09:19 2001 Received: by humbolt.nl.linux.org id ; Tue, 20 Feb 2001 21:04:17 +0100 Received: from imladris.infradead.org ([194.205.184.45]:38156 "EHLO infradead.org") by humbolt.nl.linux.org with ESMTP id ; Tue, 20 Feb 2001 20:57:42 +0100 Received: from p3ee01d5c.dip.t-dialin.net ([62.224.29.92] helo=bierkasten.org ident=postfix) by infradead.org with esmtp (Exim 3.20 #2) id 14VFhb-0004Bk-00 for linux-crypto@nl.linux.org; Tue, 20 Feb 2001 16:31:47 +0000 Received: from pc-runner (pc-runner.sign.lan [192.168.1.1]) by bierkasten.org (Postfix) with SMTP id 305B71E06 for ; Tue, 20 Feb 2001 17:31:38 +0100 (MET) Date: Tue, 20 Feb 2001 17:31:38 +0100 From: pacman To: linux-crypto@nl.linux.org Subject: Re: max size of a partition Message-Id: <20010220173138.6129ace6.pacman@bierkasten.org> X-Mailer: Sylpheed version 0.4.61 (GTK+ 1.2.8; Linux 2.4.0; i686) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list i tried kernel ver 2.4.0 with reiserfs patch (3.6.25), -ac12, 2.4.1, -ac18 all with crypto patch 2.4.0.3. /etc/fstab: /dev/hda8 /mnt/crypto ext2 defaults,noauto,loop,encryption=aes,user 0 0 what i did: losetup (patched ver. s) losetup -e aes /dev/loop0 /dev/hda8 mke2fs /dev/loop0 ==> kernel panic if hda > 2gb kernel config ist attached. -- Sincerly Michael Walle In den Rohrwiesen 1a 66440 Blieskastel Deutschland pacman@bierkasten.org http://pacman.yi.org --- On Tue, 20 Feb 2001 01:48:07 +0000 Marc Mutz wrote: > pacman wrote: > > > > hi, > > i have problems with the encryption of my partition (28gb). i always get a kernel panic while i create. if the partition has a size of 2gb it works perfectly. so is there a limit of the size? and if, is there a workaround or a solution to solve this problem. > > > > > What kernel version? > Please describe your setup more _detailed_ (exact commands, entries in > fstab, you know...) > > Marc > > -- > Marc Mutz http://EncryptionHOWTO.sourceforge.net/ > University of Bielefeld, Dep. of Mathematics / Dep. of Physics > > PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) > > > Linux-crypto: cryptography in and on the Linux system > Archive: http://mail.nl.linux.org/linux-crypto/ Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Feb 21 18:02:40 2001 Received: by humbolt.nl.linux.org id ; Wed, 21 Feb 2001 18:01:37 +0100 Received: from [194.46.8.33] ([194.46.8.33]:57097 "EHLO angusbay.vnl.com") by humbolt.nl.linux.org with ESMTP id ; Wed, 21 Feb 2001 18:00:45 +0100 Received: from amon by angusbay.vnl.com with local (Exim 3.20 #1) id 14Vcdp-0001kW-00 (Debian); Wed, 21 Feb 2001 17:01:25 +0000 Date: Wed, 21 Feb 2001 17:01:25 +0000 From: Dale Amon To: "Brian S. Julin" Cc: linux-crypto@nl.linux.org Subject: Re: crypto loopback fs stuff Message-ID: <20010221170125.R1640@vnl.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from bri@tull.umassp.edu on Wed, Feb 21, 2001 at 11:52:13AM -0500 X-Operating-System: Linux, the choice of a GNU generation Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list I'm forwarding this on as it seems highly relevant to the problems a number of us are seeing: On Wed, Feb 21, 2001 at 11:52:13AM -0500, Brian S. Julin wrote: > > Hi, I'm not on the crypto list but I have some > info that probably should be posted there, so if > you'd do me the favor, thanks. > > I was having similar problems to the one you described > on the linux-crypto list, except I was using small > partitions/files and when the mke2fs hung, it would only > sit in the D state, it would not crash the kernel and > did not generate a segfault. This was with both > SCSI and IDE drives, so it's definitely not driver > problems. > > So I got the lastest greatest bleeding edge kernel > and applied Jens Axboe's loop-4 patch to it, and I > had the same result. I mailed Jens, and he said > to wait and give the upcoming loop-5 a try, which I did. > loop-5 (and loop-5B) got rid of the mke2fs problem, but > the machine now hangs mount in the D state when using > crypt (nonencrypted loopback seems to work fine.) > > Jens says he thinks he's fixed what he can of the > loop driver, and that he may look at it further, but > this particular problem is probably in the crypto > stuff. It will probably require someone deep into > the loop_gen crypto driver to fix it; until then, > assume things are just totally broken. > > If anyone wants their problem reports to be "meaningful", > I would recommend patching Linus's 2.4.X-preY releases > with Jen's latest loop patch (go to where you get your > kernel and cd ../people/axboe/patches). > > As things now stand on my system: > > AES -- refuses to mount > Blowfish -- segfaults losetup, div0 > serpent, rc5, twofish -- /bin/mount hands in D state > rc6 -- segfaults losetup, EIP=0 > > Note also if you are using funny block sizes, Alan Cox > mentioned something about fixing ext2fs block size > detection in 2.4.1-ac20 > > -- > Brian > -- ------------------------------------------------------ Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste. Belfast, Northern Ireland ------------------------------------------------------ Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Feb 21 20:01:44 2001 Received: by humbolt.nl.linux.org id ; Wed, 21 Feb 2001 20:01:05 +0100 Received: from mail2.uni-bielefeld.de ([129.70.4.90]:58072 "EHLO mail.uni-bielefeld.de") by humbolt.nl.linux.org with ESMTP id ; Wed, 21 Feb 2001 20:00:21 +0100 Received: from Mutz.com (ppp36-174.hrz.uni-bielefeld.de [129.70.36.174]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0G94004J1FG18B@mail.uni-bielefeld.de> for linux-crypto@nl.linux.org; Wed, 21 Feb 2001 20:00:07 +0100 (MET) Date: Wed, 21 Feb 2001 18:16:01 +0000 From: Marc Mutz Subject: Roundup of 2.4 kerneli problems and call for developers (was: Re: max size of a partition) To: pacman , Dale Amon Cc: linux-crypto@nl.linux.org Message-id: <3A9405E1.B42BC32E@Mutz.com> Organization: University of Bielefeld - Dep. of Mathematics / Dep. of Physics MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18-0001 i586) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20010220173138.6129ace6.pacman@bierkasten.org> Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list pacman wrote: > > kernel config ist attached. (You don't need to base64-encode a plain text file, just send it as 7but, and additionally, you could use grep -Ev '^$|^#' /usr/src/linux/.config | sed s/^CONFIG_// to remove the noise. Thanks) If this problem occurs only with partitions >2G, I think this is a 32bit issue. I don't know if this is a kernli issue or an incompatibility between loop-5 and kerneli. This mail is titled "... and call for developers". I think we could very well use some additional ones... So I'd like to point all of you that have problems with kerneli in 2.4 (or want to become a developer) to the following: 2.4 (and 2.2.18.4pre) patches use a new architecture both in module loading and the loopback crypto driver. The "stable" version on 2.2. is still 2.2.18.3; on 2.4.x such a thing does not exist, yet. It is hard to develop something when the underlying arthitecture is deeply buggy and the bug is not considered serious enough to be fixed before 2.4.0 :-( Known problems (w/ fixes if avaliable) a. loop.c is buggy in all 2.4.x kernels, resulting in a complete system hang when accessing the loop device for some time/amount of data. Lens Axboe has a loop-5 patch[1] but AFAIK this reworks the loop device heavily. Don't expect a loop-5 patched kernel to work with the kerneli patch that was written for 2.4.x vanilla. There is no kerneli that I know of that is taylored to loop-5. b. previous versions of losetup/mount had the ciphername-number translation table hardcoded into them. That meant re-compiling them whenever a cipher changed or was added. BAD. This was changed in a way that makes losetup/mount independent of the installed drivers: The IOCTL to setup the loop_gen driver was changed to take a ciphername instead of an (internal) ciphernumber as parameter. The name->number conversion is now done in the kernel via find_cipher_by_name(). Also, there were changes in the module loading code in cryptoapi.c. That has two implications: b1. Early versions of the 2.4.x patches were unable to handle the old-style IOCTL. You'd get "LOOP_SET_STATUS: Invalid argument" messages if that was the case. 2.4.0.3 has this fixed. b2. (I guess) The module loading code has still a bug, causing losetup to segfault. This comes up when you demand-load blowfish (and other ciphers) the first time. Workaround: Load the modules before you run losetup. The problem is that I am not running 2.4.x. I do run 2.2.18.4pre1, but I am not into the new design to debug the "losetup segfaults" error. If there is someone that is a better C/Unix programmer than I am (which is easy to accomplish), I'd appreciate if he or she took a look at the code. It is not much code and quite independent of everything else in the kernel except the loop device. I worked my way into the (old) sources in a few hour's time so there should likely be people out there that can do this in less than an hour. This project certainly lacks developers, because Gisle has just finished his/her (heck, I don't even know Gisle's sex!?) master thesis (or so I understand) and is likely gone job-hunting, /me is just starting his diploma thesis (finally :-) and Astor seems to be wrapped up in work, too. If you can help, you're welcome... Marc [1] ftp.kernel.org/pub/linux/kernel/people/axboe//loop-5* -- Marc Mutz http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Wed Feb 21 23:46:05 2001 Received: by humbolt.nl.linux.org id ; Wed, 21 Feb 2001 23:45:14 +0100 Received: from pop.gmx.net ([194.221.183.20]:63900 "HELO mail.gmx.net") by humbolt.nl.linux.org with SMTP id ; Wed, 21 Feb 2001 23:44:48 +0100 Received: (qmail 15610 invoked by uid 0); 21 Feb 2001 22:44:47 -0000 Received: from 223.135.fl1.ip.foni.net (HELO server.bodom.netz) (212.7.135.223) by mail.gmx.net (mp009-rz3) with SMTP; 21 Feb 2001 22:44:47 -0000 Received: from workstation (workstation.bodom.netz [192.168.50.100]) by server.bodom.netz (8.11.2/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id f1K5fPp08037 for ; Tue, 20 Feb 2001 06:41:25 +0100 From: "Morbid Angel" To: Subject: problems Date: Tue, 20 Feb 2001 06:41:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list Hi ! Im new in this Mailing List ! I can't speak english very well but i hope u all can understand what i mean ! :))) I have 2 Problems: With 2.2.18 Kernel I get error messages : "modprobe: Can't locate module sipher-18" I use IDEA compiled in Kernel (not as a module) But all works ok with 12GB big crypted file With 2.4.0 Kernel If i do "losetup -e idea ..." with my 12GB crypted file i get ever this error msg "File to large" ! Can someone help me ? Bye Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Thu Feb 22 14:37:53 2001 Received: by humbolt.nl.linux.org id ; Thu, 22 Feb 2001 14:37:14 +0100 Received: from [194.46.8.33] ([194.46.8.33]:44816 "EHLO angusbay.vnl.com") by humbolt.nl.linux.org with ESMTP id ; Thu, 22 Feb 2001 14:36:50 +0100 Received: from amon by angusbay.vnl.com with local (Exim 3.20 #1) id 14VvwH-0003dI-00 (Debian); Thu, 22 Feb 2001 13:37:45 +0000 Date: Thu, 22 Feb 2001 13:37:44 +0000 From: Dale Amon To: linux-crypto@nl.linux.org Subject: Re: max size of a partition Message-ID: <20010222133743.F1640@vnl.com> References: <20010220163808.N16525@vnl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010220163808.N16525@vnl.com>; from amon@vnl.com on Tue, Feb 20, 2001 at 04:38:09PM +0000 X-Operating-System: Linux, the choice of a GNU generation Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list FWIW: Last night I built a 2.4.2 pre5 kernel in this patching order: * 2.4.1 base * 2.4.2 pre5 patch set * loop-5B patches * 2.4.0.3 international patch set It compiled and booted without error. Now as to whether it can *do* anything, I can't say yet because it was a bit on the late side when I got to the boot up test. So if nothing else, the patches cohabitate without blatent outwardly noticeable problems... -- ------------------------------------------------------ Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste. Belfast, Northern Ireland ------------------------------------------------------ Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ From owner-linux-crypto@nl.linux.org Tue Feb 27 00:13:07 2001 Received: by humbolt.nl.linux.org id ; Tue, 27 Feb 2001 00:11:30 +0100 Received: from w146-108.echostar.com ([205.172.146.108]:51972 "EHLO linux0.echostar.com") by humbolt.nl.linux.org with ESMTP id ; Tue, 27 Feb 2001 00:11:03 +0100 Received: from echostar.com (IDENT:ian@linux10 [10.79.98.110]) by linux0.echostar.com (8.9.3/8.8.7) with ESMTP id QAA10078 for ; Mon, 26 Feb 2001 16:10:58 -0700 Message-ID: <3A9AE282.147DE47@echostar.com> Date: Mon, 26 Feb 2001 16:10:58 -0700 From: "Ian S. Nelson" Reply-To: ian.nelson@echostar.com Organization: Echostar X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-crypto Subject: Loading secure binaries? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-crypto@nl.linux.org Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-crypto-list I'm working on an embedded Linux project and the issue of security is starting to surface and it's beginning to look kind of interesting. Is there any plans with Linux-crypto or some other project that somebody knows of to allow the loading of secure binaries? I was thinking of a scheme like this: there would be a new linux executable loader, perhaps one of the misc binary loaders or an ELF hack, you'd want it to reside inside the kernel though. Then add a new system call to provide a key to the kernel. This could be pulled down off the internet or out of a secure piece of hardware. In some applications it could be something the user provides at login time. Then the new binaries would be AES/IDEA/DES encrypted with that key and the new loader would use that key to decrypt them at load time. Anybody know of something like this? A logical extension would be to embed GPG into the kernel and then you could execute signed and encrypted binaries but that seems like overkill for what we're doing, we just don't want a few key pieces of code to ever be decrypted anywhere other than SDRAM. thanks, Ian Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/