linux-kernel - Re: [PATCH] dm: verity target

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]

Message-ID: <CABqD9hZh0yNq5FbC73qhmy3Xa-80ZygSxXAuxbcJEmJqi3K7dw@mail.gmail.com>
Date:	Thu, 10 Nov 2011 08:42:54 -0600
From:	Will Drewry <wad@...omium.org>
To:	Steffen Klassert <steffen.klassert@...unet.com>
Cc:	Mandeep Singh Baines <msb@...omium.org>,
	Alasdair G Kergon <agk@...hat.com>, dm-devel@...hat.com,
	Elly Jones <ellyjones@...omium.org>,
	Milan Broz <mbroz@...hat.com>,
	Olof Johansson <olofj@...omium.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dm: verity target

On Thu, Nov 10, 2011 at 1:44 AM, Steffen Klassert
<steffen.klassert@...unet.com> wrote:
> On Wed, Nov 09, 2011 at 09:18:10PM -0800, Mandeep Singh Baines wrote:
>>
>> + * TODO(wad): All hash storage memory is pre-allocated and freed once an
>> + * entire branch has been verified.
>> + */
>> +struct dm_bht {
>> +     /* Configured values */
>> +     int depth;  /* Depth of the tree including the root */
>> +     unsigned int block_count;  /* Number of blocks hashed */
>> +     unsigned int block_size;  /* Size of a hash block */
>> +     char hash_alg[CRYPTO_MAX_ALG_NAME];
>> +     unsigned char salt[DM_BHT_SALT_SIZE];
>> +
>> +     /* Computed values */
>> +     unsigned int node_count;  /* Data size (in hashes) for each entry */
>> +     unsigned int node_count_shift;  /* first bit set - 1 */
>> +     /* There is one per CPU so that verified can be simultaneous. */
>> +     struct hash_desc hash_desc[NR_CPUS];  /* Container for the hash alg */
>
> Please don't add a new user for the old hash interface. If the hashes can
> be done asynchronous you can use ahash, if not use shash. Both interfaces
> are reentrant, that's probaply what you want to have here. You don't
> need to have this in a per cpu manner.

I'll check out the two interfaces.  I didn't realize hash_desc was
deprecated specifically in favor of one of the others.  I'm interested
in seeing if it is possible to not keep a per-cpu desc though with the
other apis.  We do this now to avoid contention across multiple kernel
threads on crypto operations sharing the hash_desc (e.g., by wrapping
it in a mutex).

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/