linux-ext4 - Re: [PATCH v4] crc32c: Implement CRC32c with slicing-by-8 algorithm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 3 Oct 2011 17:55:10 -0700
From:	"Darrick J. Wong" <djwong@...ibm.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Mingming Cao <cmm@...ibm.com>,
	David Miller <davem@...emloft.net>,
	linux-crypto <linux-crypto@...r.kernel.org>,
	linux-ext4@...r.kernel.org,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Bob Pearson <rpearson@...temfabricworks.com>,
	Theodore Tso <tytso@....edu>
Subject: Re: [PATCH v4] crc32c: Implement CRC32c with slicing-by-8 algorithm

On Mon, Oct 03, 2011 at 09:35:13PM +0100, Herbert Xu wrote:
> On Mon, Oct 03, 2011 at 10:27:03PM +0200, Joakim Tjernlund wrote:
> >
> > > > Start from Bobs latest patches and add crc32c to lib/crc32.c
> > >
> > > If I did that, how should I handle patching in the hardware accelerated version
> > > on Intel systems?  That switcheroo ability seems to have been Herbert Xu's
> > > motivation for moving crc32c into crypto/ in the first place:
> > 
> > I don't know, I haven't looked at that problem. I suspect it moved because that
> > was the easiest solution. Having an identical impl. of crc32(only the table values differ)
> > in crypto compared to the one in lib is not the way forward though.
> 
> You can always get crypto/crc32c.c to use call helpers from
> lib/crc32.c.

So what I think I'm hearing is...

1. Apply Bob's slice-by-8 algorithm patch to regular crc32.
2. Adapt crc32's build code to generate crc32c as well.
3. Remove crypto/crc32c.c's implementation and have it wrap the code generated
   by #2.
4. Retain the current libcrc32c.  I guess if you don't configure CRYPTO and
   CRYPTO_CRC32C then it could also just reference the generated crc32c functions
   directly.

Is this a satisfactory way to move forward?

--D
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html