Wrong assumptions about return values of hifn_crypto()?

["Daniel Zebralla (A.P.E. IT-Security - Hard- & Software Development)" <D.Zebralla%ape-net.com@localhost>]

During code review of the hifn(4) driver, we fell over the following code In 
hifn7751.c (rev. 1.37):

   2383     err = hifn_crypto(sc, cmd, crp, hint);
   2384     if (err == 0) {
   2385           if (enccrd)
   2386                 sc->sc_sessions[session].hs_prev_op =
   2387                      enccrd->crd_flags & CRD_F_ENCRYPT;
   2388           if (sc->sc_sessions[session].hs_state == HS_STATE_USED)
   2389                 sc->sc_sessions[session].hs_state = HS_STATE_KEY;
   2390           return 0;
   2391     } else if (err == ERESTART) {
   2392           /*
   2393            * There weren't enough resources to dispatch the request
   2394            * to the part.  Notify the caller so they'll requeue this
   2395            * request and resubmit it again soon.
   2396            */
   2397 #ifdef HIFN_DEBUG
   2398           if (hifn_debug)
   2399                 printf(device_xname(&sc->sc_dv), "requeue request\n");
   2400 #endif
   2401           free(cmd, M_DEVBUF);
   2402           sc->sc_needwakeup |= CRYPTO_SYMQ;
   2403           return (err);
   2404     }

We're wondering if the else-part of this code snippet is ever reached, as 
hifn_crypto() only returns either EINVAL (defined in errno.h as 22), ENOMEM 
(defined in errno.h as 12) or 0. ERESTART however is defined inside errno.h 
with -3.

So is it intended that the else-branch never gets executed?

On a side-note:
hifn7751var.h contains the following (rev 1.2.2.5):

    296 /*
    297  *  Return values for hifn_crypto()
    298  */
    299 #define HIFN_CRYPTO_SUCCESS 0
    300 #define HIFN_CRYPTO_BAD_INPUT    (-1)
    301 #define HIFN_CRYPTO_RINGS_FULL   (-2)
    302 

    317  *  Return Values
    318  *  =============
    319  *  0 for success, negative values on error
    320  *

The return values defined here are never used inside hifn_crypto(). Also, the 
error values actually returned (ENOMEM and EINVAL) are not negative although 
line 319 states that hifn_crypto() returns 0 for success and negative values on 
error. It seems to us that there's a lack of consistency there.

Can someone please clarify if all the relevant errors are actually caught here?

As background: we see hangs of a hifn-based card in a system after about half 
an hour of operation, and wonder where that comes from. 

Please put me in CC on answers to @tech-crypto as I'm only subscribed to 
@tech-net.

Kind regards,
Daniel


A.P.E. GmbH
Daniel Zebralla
Hard- & Software Development
Galgenbergstraße 2a - Posthof
93053 Regensburg - Germany
Telefon +49 (941) 78385-460
Telefax +49 (941) 78385-150
D.Zebralla%ape-net.com@localhost
http://www.ape-net.com

_______________________________________

A.P.E. GmbH  IT-Security
Sitz der Gesellschaft: Regensburg
Handelsregister: HRB 5953, Regensburg
Geschäftsführer: Dr. Dieter Steiner