Herbert,
I wonder if you can clear something up about the hash export/import
functionality. In:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/344120.html
you seem to imply that the exported and imported state can't be defined
by the driver.
Boris tells me, "AFAIR, crypto users are expecting md5/sha1/sha256_state
depending on the crypto req state they are exporting".
>From what I can see, there is only one place in the core crypto code
where hash state is exported and imported, and that's in hash_accept(),
and that's always done with the same driver. The only other place is
in the marvell cesa driver itself when initialising the hmac state.
Is there any reason a driver can't define its own structure to be
exported here which can be shared between each of the different methods
it supports?
Thanks.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Sun, 11 Oct 2015 20:34:27 +0100
Russell King - ARM Linux <[email protected]> wrote:
> Herbert,
>
> I wonder if you can clear something up about the hash export/import
> functionality. In:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/344120.html
>
> you seem to imply that the exported and imported state can't be defined
> by the driver.
>
> Boris tells me, "AFAIR, crypto users are expecting md5/sha1/sha256_state
> depending on the crypto req state they are exporting".
Actually, this was my interpretation of Herbert's answer to this driver
submission [1], but maybe I completely misunderstood his point.
>
> From what I can see, there is only one place in the core crypto code
> where hash state is exported and imported, and that's in hash_accept(),
> and that's always done with the same driver. The only other place is
> in the marvell cesa driver itself when initialising the hmac state.
>
> Is there any reason a driver can't define its own structure to be
> exported here which can be shared between each of the different methods
> it supports?
>
> Thanks.
>
[1]http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/344120.html
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
On Sun, Oct 11, 2015 at 08:34:27PM +0100, Russell King - ARM Linux wrote:
> Herbert,
>
> I wonder if you can clear something up about the hash export/import
> functionality. In:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/344120.html
>
> you seem to imply that the exported and imported state can't be defined
> by the driver.
>
> Boris tells me, "AFAIR, crypto users are expecting md5/sha1/sha256_state
> depending on the crypto req state they are exporting".
>
> From what I can see, there is only one place in the core crypto code
> where hash state is exported and imported, and that's in hash_accept(),
> and that's always done with the same driver. The only other place is
> in the marvell cesa driver itself when initialising the hmac state.
>
> Is there any reason a driver can't define its own structure to be
> exported here which can be shared between each of the different methods
> it supports?
A further question: it looks like struct md5_state's hash member is
always supposed to be in little endian format, whereas struct
sha*_state's state is always big endian format. Is there a reason
why these are typed 'u32', rather than __le32 and __be32?
This would make the intention here more obvious, and should also allow
the opportunity for sparse to verify that we're getting the endianness
correct everywhere.
Thanks.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Sun, Oct 11, 2015 at 08:34:27PM +0100, Russell King - ARM Linux wrote:
>
> Is there any reason a driver can't define its own structure to be
> exported here which can be shared between each of the different methods
> it supports?
For algorithms in general you can use any format you like and there
is no restriction. However, for specific algorithms such as crc32c
and family there is a requirement to use a fixed format.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt