fallback mechanism in HASH drivers implimentetion
Hi , I am trying to understand the SHA1 (asynchronous) driver , I am not really sure regarding below mentioned scenarios,please can some help me with this? #1: When driver needs to use fallback mechanism and how does it work? #2: when do driver needs to use methods like import/export ? BR, Srisowj -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: AW: Best way to align key in AES context
On 02/13/2015 08:49 AM, Markus Stockhausen wrote: > thanks for the tip. I will at least move the data definitions to the > beginning of > my structure. > > But while it sounds logical for data types that are directly created from > that > structure I'm unsure about a context. If I understand it correctly a context > is > dynamically allocated. Could it be possible that the start address is then > only > 4 bytes aligned? > > So I tried to dive into the magic of alignmask and contexts. This even > confuses > me a little bit more. Nearly all implementations in the crypto tree make use > of > alignmasks >= 3. I guess to be at least 4 bytes aligned. But when accessing > the > context they "only" use crypto_blkcipher_ctx(). This will just return the > context > address while crypto_blkcipher_ctx_aligned() seems to be the right place to > return a pointer that is aligned according to the predefined mask. > > Would you recommend to > > a) ignore alignmask and use only __aligned(8) for the structure > > b) to assume ctx will be automatically 8 bytes aligned regardless of > __aligned(8) > flag or cra_alignmask. So nothing to take care about. > > b) or to define structure without __aligned(8) but work with cra_alignmask=7. > I fear that this might impose alignment of input/output data to 8 too and > lead > to unneccessary memcpy() operations. > > Sorry for driving myself nuts but I want to understand if before I send > patches. In this case I think the best way is to define your algorithm with .cra_ctxsize = sizeof(struct ppc_aes_ctx) + 8, and then in enc/dec/setkey do struct ppc_aes_ctx *ctx = PTR_ALIGN(crypto_tfm_ctx(tfm), 8); and you don't need the __aligned(8) in the struct definition. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Understanding HASH(SHA) Driver implementation
Hi , I am trying to analyze Linux Kernel Crypto Interface with respective to hashing(ahash for SHA1 in particular) . I am looking at omap-sham.c/atmel-sha.c as reference,which is in open source linux/driver/crypto.I need some inputs in understanding following . #1: If It need to handle a scenario where in which multiple messages will be given to generate a digest/Hash message like below. Ex: Input Block = buffer1 + buffer2 + +buffern if I need to generate hash for Input Block(could be anything like a fwimage/file etc) , Then I ll split it into some buffers and I ll send it in chunks like buffer1,bffer2 etc to underlying crypto driver Hash( Input Block) = Hash(buffer1) + Hash(buffer2) + . + Hash( buffern) | | + . +| | | | sha_update(*) sha_update(*) sha_update(*) How is it possible to keep track/store intermediate Hash generated data like for buffer1,buffer2 etc ? #2: what is the need to have multiple structures like "*_sha_reqctx " and "*_sha_dev" ? As Per my understanding "*_sha_reqctx" structure is for generic Linux Kernel Crypto crypto context to interact with specific crypto request and "*_sha_dev" structure is for Hardware specific some thing like for any DMA related operations. BR, Srisowj -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: AW: Best way to align key in AES context
> Von: linux-crypto-ow...@vger.kernel.org
> [linux-crypto-ow...@vger.kernel.org]" im Auftrag von "Tadeusz Struk
> [tadeusz.st...@intel.com]
> Gesendet: Freitag, 13. Februar 2015 15:47
> An: Markus Stockhausen
> Cc: linux-crypto@vger.kernel.org
> Betreff: Re: AW: Best way to align key in AES context
>
> On 02/11/2015 02:28 AM, Markus Stockhausen wrote:
> > I want to ensure that the key data in an AES ctx structure is 8 byte aligned
> > to avoid aligment exceptions afterwards. Other fields don't need that
> > restriction. At the moment I'm using the following (ugly) implementation.
> >
> > struct ppc_aes_ctx {
> > u32 rounds;
> > u32 *key_enc;
> > u32 *key_dec;
> > char data[AES_MAX_KEYLENGTH * 2 + 8];
> > };
> > ...
> > char *ptr;
> > ptr = ctx->data;
> > ptr = PTR_ALIGN(ptr, 8);
> > ctx->key_enc = (u32 *)(ptr);
> > ctx->key_dec = (u32 *)(ptr + AES_MAX_KEYLENGTH);
> >
> > Can anyone show me the recommended way for doing that.
>
>
> You can use gcc attributes.
>
> struct ppc_aes_ctx {
> u8 key_enc[AES_MAX_KEYLENGTH];
> u8 key_dec[AES_MAX_KEYLENGTH];
> u32 rounds;
> } __aligned(8);
Hi Tadeusz,
thanks for the tip. I will at least move the data definitions to the beginning
of
my structure.
But while it sounds logical for data types that are directly created from that
structure I'm unsure about a context. If I understand it correctly a context is
dynamically allocated. Could it be possible that the start address is then only
4 bytes aligned?
So I tried to dive into the magic of alignmask and contexts. This even confuses
me a little bit more. Nearly all implementations in the crypto tree make use of
alignmasks >= 3. I guess to be at least 4 bytes aligned. But when accessing the
context they "only" use crypto_blkcipher_ctx(). This will just return the
context
address while crypto_blkcipher_ctx_aligned() seems to be the right place to
return a pointer that is aligned according to the predefined mask.
Would you recommend to
a) ignore alignmask and use only __aligned(8) for the structure
b) to assume ctx will be automatically 8 bytes aligned regardless of
__aligned(8)
flag or cra_alignmask. So nothing to take care about.
b) or to define structure without __aligned(8) but work with cra_alignmask=7.
I fear that this might impose alignment of input/output data to 8 too and lead
to unneccessary memcpy() operations.
Sorry for driving myself nuts but I want to understand if before I send patches.
Best regards.
Markus
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
Ãber das Internet versandte E-Mails können unter fremden Namen erstellt oder
manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine
rechtsverbindliche Willenserklärung.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
Vorstand:
Kadir Akin
Dr. Michael Höhnerbach
Vorsitzender des Aufsichtsrates:
Hans Kristian Langva
Registergericht: Amtsgericht Köln
Registernummer: HRB 52 497
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
e-mails sent over the internet may have been written under a wrong name or
been manipulated. That is why this message sent as an e-mail is not a
legally binding declaration of intention.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
executive board:
Kadir Akin
Dr. Michael Höhnerbach
President of the supervisory board:
Hans Kristian Langva
Registry office: district court Cologne
Register number: HRB 52 497
Re: AF_ALG interface not marking the end of the scatter-gather list
On 02/13/2015 05:43 AM, Stephan Mueller wrote: Am Donnerstag, 12. Februar 2015, 17:41:59 schrieb Tom Lendacky: Hi Tom, I was doing some testing of the CCP driver using the AF_ALG interface and encountered a BUG_ON statement during scatter-gather DMA mapping. In algif_skcipher.c, before submitting a request to the the Crypto API the input sg list is not updated to mark the last valid sg entry of the input data. So even if there is only a single valid sg entry, sg_nents returns 127 (the initial value used when creating the sg table). In the CCP driver, when making a call to dma_map_sg I supply the number of entries as returned by sg_nents. During this call, the sg elements that are not valid cause a BUG_ON statement to be hit. I've worked around the issue in skcipher_recvmsg by marking the last valid sg entry (sg_mark_end(sgl->sg + sgl->cur - 1)) just before the call to ablkcipher_request_set_crypt and then unmarking the entry after the return from af_alg_wait_for_completion (using sg_unmark_end). Is this an appropriate/valid solution for this issue? If so, I can submit a patch with the fix in algif_skcipher and algif_hash. There has been a patch around this issue -- see patch 0f477b655a524515ec9a263d70d51f460c05a161 Thanks for the pointer Stephan. I had been working with the main kernel tree where this patch hasn't been merged yet. Thanks, Tom Thanks, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: Best way to align key in AES context
On 02/11/2015 02:28 AM, Markus Stockhausen wrote:
> I want to ensure that the key data in an AES ctx structure is 8 byte aligned
> to avoid aligment exceptions afterwards. Other fields don't need that
> restriction. At the moment I'm using the following (ugly) implementation.
>
> struct ppc_aes_ctx {
> u32 rounds;
> u32 *key_enc;
> u32 *key_dec;
> char data[AES_MAX_KEYLENGTH * 2 + 8];
> };
> ...
> char *ptr;
> ptr = ctx->data;
> ptr = PTR_ALIGN(ptr, 8);
> ctx->key_enc = (u32 *)(ptr);
> ctx->key_dec = (u32 *)(ptr + AES_MAX_KEYLENGTH);
>
> Can anyone show me the recommended way for doing that.
You can use gcc attributes.
struct ppc_aes_ctx {
u8 key_enc[AES_MAX_KEYLENGTH];
u8 key_dec[AES_MAX_KEYLENGTH];
u32 rounds;
} __aligned(8);
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AF_ALG interface not marking the end of the scatter-gather list
Am Donnerstag, 12. Februar 2015, 17:41:59 schrieb Tom Lendacky: Hi Tom, > I was doing some testing of the CCP driver using the AF_ALG interface > and encountered a BUG_ON statement during scatter-gather DMA mapping. > > In algif_skcipher.c, before submitting a request to the the Crypto API > the input sg list is not updated to mark the last valid sg entry of the > input data. So even if there is only a single valid sg entry, sg_nents > returns 127 (the initial value used when creating the sg table). > > In the CCP driver, when making a call to dma_map_sg I supply the number > of entries as returned by sg_nents. During this call, the sg elements > that are not valid cause a BUG_ON statement to be hit. > > I've worked around the issue in skcipher_recvmsg by marking the last > valid sg entry (sg_mark_end(sgl->sg + sgl->cur - 1)) just before the > call to ablkcipher_request_set_crypt and then unmarking the entry after > the return from af_alg_wait_for_completion (using sg_unmark_end). > > Is this an appropriate/valid solution for this issue? If so, I can > submit a patch with the fix in algif_skcipher and algif_hash. There has been a patch around this issue -- see patch 0f477b655a524515ec9a263d70d51f460c05a161 > > Thanks, > Tom > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
