Re: [Ocf-linux-users] [PATCH - EP80579 driver update patch]

[David M. <dav...@mc...>]

Jivin Kennedy, Brendan lays it down ...
> 
> 
> >-----Original Message-----
> >From: David McCullough [mailto:dav...@mc...]
> >
> >Jivin Kennedy, Brendan lays it down ...
> >> Hi Dave,
> >>
> >> Sorry for the slow response! I like the use of errno, but a few
> >questions:
> >>
> >> 1. Are similar changes going to be made for DSA sign/verify
> >functionality?
> >
> >I can do that if you want.
> >
> Yep, we would like those changes to be added, but the changes from my originally submitted patch are just suggestions at the end of the day ;)


Ok,  think I got them all in the attached patch.

> >> 2. It seems if the failure is in the driver(as oppose to OCF) for non
> >> algotithmic reasons, this will still show an algorithm fail. I think
> >the
> >> patch code is meant to do that, but:
> >
> >The "trace" from openssl should show whether it was hardware or OCF
> >complaining.
> >
> >> 3. If the issue was because of algorithm fail (not the hardware), then
> >the
> >> algorithm should not be run again in software (where essentially it
> >should
> >> fail there for the same reason). It just slows down response time..
> >
> >The reason it falls back to SW is that,  at least in my experience,  the
> >HW
> >has limitations that the SW versions often don't.
> >
> >So driver regularly fail these calls because there are too many bits in
> >this
> >or that operand.  If that is the case I would prefer that it was handled
> >in
> >SW and still worked myself. Esp. since if I was using openssl without
> >OCF
> >it would work.
> >
> >Also,  for the failure case, I don't mind a true failure to be slower.
> >I
> >don't know of many cases where the performance of the failure case is
> >critical,  but I am more than happy to consider it if you have a good
> >case :-)
> >
> 
> Hmm, denial of service attack based on many bogus connection attempts utilizing large keys? :)
> I can only guess, however I suppose some tuning of the code is required depending on driver use cases.
> 
> I agree that in the case where the hardware cannot handle the request, the operation should be run in software.
> However, I think the driver for that hardware should be able to detect any problems with input buffers etc. Also, detecting different error types can be useful in the above scenarios.
> 
> Of course, the final code changes are all up to you. If something doesn't suit enough OCF users to warrant a change, that is fair enough :)

You guys are using it,  that almost makes you the one who should decide.

I have cleaned up the error reporting and done a workover to make it all
predictable at least. I would like to do an OCF release,  so I will run with
this for now and if it isn't enough we can look at that again when the
issues are better known/understood.

Thanks,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org