This patch set adds support for
- dt-binding docs for Xilinx ZynqMP SHA3 driver
- Adds communication layer support for sha_hash in zynqmp.c
- Adds Xilinx ZynqMP driver for SHA3 Algorithm
- Adds device tree node for ZynqMP SHA3 driver
V3 Changes :
- Removed zynqmp_sha_import and export APIs.The reason as follows
The user space code does an accept on an already accepted FD
when we create AF_ALG socket and call accept on it,
it calls af_alg_accept and not hash_accept.
import and export APIs are called from hash_accept.
The flow is as below
accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_nokey
for hash salg_type.
- Resolved comments from
https://patchwork.kernel.org/patch/10753719/
V2 Changes :
- Added new patch (2/4) for sha_hash zynqmp API support
- Incorporated code review comments from v1 patch series. Discussed below:
https://lore.kernel.org/patchwork/patch/1029433/
Kalyani Akula (4):
dt-bindings: crypto: Add bindings for ZynqMP SHA3 driver
firmware: xilinx: Add ZynqMP sha_hash API for SHA3 functionality
crypto: Add Xilinx SHA3 driver
ARM64: zynqmp: Add Xilinix SHA-384 node.
.../devicetree/bindings/crypto/zynqmp-sha.txt | 12 ++
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 +
drivers/crypto/Kconfig | 10 +
drivers/crypto/Makefile | 1 +
drivers/crypto/zynqmp-sha.c | 240 +++++++++++++++++++++
drivers/firmware/xilinx/zynqmp.c | 27 +++
include/linux/firmware/xlnx-zynqmp.h | 2 +
7 files changed, 296 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/zynqmp-sha.txt
create mode 100644 drivers/crypto/zynqmp-sha.c
--
1.9.5
On Thu, May 02, 2019 at 04:04:38PM +0530, Kalyani Akula wrote:
> This patch set adds support for
> - dt-binding docs for Xilinx ZynqMP SHA3 driver
> - Adds communication layer support for sha_hash in zynqmp.c
> - Adds Xilinx ZynqMP driver for SHA3 Algorithm
> - Adds device tree node for ZynqMP SHA3 driver
>
> V3 Changes :
> - Removed zynqmp_sha_import and export APIs.The reason as follows
> The user space code does an accept on an already accepted FD
> when we create AF_ALG socket and call accept on it,
> it calls af_alg_accept and not hash_accept.
> import and export APIs are called from hash_accept.
> The flow is as below
> accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_nokey
> for hash salg_type.
> - Resolved comments from
> https://patchwork.kernel.org/patch/10753719/
>
Your driver still doesnt handle the case where two hash are done in parallel.
Furthermore, you miss the export/import functions.
Regards
Hi Corentin,
Please find my response inline.
> -----Original Message-----
> From: Corentin Labbe <[email protected]>
> Sent: Thursday, May 2, 2019 5:30 PM
> To: Kalyani Akula <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Sarat Chand Savitala <[email protected]>; Kalyani
> Akula <[email protected]>
> Subject: Re: [RFC PATCH V3 0/4] Add Xilinx's ZynqMP SHA3 driver support
>
> On Thu, May 02, 2019 at 04:04:38PM +0530, Kalyani Akula wrote:
> > This patch set adds support for
> > - dt-binding docs for Xilinx ZynqMP SHA3 driver
> > - Adds communication layer support for sha_hash in zynqmp.c
> > - Adds Xilinx ZynqMP driver for SHA3 Algorithm
> > - Adds device tree node for ZynqMP SHA3 driver
> >
> > V3 Changes :
> > - Removed zynqmp_sha_import and export APIs.The reason as follows The
> > user space code does an accept on an already accepted FD when we
> > create AF_ALG socket and call accept on it, it calls af_alg_accept and
> > not hash_accept.
> > import and export APIs are called from hash_accept.
> > The flow is as below
> > accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_noke
> > accept--> y
> > for hash salg_type.
> > - Resolved comments from
> > https://patchwork.kernel.org/patch/10753719/
> >
>
>
> Your driver still doesnt handle the case where two hash are done in parallel.
>
Our Firmware uses IPI protocol to send this SHA3 requests to SHA3 HW engine, which doesn't support parallel processing of 2 hash requests.
The flow is
SHA3 request from App -> SHA3 driver-> ZynqMp driver-> Firmware (which doesn't support parallel processing of 2 requests) -> SHA3 HW Engine
> Furthermore, you miss the export/import functions.
>
When user space code does an accept on an already accepted FD as below
sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(sockfd, (struct sockaddr *)&sa, sizeof(sa));
fd = accept(sockfd, NULL, 0);
where my sockaddr is
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "hash",
.salg_name = "xilinx-sha3-384"
};
Upon calling accept the flow in the kernel is as mentioned
accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_nokey
for hash salg_type.
And where import and export functions are called from hash_accept. hence, these functions never be called from the application.
So, I removed those from the driver.
Regards
Kalyani.
> Regards
On Thu, May 02, 2019 at 03:12:55PM +0000, Kalyani Akula wrote:
> Hi Corentin,
>
> Please find my response inline.
>
> > -----Original Message-----
> > From: Corentin Labbe <[email protected]>
> > Sent: Thursday, May 2, 2019 5:30 PM
> > To: Kalyani Akula <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected];
> > [email protected]; Sarat Chand Savitala <[email protected]>; Kalyani
> > Akula <[email protected]>
> > Subject: Re: [RFC PATCH V3 0/4] Add Xilinx's ZynqMP SHA3 driver support
> >
> > On Thu, May 02, 2019 at 04:04:38PM +0530, Kalyani Akula wrote:
> > > This patch set adds support for
> > > - dt-binding docs for Xilinx ZynqMP SHA3 driver
> > > - Adds communication layer support for sha_hash in zynqmp.c
> > > - Adds Xilinx ZynqMP driver for SHA3 Algorithm
> > > - Adds device tree node for ZynqMP SHA3 driver
> > >
> > > V3 Changes :
> > > - Removed zynqmp_sha_import and export APIs.The reason as follows The
> > > user space code does an accept on an already accepted FD when we
> > > create AF_ALG socket and call accept on it, it calls af_alg_accept and
> > > not hash_accept.
> > > import and export APIs are called from hash_accept.
> > > The flow is as below
> > > accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_noke
> > > accept--> y
> > > for hash salg_type.
> > > - Resolved comments from
> > > https://patchwork.kernel.org/patch/10753719/
> > >
> >
> >
> > Your driver still doesnt handle the case where two hash are done in parallel.
> >
>
> Our Firmware uses IPI protocol to send this SHA3 requests to SHA3 HW engine, which doesn't support parallel processing of 2 hash requests.
> The flow is
> SHA3 request from App -> SHA3 driver-> ZynqMp driver-> Firmware (which doesn't support parallel processing of 2 requests) -> SHA3 HW Engine
>
>
So your driver will just send bad result in that case.
You need to export and store the intermediate result in a request context.
> > Furthermore, you miss the export/import functions.
> >
>
> When user space code does an accept on an already accepted FD as below
> sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
> bind(sockfd, (struct sockaddr *)&sa, sizeof(sa));
> fd = accept(sockfd, NULL, 0);
>
> where my sockaddr is
> struct sockaddr_alg sa = {
> .salg_family = AF_ALG,
> .salg_type = "hash",
> .salg_name = "xilinx-sha3-384"
> };
>
> Upon calling accept the flow in the kernel is as mentioned
> accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_nokey
> for hash salg_type.
>
> And where import and export functions are called from hash_accept. hence, these functions never be called from the application.
> So, I removed those from the driver.
>
> Regards
> Kalyani.
>
Handling your own worflow is not enough.
You need to support two client doing multiple update in parallel.
It seems that your driver is bugged in that case.
Furthermore, i am pretty sure that export and import are mandatory, and without them self-test should fail.
Do you have self test enabled and tryed to load the tcrypt module ?
Regards