- 10 Jan, 2008 29 commits
-
-
Herbert Xu authored
Up until now we have ablkcipher algorithms have been identified as type BLKCIPHER with the ASYNC bit set. This is suboptimal because ablkcipher refers to two things. On the one hand it refers to the top-level ablkcipher interface with requests. On the other hand it refers to and algorithm type underneath. As it is you cannot request a synchronous block cipher algorithm with the ablkcipher interface on top. This is a problem because we want to be able to eventually phase out the blkcipher top-level interface. This patch fixes this by making ABLKCIPHER its own type, just as we have distinct types for HASH and DIGEST. The type it associated with the algorithm implementation only. Which top-level interface is used for synchronous block ciphers is then determined by the mask that's used. If it's a specific mask then the old blkcipher interface is given, otherwise we go with the new ablkcipher interface. Signed-off-by:Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
This patch updates the list of transforms we support and clarifies that the Block Ciphers interface in fact supports all ciphers including stream ciphers. It also removes the obsolete Configuration Notes section and adds the linux-crypto mailing list as the primary bug reporting address. Finally it documents the fact that setkey should only be called from user context. Signed-off-by: -
Herbert Xu authored
This patch converts the crypto scatterwalk code to use the generic scatterlist chaining rather the version specific to crypto. Signed-off-by: -
Andrew Morton authored
alpha: drivers/crypto/hifn_795x.c: In function 'ablkcipher_walk_init': drivers/crypto/hifn_795x.c:1231: error: implicit declaration of function 'sg_init_table' drivers/crypto/hifn_795x.c:1243: error: implicit declaration of function 'sg_set_page' drivers/crypto/hifn_795x.c: In function 'ablkcipher_walk_exit': drivers/crypto/hifn_795x.c:1257: error: implicit declaration of function 'sg_page' drivers/crypto/hifn_795x.c:1257: warning: passing argument 1 of '__free_pages' makes pointer from integer without a cast drivers/crypto/hifn_795x.c: In function 'ablkcipher_add': drivers/crypto/hifn_795x.c:1278: warning: passing argument 1 of 'kmap_atomic' makes pointer from integer without a cast drivers/crypto/hifn_795x.c: In function 'ablkcipher_walk': drivers/crypto/hifn_795x.c:1336: warning: passing argument 1 of 'kmap_atomic' makes pointer from integer without a cast drivers/crypto/hifn_795x.c: In function 'hifn_setup_session': drivers/crypto/hifn_795x.c:1465: warning: assignment makes pointer from integer without a cast drivers/crypto/hifn_795x.c:1469: warning: assignment makes pointer from integer without a cast drivers/crypto/hifn_795x.c:1472: warning: assignment makes pointer from integer without a cast drivers/crypto/hifn_795x.c: In function 'ablkcipher_get': drivers/crypto/hifn_795x.c:1593: warning: passing argument 1 of 'kmap_atomic' makes pointer from integer without a cast {standard input}: Assembler messages: {standard input}:7: Warning: setting incorrect section attributes for .got drivers/crypto/hifn_795x.c: In function 'hifn_process_ready': drivers/crypto/hifn_795x.c:1653: warning: passing argument 1 of 'kmap_atomic' makes pointer from integer without a cast drivers/crypto/hifn_795x.c: In function 'hifn_probe': drivers/crypto/hifn_795x.c:2438: error: 'DMA_32BIT_MASK' undeclared (first use in this function) drivers/crypto/hifn_795x.c:2438: error: (Each undeclared identifier is reported only once drivers/crypto/hifn_795x.c:2438: error: for each function it appears in.) drivers/crypto/hifn_795x.c:2443: warning: format '%d' expects type 'int', but argument 4 has type 'long int' drivers/crypto/hifn_795x.c:2443: warning: format '%d' expects type 'int', but argument 4 has type 'long int' Signed-off-by:Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Jan Glauber authored
The HIFN driver is currently selectable on s390 but wont compile. Since it looks like HIFN needs PCI make the Kconfig dependent on PCI, which is not available on s390. Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Acked-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
Evgeniy Polyakov authored
This patch forces HIFN driver to invoke crypto request callbacks from tasklet (softirq context) instead of hardirq context, since network stack expects it to be called from bottom halves. It is done by simply scheduling callback invocation via dedicated tasklet. Workqueue solution was dropped because of tooo slow rescheduling performance (7 times slower than tasklet, for mode details one can check this link: http://tservice.net.ru/~s0mbre/blog/devel/other/2007_11_09.html). Driver passed all AES and DES tests in tcryt.c module. Signed-off-by:
-
Jonathan Lynch authored
Resubmitting this patch which extends sha256_generic.c to support SHA-224 as described in FIPS 180-2 and RFC 3874. HMAC-SHA-224 as described in RFC4231 is then supported through the hmac interface. Patch includes test vectors for SHA-224 and HMAC-SHA-224. SHA-224 chould be chosen as a hash algorithm when 112 bits of security strength is required. Patch generated against the 2.6.24-rc1 kernel and tested against 2.6.24-rc1-git14 which includes fix for scatter gather implementation for HMAC. Signed-off-by:
Jonathan Lynch <jonathan.lynch@intel.com> Signed-off-by:
-
Sebastian Siewior authored
The Geode AES crypto engine supports only 128 bit long key. This patch adds fallback for other key sizes which are required by the AES standard. Signed-off-by:
Sebastian Siewior <sebastian@breakpoint.cc> Acked-by:
Jordan Crouse <jordan.crouse@amd.com> Signed-off-by:
-
Sebastian Siewior authored
The setkey() function can be shared with the generic algorithm. Signed-off-by:
-
Sebastian Siewior authored
NO other block mode is M by default. Signed-off-by:
-
Sebastian Siewior authored
The setkey() function can be shared with the generic algorithm. Signed-off-by:
-
Sebastian Siewior authored
This patch exports four tables and the set_key() routine. This ressources can be shared by other AES implementations (aes-x86_64 for instance). The decryption key has been turned around (deckey[0] is the first piece of the key instead of deckey[keylen+20]). The encrypt/decrypt functions are looking now identical (except they are using different tables and key). Signed-off-by:
-
Sebastian Siewior authored
Signed-off-by:
-
Joy Latten authored
This patch adds countersize to CTR mode. The template is now ctr(algo,noncesize,ivsize,countersize). For example, ctr(aes,4,8,4) indicates the counterblock will be composed of a salt/nonce that is 4 bytes, an iv that is 8 bytes and the counter is 4 bytes. When noncesize + ivsize < blocksize, CTR initializes the last block - ivsize - noncesize portion of the block to zero. Otherwise the counter block is composed of the IV (and nonce if necessary). If noncesize + ivsize == blocksize, then this indicates that user is passing in entire counterblock. Thus countersize indicates the amount of bytes in counterblock to use as the counter for incrementing. CTR will increment counter portion by 1, and begin encryption with that value. Note that CTR assumes the counter portion of the block that will be incremented is stored in big endian. Signed-off-by:
Joy Latten <latten@austin.ibm.com> Signed-off-by:
-
Denys Vlasenko authored
Move huge unrolled pieces of code (3 screenfuls) at the end of 128/256 key setup routines into common camellia_setup_tail(), convert it to loop there. Loop is still unrolled six times, so performance hit is very small, code size win is big. Signed-off-by:
Denys Vlasenko <vda.linux@googlemail.com> Acked-by:
Noriaki TAKAMIYA <takamiya@po.ntts.co.jp> Signed-off-by:
-
Denys Vlasenko authored
Optimize GETU32 to use 4-byte memcpy (modern gcc will convert such memcpy to single move instruction on i386). Original GETU32 did four byte fetches, and shifted/XORed those. Signed-off-by:
-
Denys Vlasenko authored
Rename some macros to shorter names: CAMELLIA_RR8 -> ROR8, making it easier to understand that it is just a right rotation, nothing camellia-specific in it. CAMELLIA_SUBKEY_L() -> SUBKEY_L() - just shorter. Move be32 <-> cpu conversions out of en/decrypt128/256 and into camellia_en/decrypt - no reason to have that code duplicated twice. Signed-off-by:
-
Denys Vlasenko authored
Move code blocks around so that related pieces are closer together: e.g. CAMELLIA_ROUNDSM macro does not need to be separated from the rest of the code by huge array of constants. Remove unused macros (COPY4WORD, SWAP4WORD, XOR4WORD[2]) Drop SUBL(), SUBR() macros which only obscure things. Same for CAMELLIA_SP1110() macro and KEY_TABLE_TYPE typedef. Remove useless comments: /* encryption */ -- well it's obvious enough already! void camellia_encrypt128(...) Combine swap with copying at the beginning/end of encrypt/decrypt. Signed-off-by:
-
Denys Vlasenko authored
Currently twofish cipher key setup code has unrolled loops - approximately 70-100 instructions are repeated 40 times. As a result, twofish module is the biggest module in crypto/*. Unrolling produces x2.5 more code (+18k on i386), and speeds up key setup by 7%: unrolled: twofish_setkey/sec: 41128 loop: twofish_setkey/sec: 38148 CALC_K256: ~100 insns each CALC_K192: ~90 insns CALC_K: ~70 insns Attached patch removes this unrolling. $ size */twofish_common.o text data bss dec hex filename 37920 0 0 37920 9420 crypto.org/twofish_common.o 13209 0 0 13209 3399 crypto/twofish_common.o Run tested (modprobe tcrypt reports ok). Please apply. Signed-off-by:
-
Sebastian Siewior authored
This patch moves macros in geode-aes.c into geode-aes.h. Signed-off-by:
-
Sebastian Siewior authored
The code waits in a busy loop until the hardware finishes the encryption or decryption process. This wants a cpu_relax() :) The busy loop finishes either if the encryption is done or if the counter is zero. If the latter is true than the hardware failed. Since this should not happen, leave sith a BUG(). Signed-off-by:
-
Sebastian Siewior authored
It is enough if the IV is copied before and after the while loop. With DM-Crypt is seems not be required to save the IV after encrytion because a new one is used in the request (dunno about other users). It is not save to load the IV within while loop and not save afterwards because we mill end up with the wrong IV if the request goes consists of more than one page. Signed-off-by:
-
Sebastian Siewior authored
This three defines are used in all AES related hardware. Signed-off-by:
-
Sebastian Siewior authored
alias isn't required because the module provides PCI ids. Signed-off-by:
-
Evgeniy Polyakov authored
HIFN driver update to use DES weak key checks (exported in this patch). Signed-off-by:
-
Evgeniy Polyakov authored
This patch creates include/crypto/des.h for common macros shared between DES implementations. Signed-off-by:
-
Evgeniy Polyakov authored
This is a driver for HIFN 795x crypto accelerator chips. It passed all tests for AES, DES and DES3_EDE except weak test for DES, since hardware can not determine weak keys. Signed-off-by:
-
Joy Latten authored
This patch implements CTR mode for IPsec. It is based off of RFC 3686. Please note: 1. CTR turns a block cipher into a stream cipher. Encryption is done in blocks, however the last block may be a partial block. A "counter block" is encrypted, creating a keystream that is xor'ed with the plaintext. The counter portion of the counter block is incremented after each block of plaintext is encrypted. Decryption is performed in same manner. 2. The CTR counterblock is composed of, nonce + IV + counter The size of the counterblock is equivalent to the blocksize of the cipher. sizeof(nonce) + sizeof(IV) + sizeof(counter) = blocksize The CTR template requires the name of the cipher algorithm, the sizeof the nonce, and the sizeof the iv. ctr(cipher,sizeof_nonce,sizeof_iv) So for example, ctr(aes,4,8) specifies the counterblock will be composed of 4 bytes from a nonce, 8 bytes from the iv, and 4 bytes for counter since aes has a blocksize of 16 bytes. 3. The counter portion of the counter block is stored in big endian for conformance to rfc 3686. Signed-off-by: -
Herbert Xu authored
The previous patch fixed spurious read faults from occuring by copying the data if we happen to have a single block at the end of a page. It appears that gcc cannot guarantee 16-byte alignment in the kernel with __attribute__. The following report from Torben Viets shows a buffer that's only 8-byte aligned: > eneral protection fault: 0000 [#1] > Modules linked in: xt_TCPMSS xt_tcpmss iptable_mangle ipt_MASQUERADE > xt_tcpudp xt_mark xt_state iptable_nat nf_nat nf_conntrack_ipv4 > iptable_filter ip_tables x_tables pppoe pppox af_packet ppp_generic slhc > aes_i586 > CPU: 0 > EIP: 0060:[<c035b828>] Not tainted VLI > EFLAGS: 00010292 (2.6.23.12 #7) > EIP is at aes_crypt_copy+0x28/0x40 > eax: f7639ff0 ebx: f6c24050 ecx: 00000001 edx: f6c24030 > esi: f7e89dc8 edi: f7639ff0 ebp: 00010000 esp: f7e89dc8 Since the hardware must have 16-byte alignment, the following patch fixes this by open coding the alignment adjustment. Signed-off-by:
-
- 28 Dec, 2007 1 commit
-
-
Herbert Xu authored
The xcryptecb instruction always processes an even number of blocks so we need to ensure th existence of an extra block if we have to process an odd number of blocks. Signed-off-by:
-
- 23 Nov, 2007 2 commits
-
-
Herbert Xu authored
As it is crypto_remove_spawn may try to unregister an instance which is yet to be registered. This patch fixes this by checking whether the instance has been registered before attempting to remove it. It also removes a bogus cra_destroy check in crypto_register_instance as 1) it's outside the mutex; 2) we have a check in __crypto_register_alg already. Signed-off-by: -
Herbert Xu authored
It seems that newer versions of gcc have regressed in their abilities to analyse initialisations. This patch moves the initialisations up to avoid the warnings. Signed-off-by:
-
- 17 Nov, 2007 8 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86Linus Torvalds authored
* 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86: x86: simplify "make ARCH=x86" and fix kconfig all.config x86: reboot fixup for wrap2c board x86: check boundary in count setup resource x86: fix reboot with no keyboard attached x86: add hpet sanity checks x86: on x86_64, correct reading of PC RTC when update in progress in time_64.c x86: fix freeze in x86_64 RTC update code in time_64.c ntp: fix typo that makes sync_cmos_clock erratic Remove x86 merge artifact from top Makefile x86: fixup cpu_info array conversion x86: show cpuinfo only for online CPUs x86: fix cpu-hotplug regression x86: ignore the sys_getcpu() tcache parameter x86: voyager use correct header file name x86: fix smp init sections x86: fix voyager_cat_init section x86: fix bogus memcpy in es7000_check_dsdt()
-
Sam Ravnborg authored
Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in all.config. For a fix the diffstat is nice: 6 files changed, 3 insertions(+), 36 deletions(-) The patch reverts these commits: - 0f855aa6 ("kconfig: add helper to set config symbol from environment variable") - 2a113281 ("kconfig: use $K64BIT to set 64BIT with all*config targets") Roman Zippel pointed out that kconfig supported string compares so the additional complexity introduced by the above two patches were not needed. With this patch we have following behaviour: # make {allno,allyes,allmod,rand}config [ARCH=...] option \ host arch | 32bit | 64bit ===================================================== ./. | 32bit | 64bit ARCH=x86 | 32bit | 32bit ARCH=i386 | 32bit | 32bit ARCH=x86_64 | 64bit | 64bit The general rule are that ARCH= and native architecture takes precedence over the configuration. So make ARCH=i386 [whatever] will always build a 32-bit kernel no matter what the configuration says. The configuration will be updated to 32-bit if it was configured to 64-bit and the other way around. This behaviour is consistent with previous behaviour so no suprises here. make ARCH=x86 will per default result in a 32-bit kernel but as the only ARCH= value x86 allow the user to select between 32-bit and 64-bit using menuconfig. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Herrmann <aherrman@arcor.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sam Ravnborg authored
Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in all.config. For a fix the diffstat is nice: 6 files changed, 3 insertions(+), 36 deletions(-) The patch reverts these commits: 0f855aa6 -> kconfig: add helper to set config symbol from environment variable 2a113281 -> kconfig: use $K64BIT to set 64BIT with all*config targets Roman Zippel pointed out that kconfig supported string compares so the additional complexity introduced by the above two patches were not needed. With this patch we have following behaviour: # make {allno,allyes,allmod,rand}config [ARCH=...] option \ host arch | 32bit | 64bit ===================================================== ./. | 32bit | 64bit ARCH=x86 | 32bit | 32bit ARCH=i386 | 32bit | 32bit ARCH=x86_64 | 64bit | 64bit The general rule are that ARCH= and native architecture takes precedence over the configuration. So make ARCH=i386 [whatever] will always build a 32-bit kernel no matter what the configuration says. The configuration will be updated to 32-bit if it was configured to 64-bit and the other way around. This behaviour is consistent with previous behaviour so no suprises here. make ARCH=x86 will per default result in a 32-bit kernel but as the only ARCH= value x86 allow the user to select between 32-bit and 64-bit using menuconfig. Signed-off-by:
-
Denys authored
Needed to make the wireless board, WRAP2C reboot. Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Yinghai Lu authored
need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so info->bus->resource[info->res_num] = res will not beyond of bus resource array when acpi returns too many resource entries. Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Gary Hade <gary.hade@us.ibm.com> Cc: Len Brown <lenb@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Truxton Fulton authored
Attempt to fix http://bugzilla.kernel.org/show_bug.cgi?id=8378 Hiroto Shibuya wrote to tell me that he has a VIA EPIA-EK10000 which suffers from the reboot problem when no keyboard is attached. My first patch works for him: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59f4e7d572980a521b7bdba74ab71b21f5995538 But the latest patch does not work for him : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8b93789808756bcc1e5c90c99f1b1ef52f839a51 We found that it was necessary to also set the "disable keyboard" flag in the command byte, as the first patch was doing. The second patch tries to minimally modify the command byte, but it is not enough. Please consider this simple one-line patch to help people with low end VIA motherboards reboot when no keyboard is attached. Hiroto Shibuya has verified that this works for him (as I no longer have an afflicted machine). Additional discussion: Note that original patch from Truxton DOES disable keyboard and this has been in main tree since 2.6.14, thus it must have quite a bit of air time already. http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.14.y.git;a=commit;h=59f4e7d572980a521b7bdba74ab71b21f5995538 Note that he only mention "System flag" in the description and comment, but in the code, "disable keyboard" flag is set. outb(0x14, 0x60); /* set "System flag" */ In 2.6.23, he made a change to read the current byte and then mask the flags, but along this change, he only set the "System flag" and dropped the setting of "disable keyboard" flag. http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commit;h=8b93789808756bcc1e5c90c99f1b1ef52f839a51 outb(cmd | 0x04, 0x60); /* set "System flag" */ So my request is to restore the setting of disable keyboard flag which has been there since 2.6.14 but disappeared in 2.6.23. Cc: Lee Garrett <lee-in-berlin@web.de> Cc: "Hiroto Shibuya" <hiroto.shibuya@gmail.com> Cc: Natalie Protasevich <protasnb@gmail.com> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Ingo Molnar <mingo@elte.hu> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Aristeu Rozanski <aris@ruivo.org> Cc: <stable@kernel.org> Signed-off-by:
-
Thomas Gleixner authored
Some BIOSes advertise HPET at 0x0. We really do no want to allocate a resource there. Check for it and leave early. Other BIOSes tell us the HPET is at 0xfed0000000000000 instead of 0xfed00000. Add a check and fix it up with a warning on user request. Signed-off-by: -
David P. Reed authored
Correct potentially unstable PC RTC time register reading in time_64.c Stop the use of an incorrect technique for reading the standard PC RTC timer, which is documented to "disconnect" time registers from the bus while updates are in progress. The use of UIP flag while interrupts are disabled to protect a 244 microsecond window is one of the Motorola spec sheet's documented ways to read the RTC time registers reliably. tglx: removed locking changes from original patch, as they gain nothing (read_persistent_clock is only called during boot, suspend, resume - so no hot path affected) and conflict with the paravirt locking scheme (see 32bit code), which we do not want to complicate for no benefit. Signed-off-by:
David P. Reed <dpreed@reed.com> Signed-off-by:
-
