>>>> As for SHA. It was shown that there is a way to use SHA even on >>>> pre-Nano, see >>>> http://www.mail-archive.com/openssl-dev@openssl.org/msg21787.html. >>>> Challenge is to make it multi-thread safe. It would take allocation of >>>> dynamic lock and serializing access to "crash page" allocated at engine >>>> load. >>> No, there's more problem on using the "crash page" than benefit. >>> I've had the "crash page" patch on production system, and couple >>> of situation it broke things. >> If not much trouble could you elaborate? About the way it broke things >> and under which circumstances? Even if we choose to discard the approach >> it's valuable knowledge... A lot of thanks in advance. > > Some apps (like VMs in e.g. Java) do also hook SIGSEGV for various > reasons (or at leased used to). You need a lot of special attention to > chain the signal handlers properly; and this was not done right in the > patch. And you also need to check various other things to be correct in > the signal; otherwise you might be trying to fix a real SIGSEGV in > another thread. > > And this is pretty much unfixable if the application has multiple > threads and one of the threads goes switch SIGSEGV handlers behind our > backs.
Unless one demands programmer to supply sigaction replacement that would coordinate handlers in MT application. Most obvious solution would be to have process-wide handler that calls per-thread handlers. Naturally provided that threads are prevented (or maintain discipline) from overriding process-wide handler and set only own per-thread ones. For reference, on Windows signal handling is strictly per-thread. One can only wonder why it's not the actual case for synchronous signals (such as SEGV, ILL, FPE) even in Posix. Of course this is not right forum to discuss this. We can only a) provide a *hook* for overriding sigaction for MT programmers to use in similar situation (this implies that if programmer didn't provide replacement, then OpenSSL accepts no responsibility, the way it is now with other MT hooks); b) *detect* if application is multi-threaded and *abstain* from using "crash page" in favor of software (there are relevant single-threaded applications, e.g. OpenSSH and Apache); c) forget all about "crash page". As variation of b) one can naturally make engine interpret an argument that would tell it that it's safe to use "crash page" in particular process context. > I believe the one major bug we had, ended up being a bug in kernel grsec > patchset that caused some breakage in signal handlers. But it just > seemed to be caused by the "crash page". I.e. reality is not what theory suggests:-) I mean we blame deficient standard, but it was some other implementation issue:-) >>> There's also additional overhead in >>> copying the data to the specifically crafted memory area, and it >>> causes this kludge to be not as beneficial. >> But it's still several times faster than software and that's what counts. > > You will get additional penalty from: > * hooking signal handler and restoring it (two syscalls) > * handling of the page fault > * copying data from user's buffer to the mmap():ed buffer > > While this will be still faster with large amounts of data, Which is why my snippet opted for hardware only for larger blocks, >512 bytes in SHA1 case. Smaller blocks were served by software implementation. > the hack is not general purpose. I.e. c) forget all about it? I'm somewhat opposed to the originally suggested idea of intermediate buffering, because there is no good way of knowing what's optimal and so you end up wasting memory [especially in MT application]. One possibility *might* be to do something similar to crypto/evp/e_aes_cbc_hmac_sha1.c in specifically TLS context. The thing is that packet length is known in advance, i.e. prior call to cipher. Let us think about it... > The speed-up is even greater if you teach your application to properly > use the ONESHOT flag, and the finalizing form can used properly then. I never suggested to use "crash page" alone. If application passes ONESHOT flag, there is no reason not to use it. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
