lists.openwall.net  lists / announce owlusers owldev johnusers johndev passwdqcusers yescrypt popa3dusers / osssecurity kernelhardening musl sabotage tlsify passwords / cryptdev xvendor / Bugtraq FullDisclosure linuxkernel linuxnetdev linuxext4 PHC  
Open Source and information security mailing list archives
 

Date: Wed, 18 Jan 2012 14:27:47 0800 From: "Darrick J. Wong" <djwong@...ibm.com> To: Andrew Morton <akpm@...uxfoundation.org>, Herbert Xu <herbert@...dor.apana.org.au>, "Darrick J. Wong" <djwong@...ibm.com> Cc: Theodore Tso <tytso@....edu>, Joakim Tjernlund <joakim.tjernlund@...nsmode.se>, Bob Pearson <rpearson@...temfabricworks.com>, linuxkernel <linuxkernel@...r.kernel.org>, Andreas Dilger <adilger.kernel@...ger.ca>, linuxcrypto <linuxcrypto@...r.kernel.org>, linuxfsdevel <linuxfsdevel@...r.kernel.org>, Mingming Cao <cmm@...ibm.com>, linuxext4@...r.kernel.org Subject: [PATCH 02/13] crc32: Move long comment about crc32 fundamentals to Documentation/ Moved a long comment from lib/crc32.c to Documentation/crc32.txt where it will more likely get read.  Edited the resulting document to add an explanation of the slicingbyn algorithm. From: Bob Pearson <rpearson@...temfabricworks.com> Signedoffby: George Spelvin <linux@...izon.com> Signedoffby: Bob Pearson <rpearson@...temfabricworks.com> [djwong@...ibm.com: Minor changelog tweaks] Signedoffby: Darrick J. Wong <djwong@...ibm.com>  Documentation/00INDEX  2 + Documentation/crc32.txt  183 +++++++++++++++++++++++++++++++++++++++++++++++ lib/crc32.c  129 + 3 files changed, 187 insertions(+), 127 deletions() create mode 100644 Documentation/crc32.txt diff git a/Documentation/00INDEX b/Documentation/00INDEX index 65bbd26..e7b38a0 100644  a/Documentation/00INDEX +++ b/Documentation/00INDEX @@ 104,6 +104,8 @@ cpuidle/  info on CPU_IDLE, CPU idle state management subsystem. cputopology.txt  documentation on how CPU topology info is exported via sysfs. +crc32.txt +  brief tutorial on CRC computation cris/  directory with info about Linux on CRIS architecture. crypto/ diff git a/Documentation/crc32.txt b/Documentation/crc32.txt new file mode 100644 index 0000000..3d74ba4  /dev/null +++ b/Documentation/crc32.txt @@ 0,0 +1,183 @@ +A brief CRC tutorial. + +A CRC is a longdivision remainder. You add the CRC to the message, +and the whole thing (message+CRC) is a multiple of the given +CRC polynomial. To check the CRC, you can either check that the +CRC matches the recomputed value, *or* you can check that the +remainder computed on the message+CRC is 0. This latter approach +is used by a lot of hardware implementations, and is why so many +protocols put the endofframe flag after the CRC. + +It's actually the same long division you learned in school, except that + We're working in binary, so the digits are only 0 and 1, and + When dividing polynomials, there are no carries. Rather than add and + subtract, we just xor. Thus, we tend to get a bit sloppy about + the difference between adding and subtracting. + +Like all division, the remainder is always smaller than the divisor. +To produce a 32bit CRC, the divisor is actually a 33bit CRC polynomial. +Since it's 33 bits long, bit 32 is always going to be set, so usually the +CRC is written in hex with the most significant bit omitted. (If you're +familiar with the IEEE 754 floatingpoint format, it's the same idea.) + +Note that a CRC is computed over a string of *bits*, so you have +to decide on the endianness of the bits within each byte. To get +the best errordetecting properties, this should correspond to the +order they're actually sent. For example, standard RS232 serial is +littleendian; the most significant bit (sometimes used for parity) +is sent last. And when appending a CRC word to a message, you should +do it in the right order, matching the endianness. + +Just like with ordinary division, you proceed one digit (bit) at a time. +Each step of the division, division, you take one more digit (bit) of the +dividend and append it to the current remainder. Then you figure out the +appropriate multiple of the divisor to subtract to being the remainder +back into range. In binary, this is easy  it has to be either 0 or 1, +and to make the XOR cancel, it's just a copy of bit 32 of the remainder. + +When computing a CRC, we don't care about the quotient, so we can +throw the quotient bit away, but subtract the appropriate multiple of +the polynomial from the remainder and we're back to where we started, +ready to process the next bit. + +A bigendian CRC written this way would be coded like: +for (i = 0; i < input_bits; i++) { + multiple = remainder & 0x80000000 ? CRCPOLY : 0; + remainder = (remainder << 1  next_input_bit()) ^ multiple; +} + +Notice how, to get at bit 32 of the shifted remainder, we look +at bit 31 of the remainder *before* shifting it. + +But also notice how the next_input_bit() bits we're shifting into +the remainder don't actually affect any decisionmaking until +32 bits later. Thus, the first 32 cycles of this are pretty boring. +Also, to add the CRC to a message, we need a 32bitlong hole for it at +the end, so we have to add 32 extra cycles shifting in zeros at the +end of every message, + +These details lead to a standard trick: rearrange merging in the +next_input_bit() until the moment it's needed. Then the first 32 cycles +can be precomputed, and merging in the final 32 zero bits to make room +for the CRC can be skipped entirely. This changes the code to: + +for (i = 0; i < input_bits; i++) { + remainder ^= next_input_bit() << 31; + multiple = (remainder & 0x80000000) ? CRCPOLY : 0; + remainder = (remainder << 1) ^ multiple; +} + +With this optimization, the littleendian code is particularly simple: +for (i = 0; i < input_bits; i++) { + remainder ^= next_input_bit(); + multiple = (remainder & 1) ? CRCPOLY : 0; + remainder = (remainder >> 1) ^ multiple; +} + +The most significant coefficient of the remainder polynomial is stored +in the least significant bit of the binary "remainder" variable. +The other details of endianness have been hidden in CRCPOLY (which must +be bitreversed) and next_input_bit(). + +As long as next_input_bit is returning the bits in a sensible order, we don't +*have* to wait until the last possible moment to merge in additional bits. +We can do it 8 bits at a time rather than 1 bit at a time: +for (i = 0; i < input_bytes; i++) { + remainder ^= next_input_byte() << 24; + for (j = 0; j < 8; j++) { + multiple = (remainder & 0x80000000) ? CRCPOLY : 0; + remainder = (remainder << 1) ^ multiple; + } +} + +Or in littleendian: +for (i = 0; i < input_bytes; i++) { + remainder ^= next_input_byte(); + for (j = 0; j < 8; j++) { + multiple = (remainder & 1) ? CRCPOLY : 0; + remainder = (remainder >> 1) ^ multiple; + } +} + +If the input is a multiple of 32 bits, you can even XOR in a 32bit +word at a time and increase the inner loop count to 32. + +You can also mix and match the two loop styles, for example doing the +bulk of a message byteatatime and adding bitatatime processing +for any fractional bytes at the end. + +To reduce the number of conditional branches, software commonly uses +the byteatatime table method, popularized by Dilip V. Sarwate, +"Computation of Cyclic Redundancy Checks via Table LookUp", Comm. ACM +v.31 no.8 (August 1998) p. 10081013. + +Here, rather than just shifting one bit of the remainder to decide +in the correct multiple to subtract, we can shift a byte at a time. +This produces a 40bit (rather than a 33bit) intermediate remainder, +and the correct multiple of the polynomial to subtract is found using +a 256entry lookup table indexed by the high 8 bits. + +(The table entries are simply the CRC32 of the given onebyte messages.) + +When space is more constrained, smaller tables can be used, e.g. two +4bit shifts followed by a lookup in a 16entry table. + +It is not practical to process much more than 8 bits at a time using this +technique, because tables larger than 256 entries use too much memory and, +more importantly, too much of the L1 cache. + +To get higher software performance, a "slicing" technique can be used. +See "High Octane CRC Generation with the Intel Slicingby8 Algorithm", +ftp://download.intel.com/technology/comms/perfnet/download/slicingby8.pdf + +This does not change the number of table lookups, but does increase +the parallelism. With the classic Sarwate algorithm, each table lookup +must be completed before the index of the next can be computed. + +A "slicing by 2" technique would shift the remainder 16 bits at a time, +producing a 48bit intermediate remainder. Rather than doing a single +lookup in a 65536entry table, the two high bytes are looked up in +two different 256entry tables. Each contains the remainder required +to cancel out the corresponding byte. The tables are different because the +polynomials to cancel are different. One has nonzero coefficients from +x^32 to x^39, while the other goes from x^40 to x^47. + +Since modern processors can handle many parallel memory operations, this +takes barely longer than a single table lookup and thus performs almost +twice as fast as the basic Sarwate algorithm. + +This can be extended to "slicing by 4" using 4 256entry tables. +Each step, 32 bits of data is fetched, XORed with the CRC, and the result +broken into bytes and looked up in the tables. Because the 32bit shift +leaves the loworder bits of the intermediate remainder zero, the +final CRC is simply the XOR of the 4 table lookups. + +But this still enforces sequential execution: a second group of table +lookups cannot begin until the previous groups 4 table lookups have all +been completed. Thus, the processor's load/store unit is sometimes idle. + +To make maximum use of the processor, "slicing by 8" performs 8 lookups +in parallel. Each step, the 32bit CRC is shifted 64 bits and XORed +with 64 bits of input data. What is important to note is that 4 of +those 8 bytes are simply copies of the input data; they do not depend +on the previous CRC at all. Thus, those 4 table lookups may commence +immediately, without waiting for the previous loop iteration. + +By always having 4 loads in flight, a modern superscalar processor can +be kept busy and make full use of its L1 cache. + +Two more details about CRC implementation in the real world: + +Normally, appending zero bits to a message which is already a multiple +of a polynomial produces a larger multiple of that polynomial. Thus, +a basic CRC will not detect appended zero bits (or bytes). To enable +a CRC to detect this condition, it's common to invert the CRC before +appending it. This makes the remainder of the message+crc come out not +as zero, but some fixed nonzero value. (The CRC of the inversion +pattern, 0xffffffff.) + +The same problem applies to zero bits prepended to the message, and a +similar solution is used. Instead of starting the CRC computation with +a remainder of 0, an initial remainder of all ones is used. As long as +you start the same way on decoding, it doesn't make a difference. + diff git a/lib/crc32.c b/lib/crc32.c index ffea0c9..c3ce94a 100644  a/lib/crc32.c +++ b/lib/crc32.c @@ 20,6 +20,8 @@ * Version 2. See the file COPYING for more details. */ +/* see: Documentation/crc32.txt for a description of algorithms */ + #include <linux/crc32.h> #include <linux/kernel.h> #include <linux/module.h> @@ 209,133 +211,6 @@ u32 __pure crc32_be(u32 crc, unsigned char const *p, size_t len) EXPORT_SYMBOL(crc32_le); EXPORT_SYMBOL(crc32_be); /*  * A brief CRC tutorial.  *  * A CRC is a longdivision remainder. You add the CRC to the message,  * and the whole thing (message+CRC) is a multiple of the given  * CRC polynomial. To check the CRC, you can either check that the  * CRC matches the recomputed value, *or* you can check that the  * remainder computed on the message+CRC is 0. This latter approach  * is used by a lot of hardware implementations, and is why so many  * protocols put the endofframe flag after the CRC.  *  * It's actually the same long division you learned in school, except that  *  We're working in binary, so the digits are only 0 and 1, and  *  When dividing polynomials, there are no carries. Rather than add and  * subtract, we just xor. Thus, we tend to get a bit sloppy about  * the difference between adding and subtracting.  *  * A 32bit CRC polynomial is actually 33 bits long. But since it's  * 33 bits long, bit 32 is always going to be set, so usually the CRC  * is written in hex with the most significant bit omitted. (If you're  * familiar with the IEEE 754 floatingpoint format, it's the same idea.)  *  * Note that a CRC is computed over a string of *bits*, so you have  * to decide on the endianness of the bits within each byte. To get  * the best errordetecting properties, this should correspond to the  * order they're actually sent. For example, standard RS232 serial is  * littleendian; the most significant bit (sometimes used for parity)  * is sent last. And when appending a CRC word to a message, you should  * do it in the right order, matching the endianness.  *  * Just like with ordinary division, the remainder is always smaller than  * the divisor (the CRC polynomial) you're dividing by. Each step of the  * division, you take one more digit (bit) of the dividend and append it  * to the current remainder. Then you figure out the appropriate multiple  * of the divisor to subtract to being the remainder back into range.  * In binary, it's easy  it has to be either 0 or 1, and to make the  * XOR cancel, it's just a copy of bit 32 of the remainder.  *  * When computing a CRC, we don't care about the quotient, so we can  * throw the quotient bit away, but subtract the appropriate multiple of  * the polynomial from the remainder and we're back to where we started,  * ready to process the next bit.  *  * A bigendian CRC written this way would be coded like:  * for (i = 0; i < input_bits; i++) {  * multiple = remainder & 0x80000000 ? CRCPOLY : 0;  * remainder = (remainder << 1  next_input_bit()) ^ multiple;  * }  * Notice how, to get at bit 32 of the shifted remainder, we look  * at bit 31 of the remainder *before* shifting it.  *  * But also notice how the next_input_bit() bits we're shifting into  * the remainder don't actually affect any decisionmaking until  * 32 bits later. Thus, the first 32 cycles of this are pretty boring.  * Also, to add the CRC to a message, we need a 32bitlong hole for it at  * the end, so we have to add 32 extra cycles shifting in zeros at the  * end of every message,  *  * So the standard trick is to rearrage merging in the next_input_bit()  * until the moment it's needed. Then the first 32 cycles can be precomputed,  * and merging in the final 32 zero bits to make room for the CRC can be  * skipped entirely.  * This changes the code to:  * for (i = 0; i < input_bits; i++) {  * remainder ^= next_input_bit() << 31;  * multiple = (remainder & 0x80000000) ? CRCPOLY : 0;  * remainder = (remainder << 1) ^ multiple;  * }  * With this optimization, the littleendian code is simpler:  * for (i = 0; i < input_bits; i++) {  * remainder ^= next_input_bit();  * multiple = (remainder & 1) ? CRCPOLY : 0;  * remainder = (remainder >> 1) ^ multiple;  * }  *  * Note that the other details of endianness have been hidden in CRCPOLY  * (which must be bitreversed) and next_input_bit().  *  * However, as long as next_input_bit is returning the bits in a sensible  * order, we can actually do the merging 8 or more bits at a time rather  * than one bit at a time:  * for (i = 0; i < input_bytes; i++) {  * remainder ^= next_input_byte() << 24;  * for (j = 0; j < 8; j++) {  * multiple = (remainder & 0x80000000) ? CRCPOLY : 0;  * remainder = (remainder << 1) ^ multiple;  * }  * }  * Or in littleendian:  * for (i = 0; i < input_bytes; i++) {  * remainder ^= next_input_byte();  * for (j = 0; j < 8; j++) {  * multiple = (remainder & 1) ? CRCPOLY : 0;  * remainder = (remainder << 1) ^ multiple;  * }  * }  * If the input is a multiple of 32 bits, you can even XOR in a 32bit  * word at a time and increase the inner loop count to 32.  *  * You can also mix and match the two loop styles, for example doing the  * bulk of a message byteatatime and adding bitatatime processing  * for any fractional bytes at the end.  *  * The only remaining optimization is to the byteatatime table method.  * Here, rather than just shifting one bit of the remainder to decide  * in the correct multiple to subtract, we can shift a byte at a time.  * This produces a 40bit (rather than a 33bit) intermediate remainder,  * but again the multiple of the polynomial to subtract depends only on  * the high bits, the high 8 bits in this case.  *  * The multiple we need in that case is the low 32 bits of a 40bit  * value whose high 8 bits are given, and which is a multiple of the  * generator polynomial. This is simply the CRC32 of the given  * onebyte message.  *  * Two more details: normally, appending zero bits to a message which  * is already a multiple of a polynomial produces a larger multiple of that  * polynomial. To enable a CRC to detect this condition, it's common to  * invert the CRC before appending it. This makes the remainder of the  * message+crc come out not as zero, but some fixed nonzero value.  *  * The same problem applies to zero bits prepended to the message, and  * a similar solution is used. Instead of starting with a remainder of  * 0, an initial remainder of all ones is used. As long as you start  * the same way on decoding, it doesn't make a difference.  */  #ifdef UNITTEST #include <stdlib.h>  To unsubscribe from this list: send the line "unsubscribe linuxext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomoinfo.html
Powered by blists  more mailing lists