Discussion:
Wrong assumptions about return values of hifn_crypto()?
(too old to reply)
Daniel Zebralla \(A.P.E. IT-Security - Hard- & Software Development\)
2010-06-07 13:58:06 UTC
Permalink
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
***@ape-net.com
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



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Thor Lancelot Simon
2010-06-08 15:08:44 UTC
Permalink
?? 2383 ??? err = hifn_crypto(sc, cmd, crp, hint);
?? 2384 ??? if (err == 0) {
Your message is basically unreadable with all this "?" in it. Could you
try resending it in a less crazed form?

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Matthew Mondor
2010-06-08 21:29:47 UTC
Permalink
On Tue, 8 Jun 2010 11:08:44 -0400
Post by Thor Lancelot Simon
?? 2383 ??? err = hifn_crypto(sc, cmd, crp, hint);
?? 2384 ??? if (err == 0) {
Your message is basically unreadable with all this "?" in it. Could you
try resending it in a less crazed form?
The Content-Encoding was Quoted-Printable with Content-Type Charset
ISO-8859-1 though, and my client could read it fine (even in a UTF-8
locale). Those 0xA0 (160, =A0 in quoted-printable) characters in
ISO-8859-1 are the non-breaking space...
--
Matt

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Daniel Zebralla \(A.P.E. IT-Security - Hard- & Software Development\)
2010-06-09 13:17:01 UTC
Permalink
Outlook and its interpretation of plain-text, I'm sorry.
I hope that this time everything looks ok. The numbers are
line numbers btw.

Greets,
Daniel

----------------------original mail---------------------------

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
***@ape-net.com
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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...