Re: [openssl.org #670] -fPIC flag missing for asm/des_enc-sparc.
Uhmm, which OpenSSL version are you talking about? I can't find des_enc-sparc.S anywhere in my copy of the 0.9.7 branch... [EMAIL PROTECTED] - Tue Jul 29 17:06:13 2003]: It is in the latest branch in crypto/des/asm (at least after make). It seems that my problem went away with an install of a newer gcc version or some other as... it seems that in the current snapshots the shared option for solaris does not work correctly. Compilation in crypto/des of gcc -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #668] Turn fallback off by default
The following patch adapts that already in #668 to leave software
fallback off except when explicitly requested, per Geoff Thorpe's
request.
--- openssl-0.9.7b.orig/crypto/engine/hw_ncipher.c 2002-12-12 17:41:34.0
+
+++ openssl-0.9.7b/crypto/engine/hw_ncipher.c 2003-09-29 14:15:49.0 +0100
@@ -154,6 +154,8 @@
#define HWCRHK_CMD_THREAD_LOCKING (ENGINE_CMD_BASE + 2)
#define HWCRHK_CMD_SET_USER_INTERFACE (ENGINE_CMD_BASE + 3)
#define HWCRHK_CMD_SET_CALLBACK_DATA(ENGINE_CMD_BASE + 4)
+#define HWCRHK_CMD_FALLBACK_RSA (ENGINE_CMD_BASE + 5)
+#define HWCRHK_CMD_FALLBACK_MODEXP (ENGINE_CMD_BASE + 6)
static const ENGINE_CMD_DEFN hwcrhk_cmd_defns[] = {
{HWCRHK_CMD_SO_PATH,
SO_PATH,
@@ -175,6 +177,14 @@
SET_CALLBACK_DATA,
Set the global user interface extra data (internal),
ENGINE_CMD_FLAG_INTERNAL},
+ {HWCRHK_CMD_FALLBACK_RSA,
+ FALLBACK_RSA,
+ Fallback to software RSA if hardware fails (boolean),
+ ENGINE_CMD_FLAG_NUMERIC},
+ {HWCRHK_CMD_FALLBACK_MODEXP,
+ FALLBACK_MODEXP,
+ Fallback to software modexp if hardware fails (boolean),
+ ENGINE_CMD_FLAG_NUMERIC},
{0, NULL, NULL, 0}
};
@@ -516,6 +526,7 @@
#endif
HWCryptoHook_RandomBytes_t *p8;
HWCryptoHook_ModExpCRT_t *p9;
+ const char *fallback;
if(hwcrhk_dso != NULL)
{
@@ -595,6 +606,14 @@
}
}
+ /* Enable software fallback unless explicitly disabled (may also use
+* control commands). */
+ fallback = getenv(OPENSSL_NCIPHER_FALLBACK);
+ if (fallback (0 == strcmp(fallback, on)))
+ hwcrhk_globals.flags |=
+ HWCryptoHook_InitFlags_FallbackRSAImmed |
+ HWCryptoHook_InitFlags_FallbackModExp;
+
/* Try and get a context - if not, we may have a DSO but no
* accelerator! */
if(!get_context(hwcrhk_context, password_context))
@@ -728,6 +747,28 @@
~HWCryptoHook_InitFlags_SimpleForkCheck;
CRYPTO_w_unlock(CRYPTO_LOCK_ENGINE);
break;
+ /* These enable or disable initialisation structure flags allowing
+* fallback to software computation. */
+ case HWCRHK_CMD_FALLBACK_RSA:
+ CRYPTO_w_lock(CRYPTO_LOCK_ENGINE);
+ if(i)
+ hwcrhk_globals.flags |=
+ HWCryptoHook_InitFlags_FallbackRSAImmed;
+ else
+ hwcrhk_globals.flags =
+ ~HWCryptoHook_InitFlags_FallbackRSAImmed;
+ CRYPTO_w_unlock(CRYPTO_LOCK_ENGINE);
+ break;
+ case HWCRHK_CMD_FALLBACK_MODEXP:
+ CRYPTO_w_lock(CRYPTO_LOCK_ENGINE);
+ if(i)
+ hwcrhk_globals.flags |=
+ HWCryptoHook_InitFlags_FallbackModExp;
+ else
+ hwcrhk_globals.flags =
+ ~HWCryptoHook_InitFlags_FallbackModExp;
+ CRYPTO_w_unlock(CRYPTO_LOCK_ENGINE);
+ break;
/* This will prevent the initialisation function from installing
* the mutex-handling callbacks, even if they are available from
* within the library (or were provided to the library from the
@@ -938,19 +979,13 @@
r-top = m_r.size / sizeof(BN_ULONG);
bn_fix_top(r);
+ if ((ret == HWCRYPTOHOOK_ERROR_FALLBACK)
+ (hwcrhk_globals.flags HWCryptoHook_InitFlags_FallbackModExp))
+ return ret;
+
if (ret 0)
{
- /* FIXME: When this error is returned, HWCryptoHook is
- telling us that falling back to software computation
- might be a good thing. */
- if(ret == HWCRYPTOHOOK_ERROR_FALLBACK)
- {
- HWCRHKerr(HWCRHK_F_HWCRHK_MOD_EXP,HWCRHK_R_REQUEST_FALLBACK);
- }
- else
- {
- HWCRHKerr(HWCRHK_F_HWCRHK_MOD_EXP,HWCRHK_R_REQUEST_FAILED);
- }
+ HWCRHKerr(HWCRHK_F_HWCRHK_MOD_EXP,HWCRHK_R_REQUEST_FAILED);
ERR_add_error_data(1,rmsg.buf);
goto err;
}
@@ -1006,13 +1041,13 @@
if (ret 0)
{
- /* FIXME: When this error is returned, HWCryptoHook is
- telling us that falling back to software computation
- might be a good thing. */
- if(ret == HWCRYPTOHOOK_ERROR_FALLBACK)
+ if ((ret == HWCRYPTOHOOK_ERROR_FALLBACK)
+ (hwcrhk_globals.flags
+
Re: [PATCH] Fall back to software if nCipher hardware fails
On Wed, Sep 24, 2003 at 12:01:19PM -0400, Geoff Thorpe wrote: Well I think it depends if your hardware could be used for the purposes of scalability and throughput. If so, this approach is a naive way to improve the user experience because in reality it blows away all attemps by the architect/admins to have any congestion management. With respect, these are the only people who have the budgets and time to think about buying dedicated crypto hardware anyway, right? technical rant So if you choose the number of accelerators to address what you see as appropriate resourcing for SSL/PKC demands, and you resource your web-server (or whatever) hosts to cover what you foresee as appropriate for web/application/accelerator-controller purposes, then how do you keep an overload in one component from bringing down the rest? [...] Fair enough; I've updated the ticket with one that leaves software fallback disabled unless OPENSSL_NCIPHER_FALLBACK=on or an ENGINE control command is used. Cheers, -- Colin Watson [EMAIL PROTECTED] Software EngineernCipher Corporation Limited __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
suspicious VxWorks patch
From latest e_os.h (inside VxWORKS ifdef): #define ioctlsocket(a,b,c) ioctl((a),(b),*(int*)(c)) Can this really be right? I mean using it in BIO_socket_ioctl() expands to: ioctlsocket (fd, type, *(int*)ptr); I would assume VxWorks to expect a pointer in the 3rd arg to it's ioctl(). If so, the above could crash or at worst silently trash some unrelated data. Gisle V. # rm /bin/laden /bin/laden: Not found __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: suspicious VxWorks patch
In message [EMAIL PROTECTED] on Mon, 29 Sep 2003 16:29:36 +0200, Gisle Vanem [EMAIL PROTECTED] said: giva From latest e_os.h (inside VxWORKS ifdef): giva giva #define ioctlsocket(a,b,c) ioctl((a),(b),*(int*)(c)) That got changed to this: #define ioctlsocket(a,b,c) ioctl((a),(b),(int)(c)) -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #678] Crash in lhash code in openssl 0.9.7a
I agree entirely that a reference counter is the way to go. However, the complexity is much higher, and *for my purposes* the solution that I described works adequately. Thanks for doing a proper fix! Philip Richard Levitte via RT wrote: It seems to me that adding a reference counter is a bit better. This means that we need to have one extra function (and callback) to release a pointer (and thereby decreas the reference count). I'm experimenting with that approach as I write, and I'm going to release soon unless someone sees a problem with that approach. Your alternative will unfortunately mean that we'll get a large number of reports telling us about the memory leak reported by valgrind and whatnot. I'd prefer to stay away from there if possible. [EMAIL PROTECTED] - Tue Aug 19 10:34:05 2003]: I get a crash in the lhash code in Openssl 0.9.7a. The troublesome case is when it is called from err/err.c in a multithreaded environment. The root cause *may* be that the hash is destroyed by int_thread_del_item while (say) int_thread_get has a copy of the pointer. The locking does not seem to cover the gap between loading the pointer (int_thread_hash) and then using it. Rather the lock is taken out, the pointer loaded, the lock released. The lock is then re-acquired and then the pointer is used. This seems wrong. My simple-minded proposal to fix the problem is to delete the code in int_thread_del_item that deletes the hash when it becomes empty. Yes, this will result in some memory being reserved and not freed.. I also suspect that the same problem could arise with int_error_hash -- that pointer is returned by int_err_get() when no lock is being held. Advice? Philip -- Philip Gladstone978-ZEN-TOAD (978-936-8623) Cisco Systems, Inc Boxboro, MA __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #701] [Patch] openssl support for iSeries (os/400)
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: suspicious VxWorks patch
On 9/29/03 7:29 AM, Gisle Vanem [EMAIL PROTECTED] wrote: #define ioctlsocket(a,b,c) ioctl((a),(b),*(int*)(c)) Can this really be right? I mean using it in BIO_socket_ioctl() expands to: ioctlsocket (fd, type, *(int*)ptr); I would assume VxWorks to expect a pointer in the 3rd arg to it's ioctl(). If so, the above could crash or at worst silently trash some unrelated data. I submitted a patch to cast it to an int instead of dereferencing it. VxWorks ioctl takes an int for the 3 parameter, but it is treated similarly to how other platforms treat the 3 parameter to ioctl (sometimes a pointer). The original code for VxWorks in e_os.h was this (note the dereference of c): #define ioctlsocket(a,b,c) ioctl((a),(b),*(c)) This did not compile because c is sometimes a void *. I changed it to the following, which has difference semantics than the original (no longer dereferences), but I think is correct for VxWorks (assumes an int is big enough to hold a pointer, which is not always true on all platforms, but this is a limitation of the VxWorks ioctl because it uses an int for that parameter): #define ioctlsocket(a,b,c) ioctl((a),(b),(int)(c)) The latest version of e_os.h has the change. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
