Re: [PATCH] libcrypto without executable stack
On Nov 9 01:19, Mike Frysinger wrote: On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote: the appended patch makes libcrypto.so compile without executable stack requirements. it should be portable accross all versions of binutils (and doesn't affect any non-linux platform anyway). it will break non-ELF builds though (but maybe the script isnt used for non-ELF targets so thats OK?) It's also used for Cygwin and the patch breaks the Cygwin build. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wednesday 09 November 2005 10:45, Corinna Vinschen wrote: It's also used for Cygwin and the patch breaks the Cygwin build. I don't have a cygwin toolchain around, but can you tell me the error message so that I can work on fixing it? does the attached patch work? Thanks, Dirk --- crypto/perlasm/x86unix.pl +++ crypto/perlasm/x86unix.pl @@ -586,6 +586,8 @@ push(@out,$const); $const=; } + push(@out, .section .note.GNU-stack,\\,[EMAIL PROTECTED]) + if($main'elf); } sub main'data_word
Re: [PATCH] libcrypto without executable stack
On Nov 9 13:57, Dirk Mueller wrote: On Wednesday 09 November 2005 10:45, Corinna Vinschen wrote: It's also used for Cygwin and the patch breaks the Cygwin build. I don't have a cygwin toolchain around, but can you tell me the error message so that I can work on fixing it? x86cpuid-cof.s: Assembler messages: x86cpuid-cof.s:0: Warning: end of file not at end of a line; newline inserted x86cpuid-cof.s:165: Error: junk at end of line, first unrecognized character is `-' does the attached patch work? Yes, it works. The resulting asm file does not contain the new .section pseudo op. There are two problems with this section in PE/COFF, first, the section name must not contain a dash (for whatever reason), and second, COFF sections have only up to two parameters as described in the gas info pages: .section NAME[, FLAGS] .section NAME[, SUBSEGMENT] Btw., the first asm message indicates that a \n is missing. You should add this at the end of the section string to avoid the warning. HTH, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wednesday 09 November 2005 14:30, Corinna Vinschen wrote: Btw., the first asm message indicates that a \n is missing. You should add this at the end of the section string to avoid the warning. Ok, thanks for your help and the hint. I'd like to suggest the following patch for inclusion into OpenSSL. Thanks, Dirk 2005-11-09 Dirk Mueller [EMAIL PROTECTED] * x86unix.pl: Annotate assembler sources with non executable stack requirements for ELF targets. --- crypto/perlasm/x86unix.pl +++ crypto/perlasm/x86unix.pl @@ -586,6 +586,8 @@ push(@out,$const); $const=; } + push(@out, .section .note.GNU-stack,\\,[EMAIL PROTECTED]) + if($main'elf); } sub main'data_word
Re: [PATCH] libcrypto without executable stack
On Wed, Nov 09, 2005 at 02:39:47PM +0100, Dirk Mueller wrote: Ok, thanks for your help and the hint. I'd like to suggest the following patch for inclusion into OpenSSL. thanks, we've just been forcing -Wa,--noexecstack in Gentoo ... this is much nicer :) btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to generate some source files which are included in the final lib, it'll force back in exec stack markings ... %ifidn __OUTPUT_FORMAT__,elf section .note.GNU-stack noalloc noexec nowrite progbits %endif -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wednesday 09 November 2005 15:15, Mike Frysinger wrote: btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to generate some source files which are included in the final lib, it'll force back in exec stack markings ... It doesn't seem to be used here. can you confirm that the stack is nonexecutable on your platform if you apply just the patch I posted? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wed, Nov 09, 2005 at 03:21:20PM +0100, Dirk Mueller wrote: On Wednesday 09 November 2005 15:15, Mike Frysinger wrote: btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to generate some source files which are included in the final lib, it'll force back in exec stack markings ... It doesn't seem to be used here. i wasnt suggesting it was, just saying that 'hey, just in case, why the hell note' :) can you confirm that the stack is nonexecutable on your platform if you apply just the patch I posted? with openssl-0.9.8a/x86 your patch fixes GNU_STACK markings for me x86_64/ia64 though need another fix ... -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
the appended patch makes libcrypto.so compile without executable stack requirements. it should be portable accross all versions of binutils x86unix.pl is called to generate output suitable not only for GNU assembler [applies to ELF, COFF and a.out targets], but even for vendor assemblers, for example Suns. So one either have to complement it with a way to *reliably* identify when binutils are deployed or adhere to alternative method, such as previously suggested -Wa,--noexecstack. (and doesn't affect any non-linux platform anyway). How come it turns from unsure should be portable to definitive doesn't affect so easily:-) Indeed, should be portable is more like well, i didn't actually test every single version, right? And it's fine! But doesn't affect is pretty much i've tested every damn non-linux platform and not single one failed and it doesn't really win the confidence:-) But anyway. My vote goes to alternative method, which can be deployed as easily as './config -Wa,--noexecstack' prior make. Because it can be taylored to various needs/environments as easy as it can be deployed and without headaches of cross-platform verification or running into subtle bugs. It appears that alternatively one can throw in -Wl,-z,-noexecstack... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: hunting for small OpenSSL libs
I'm trying to merge the work from Martin Witzel (openssl-e dated from Nov. 2003) to reduce the OpensSSL footprint (for 386'er x86). With OpenSSL 0.9.7 is was able to reduce the library size down to 1070834 bytes libcrypto.a 159774 bytes libssl.a if only DES, MD5, RSA and SHA are used. Now with OpenSSL 0.9.8 the libs are much bigger 1208692 bytes libcrypto.a no-sha256 no-sha512 no-ec no-hw? These are largest 0.9.8 newcomers according to 'size libcrypto.a | sort -n'. I suppose you already do no-sha0? On related note, no-asm doesn't necessarily mean smaller code, rather contrary... and I was not able to remove DSA (yes, I know RFC2246 requires DSA but OpenVPN is linked staticly without TLS support so this is not a concern). The resulting OpenVPN binary is 208623 bytes larger which quite much. I have a couple of questions: a) I wonder if there is anyone else working on something to reduce the footprint from OpenSSL? You can now run into #ifdef OPENSSL_SMALL_FOOTPRINT clauses in OpenSSL code. Simplest way to engage it is to pass -DOPENSSL_SMALL_FOOTPRINT argument at ./config command line. But don't hold your breath, at least not for now, as it still affects very few modules, most notably sha, bignum and des [in HEAD]. And it should be naturally complemented with optimize for size compiler flag, e.g. in gcc context -O2 is appropriate. c) If I get the previous openssl-e patch set working again is there a way to get the patch merged to the OpenSSL core? Common mistake contributors tend to do is suggesting large intrusive patches for released code-bases. Intrusive patches are less likely to get through there, so forget stable releases! Target the development branch! You have way better chances there. Don't accumulate too much changes for submission, suggest smaller patches and complement them with meaningful rationale. Describe the problems you've ran into, instead of just this fixed my problem. Another keyword is to motivate OpenSSL team members somehow. E.g. explicitly state what free software project you're working on, provide reference and tell why it's important. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Openssl 0.9.8 Win 64 bit initial support
While seeing the Major changes between Openssl 0.9.7g and Openssl 0.9.8 I found that for Win64 support it says : Added initial support for Win64 But I am not able to find out what initial support does this provide? Could anyone elaborate on this? Risking that the answer will be disregarded again, the question was answered in July upon 0.9.8 release, see http://marc.theaimsgroup.com/?l=openssl-devm=112076008130181w=2. Risking and again refers to the fact that the question was posed by the same originator:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wed, Nov 09, 2005 at 05:38:39PM +0100, Andy Polyakov wrote: (and doesn't affect any non-linux platform anyway). How come it turns from unsure should be portable to definitive doesn't affect so easily:-) it should be portable across all ELF targets ... after all, you're just adding an elf program header which any elf loader worth its salt would ignore if it didnt support it the code itself though would require GNU as ... but i havent poked through the code before so maybe that requirement is already covered ? But anyway. My vote goes to alternative method, which can be deployed as easily as './config -Wa,--noexecstack' prior make. or maybe add it to the default configure code as a normal check ? i'm pretty sure there is no case where you wouldnt want to use the flag if your toolchain supported it -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wednesday 09 November 2005 17:38, Andy Polyakov wrote: (and doesn't affect any non-linux platform anyway). How come it turns from unsure should be portable to definitive doesn't affect so easily:-) What I tried to say was that the extra section is ignored on platforms that do not use a recent binutils toolchain, which interpret this section magically. But anyway. My vote goes to alternative method, which can be deployed as easily as './config -Wa,--noexecstack' prior make. Because it can be taylored to various needs/environments as easy as it can be deployed and without headaches of cross-platform verification or running into subtle bugs. Works for me as well, its kind of a brute force hammer though. In any case the real intention is to document that libcrypto *should* work fine without executable stack (and it does, given there is only one tiny piece of assembler which questions the whole thing), and for that, one patch in upstream is needed, and IMHO it should configure with non-executable stack by default if the preconditions are met. Dirk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1239] OpenSSL-0.9.8 executable fails to load when compiled with shared libraries on AIX
First of all keep in mind and some platforms are pretty much community supported, meaning that it's seldomly tested by occasional users and platform support might end up being based on incomplete or inaccurate information. This in turn means that you might have some irrational impressions such as how could they miss this [on AIX]. -- Options: --openssldir=home dir/openssl enable-threads -D_REENTRANT enable-shared no-gmp no-krb5 no-mdc2 no-rc5 no-zlib no-zlib-dynamic OS (uname): AIX chi-ibm02 2 5 00CBD8CF4C00 OS (config): 00CBD8CF4C00-ibm-aix Target (default): aix-cc Target: aix-cc Problem description: When I install OpenSSL-0.9.8/0.9.8a on AIX with shared libraries, after command make it builds but produces a number of error messages like: - exec(): 0509-036 Cannot load program home dir/openssl-0.9.8a/util/../apps/openssl because of the following errors: 0509-150 Dependent module libc.a(shr.o) could not be loaded. 0509-022 Cannot load module libc.a(shr.o). 0509-026 System error: A file or directory in the path name does not exist. - It can be helped by explicitly adding the path for libc.a, e.g. env LIBPATH=/usr/lib required command but it doesn't seem to be a good permanent solution. Ouch! Verify http://cvs.openssl.org/chngview?cn=14612. Case is being dismissed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1238] Bug Report: OpenSSL 0.9.7i Configure broken for solaris-sparcv8-cc
This was already reported and fixed. Case is being dismissed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1239] OpenSSL-0.9.8 executable fails to load when compiled with shared libraries on AIX
See http://marc.theaimsgroup.com/?l=openssl-devm=113155776813084w=2 for resolution. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1236] problems with make
Using either NetBSD 1.6.2 make, or NetBSD pkgsrc gmake to build 0.9.8a seems to result in a continuous make loop. Well, the make loop problem doesn't seem to be specific to NetBSD. If you delete libcrypto.a and don't run 'make clean', all makes end up in end-less loop. After some debugging, I realized that it was a partial previous build had left crypto/lib present, but not libcrypto.a. A make clean solved the problem. So: ./Configure no-threads BSD-x86 make (fails at s512base2-out.s...) 1. It's s512sse2-*.s, where sse2 refers to Intel P4 SSE2 instruction extensions. Which implies that your assembler is expected to be up-to-date to handle it. If it's note the case, then you should pass no-sse2 option at configure stage. 2. NetBSD versioning is not my strong side, but if version in question is ELF-based, then you should use BSD-x86-elf. Essentially we recommend to use ./config, which is expected to at least tell apart ELF and non-ELF flavors, but it also attempt to pass no-sse2 when appropriate. It appears that somewhere along the way we wind up with: istari-[/sandel/src/openssl-0.9.8a] mcr 1166 %ls -l libcrypto.a crypto/lib ls: libcrypto.a: No such file or directory - -rw-r--r-- 1 mcr wheel 0 Nov 3 22:05 crypto/lib I tried this, but it didn't help. Perhaps it needs to be applied to all files down the tree. What's this and what's help. If this is proposed patch and help is no more end-less loop, then it helps. You end up with a lot of unresolved reference errors, but it doesn't exhaust the process table. I'd say no loop is good enough solution, as 'make clean' is more than appropriate in such situation. This posting is partly to fill google with an answer. - --- openssl-0.9.8a.orig/crypto/Makefile Thu Nov 3 21:50:18 2005 +++ openssl-0.9.8a/crypto/MakefileThu Nov 3 22:00:01 2005 @@ -94,12 +94,14 @@ @$(PERL) $(TOP)/util/mklink.pl ../apps $(APPS) @target=links; $(RECURSIVE_MAKE) - -lib: $(LIBOBJ) +lib: $(LIB) + @touch lib + +$(LIB): $(LIBOBJ) $(AR) $(LIB) $(LIBOBJ) $(RANLIB) $(LIB) || echo Never mind. - - @touch lib - -shared: buildinf.h lib subdirs +shared: buildinf.h lib subdirs if [ -n $(SHARED_LIBS) ]; then \ (cd ..; $(MAKE) $(SHARED_LIB)); \ fi __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1239] Ticket Resolved
Thank you very much, without filing a bug, just wanted to notice that after successful installation OpenSSL-0.9.8a on linux 32, openssl version produces: OpenSSL 0.9.6b [engine] 9 Jul 2001 while for linux 64 OpenSSL 0.9.7a Feb 19 2003 On other platforms version seems to be correct. Regards, Vladimir -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov via RT Sent: Wednesday, November 09, 2005 11:48 AM To: Shklover, Vladimir Subject: [openssl.org #1239] Ticket Resolved According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1052]: New patch for subjectAltName
[EMAIL PROTECTED] via RT wrote: In the rt now is a new patch for openssl HEAD (of 20051108) that handles the subjectAltName generation. This patch allows users to set all types of generalNames from data provided in the DN of the request. Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many smime.p7s Description: S/MIME Cryptographic Signature
Support for rfc3546 in openssl?
Hi, are there any plans to add support for rfc3546 (Transport Layer Security (TLS) Extensions), especially Server Name Indication to openssl in the near future? Regards Rüdiger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] libcrypto without executable stack
On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote: Hi, the appended patch makes libcrypto.so compile without executable stack requirements. it should be portable accross all versions of binutils (and doesn't affect any non-linux platform anyway). The problem is that binutils assumes that assembler files without that section require an executable stack, while most don't. This means that on all platforms that use gnu binutils something is required for all (generated) assembler files (not created by gcc), not just for x86. You don't have the problem with .c files since gcc will add the proper section if it needs to, which is in most cases. There are cases where gcc will generate assembler that requires an executable stack too. This means either patching all those generated files, or telling the assembler (with -Wa,--noexecstack) that it shouldn't generate an executable stack. I would prefer the first, but I don't see how to make that portable in an easy way. The problem with an executable stack is probaly obvious to most people, in case of a security bug it's ussually the most easy way to exploit it. The Linux kernel now has the abbility to make the stack executable on request, specialy on hardware with the NX bit. There exist patches that do not allow you to have an executable stack. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1191] [PATCH] Pre-Shared Key Ciphersuites for OpenSSL
I have two questions: (1) When new version of openssl which implements the PSK ciphersuites be released? (2) I can use the patch supplied here in the until then, but then there is the legal question: is the patch released under the same license as openssl? Thanks! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
