On Mon, 27 May 2019 at 12:43, Pascal Van Leeuwen
<pvanleeuwen@xxxxxxxxxxxxxxxx> wrote:
>
> > As I explained before, what appears synchronous to a single userland
> > process may look very differently from the OS and h/w perspective. But
> > of course, I take your point that h/w is not faster than the CPU in
> > the general case, and so care must be taken.
> >
> "Synchronous" in this context was referring to a use case where the
> application does a request and then *waits* for the result of that
> request before continuing.
> While "asynchronous" would refer to a case where the application fires
> off a request and then merrily goes off doing "other" things (which
> could be, but is not limited to, preparing and posting new requests).
>
> So I'm strictly viewing it from the applications' perspective here.
>
I understand that. But even if the application is synchronous, it does
not mean that the whole world stops and nothing is using the
accelerator in the mean time.
> > This is made worse by the priority scheme, which does not really
> > convery information like this.
> >
> Yes, the priority scheme is far too simplistic to cover all details
> regarding hardware acceleration. Which why we probably shouldn't use
> it to select hardware drivers at all.
>
> > > But then again that would still be too simplistic to select to best
> > > driver under all possible circumstances ... so why even bother.
> > >
> > > > flag for that. But even if that does happen, it doesn't mean you can
> > > > stop caring about zero length inputs :-)
> > > >
> > > If the selection of the hardware driver becomes explicit and not
> > > automatic, you could argue for a case where the driver does NOT have
> > > to implement all dark corners of the API. As, as a hardware vendor,
> > > we could simply recommend NOT to use it for application XYZ because
> > > it does things - like zero length messages - we don't support.
> > >
> >
> > Spoken like a true h/w guy :-)
> >
> Guilty as charged. I AM a true H/W guy and not a software engineer at all.
> But have you ever stopped to wonder WHY all hardware guys talk like that?
> Maybe, just maybe, they have a damn good reason to do so ...
>
Of course. And so do we. And that is why we meet in the middle to compromise.
> > Our crypto s/w stack and the storage, networking and other subsystems
> > that are layered on top of it are complex enough that we shouldn't try
> > to cater for non-compliant hardware. This is why you need to fix this
> > in your driver: to prevent the issue from leaking into other layers,
> > making it even more difficult to do testing and validation.
> >
> Now where am I suggesting that applications should cater for non-compliant
> hardware? I'm simply suggesting that you should NOT use the hardware for
> such an application at all. If you make it explicit, you can do that.
>
> And besides, who decides what is "compliant" and what the rules are?
If the algorithm in question is defined for zero length inputs, but
the h/w chooses not to implement that case, I think non-compliant is a
rather nice way to say 'broken'. I know there is a gradient here going
from hashes, AEADs to symmetric ciphers, but I think this applies to
all of them.
> Please keep in mind that existing hardware cannot be changed. So why
> wasn't the API designed around the limitations of *existing* hardware?
>From a software point of view, adding special cases for zero length
inputs amounts to what you are trying to avoid: using more 'silicon
area'.
Proper validation requires coverage based testing, i.e., that all
statements in a program can be proven to be exercised by some use
case, and produce the correct result.
This means that, if we have to add 'if (message_length > 0) { do this;
} else { do that; }' everywhere, we are moving the effort from your
corner to mine. Of course I am going to oppose to that :-)
> It can take several years for a hardware fix to reach the end user ...
>
While software implementations can sometimes be fixed quickly,
software APIs have *really* long lifetimes as well, especially in the
server space. And until you have reached sufficient coverage with your
updated API, you are stuck with both the old one and the new one, so
you have even more code to worry about.
So a crypto API where zero length inputs are not permitted or treated
specially is not the way to fix this.
> As for testing and validation: if the selection is explicit, then the
> responsibility for the testing and validation can move to the HW vendor.
>
I think the bottom line is still to fix the driver and be done with
it. I honestly don't care about what exactly your h/w supports, as
long as the driver that encapsulates it addresses the impedance
mismatch between what the h/w layer provides and what the upper layer
expects.
