Rather than doing separate linker/compiler checks, just build a
non-empty program with each so that the compiler will actually try to
use the hardening features. Reduce redundancy in the macro calls by just
setting the flag that was just tested.
Also, disable hardening for mingw, since its trying to use a
libssp-0.dll file that I can't find right now. The detected hardening
flags break mingw builds currently.
Where available, enable stack smashing protection, fortify source,
no-strict-overflow, and read only relocations.
Many Linux distributions automatically enable most of these options.
They are no brainers. The difference introduced here is in asking for a
few more aggressive options. An option to disable the more aggressive
options is provided (--disable-hardening). When set, configure will fall
back to the default CFLAGS on the system - in many cases that will still
be hardened. There is no point in going further than that.
Options enabled are:
-fstack-protector-strong is a relatively new GCC-4.9 feature that is
supposed to give a better balance between performance and protection.
-all is considered too aggressive, but was used in Chromium and other
security critical systems until -strong became available. Follow their
lead and use -strong when possible. clang 6.0 supports -all but not
-strong.
_FORTIFY_SOURCE replaces certain unsafe C str* and mem* functions with
more robust equivalents when the compiler can determine the length of
the buffers involved.
-fno-strict-overflow instructs GCC to not make optimizations based on
the assumption that signed arithmetic will wrap around on overflow (e.g.
(short)0x7FFF + 1 == 0). This prevents the optimizer from doing some
unexpected things. Further improvements should trap signed overflows and
reduce the use of signed to refer to naturally unsigned quantities.
I did not set -fPIE (position independent executables). The critical
function of Open/LibreSSL is as a library, not an executable.
Tested on Ubuntu Linux 14.04.1 LTS, OS X 10.10.1 with "make check".
The code added to m4/ is GPLv3 but con
Signed-off-by: Jim Barlow <jim@purplerock.ca>
Where available, enable stack smashing protection, fortify source,
no-strict-overflow, and read only relocations.
Many Linux distributions automatically enable most of these options.
They are no brainers. The difference introduced here is in asking for a
few more aggressive options. An option to disable the more aggressive
options is provided (--disable-hardening). When set, configure will fall
back to the default CFLAGS on the system - in many cases that will still
be hardened. There is no point in going further than that.
Options enabled are:
-fstack-protector-strong is a relatively new GCC-4.9 feature that is
supposed to give a better balance between performance and protection.
-all is considered too aggressive, but was used in Chromium and other
security critical systems until -strong became available. Follow their
lead and use -strong when possible. clang 6.0 supports -all but not
-strong.
_FORTIFY_SOURCE replaces certain unsafe C str* and mem* functions with
more robust equivalents when the compiler can determine the length of
the buffers involved.
-fno-strict-overflow instructs GCC to not make optimizations based on
the assumption that signed arithmetic will wrap around on overflow (e.g.
(short)0x7FFF + 1 == 0). This prevents the optimizer from doing some
unexpected things. Further improvements should trap signed overflows and
reduce the use of signed to refer to naturally unsigned quantities.
I did not set -fPIE (position independent executables). The critical
function of Open/LibreSSL is as a library, not an executable.
Tested on Ubuntu Linux 14.04.1 LTS, OS X 10.10.1 with "make check".
Signed-off-by: Jim Barlow <jim@purplerock.ca>
When generating ELF objects from assembly, gcc and clang mark the
GNU_STACK program headers as RWX by default. This is a security issue,
so we make sure it is marked only RW.
This modifies Anthony G. Basile's original patch for Linux to set
.note.GNU-stack whenever the assembler supports it. It is surprising
that any modern toolchain would enable an executable stack without an
explicit request. The number of programs that need an executable stack
is surely much smaller than the number of programs that include assembly.
Previously, they were all using the portable package version, rather
than the individual library versions. openssl(1)'s pc file represents
the LibreSSL-portable release however.
$ pkg-config --modversion libtls
1:0:0
$ pkg-config --modversion openssl
2.1.2
$ pkg-config --modversion libssl
30:0:0
$ pkg-config --modversion libcrypto
30:3:0
ok beck@ deraadt@
Add additional code to remove linked manpages on uninstall. Since we do
linking manually, automake will not remove them for us.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Add a do_mv()/$MV wrappers to be called instead of just mv. This
function will preserve the target file if it does not differ from the
source file. This helps to remove unnecessary compilator calls after
calling update.sh w/o source changes.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
In several additional places call $CP instead of just cp to ease and
speed up rebuilds after update.sh execution.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
This adds initial support for assembly crypto acceleration on x86_64 for
ELF (Linux, *BSD, Solaris) and Mach-O (OS-X) systems.
The build method is a little different than OpenSSL and OpenBSD. All
the .s files are generated ahead of time when the tarball is generated,
so there are no complicated makefile rules at configure/build time. This
also means the builds are faster and perl is not required on the build
system.
Thanks to Wouter Clarie for providing the initial cleanup and patch
that this is based on.
This makes building and testing easier because the library Makefile.am
files are use directly rather than as templates. Thanks to Wouter Clarie
for the idea.
Remove a lot of complex shell code. Upstream churn has slowed down, so
it is now easier to maintain this directly as automake files. This is
also needed to start integrating CPU-specific acceleration support.
Since we are deriving the copy list from the Makefile.am files, we can
now get rid of copy_src/copy_crypto.
Use './configure --enable-libtls' to build the library and install the
associated manpages. Note that the API and ABI of this library may
change still, though feedback is welcome.
ok deraadt@ jsing@ tedu@
Windows sockets functions look on the outside like they behave similarly
to POSIX functions, but there are many subtle and glaring differences,
including errors reported via WSAGetLastError, read, write, and close do
not work on sockets, setsockopt takes a (char *) rather than (void *),
etc.
This header implements wrappers that coerce more POSIX-like behavior
from these functions, making portable code easier to develop.
BENEFITS:
One does not necessarily need to sprinkle #ifdefs around code to handle
the Windows and non-Windows behavior when porting code.
CAVEATS:
There may be performance implications with the 'mother-may-I'
approach to determining if a descriptor is a socket or a file.
The errno mappings are not 100% what one might expect compared to POSIX
since there were not always good 1:1 equivalents from the WSA errors.
This provides sufficient functionality to run openssl(1) from a Windows
console. This is based on the original select-based version from from
songdongsheng@live.cn. Changes:
* use nfds_t directly for iterating the fds.
* add WSAGetLastError -> errno mappings
* handle POLLHUP and the OOB data cases for revents
* handle sparse arrays of fds correctly
* KNF style updates
* teach poll how to handle file handles as well as sockets
This handles the socket/non-socket issue by alternating a loop between
WaitForMultipleObjects for non-sockets and and select for sockets. One
would think this would be terrible for performance, but as of this
writing, poll consumes about 6% of the time doing a bulk transfer
between a Linux box and 'openssl.exe s_server'.
I tried to implement this all in terms of WaitForMultipleObjects with a
select 'poll' at the end to get extra specific socket status. However,
the cost of setting up an event handle for each socket, setting the
WSAEventSelect attributes, and cleaning them up reliably was pretty
high. Since the event handle associated with a socket is also global,
creating a new one cancels the previous one or can be disabled
externally.
In addition, the 'FD_WRITE' status of a socket event handle does not
behave in an expected fashion, being triggered by an edge on a write
event rather than being level triggered.
Another fun horror story is how stdin in windows might be a console, it
might be a pipe, it might be something else. If these all worked in the
same way, it would be great. But, since a console-stdin can also signal
on a mouse or window event, it means we can easily get stuck in a
blocking read (you can't make stdin non-blocking) if the non-character
events are not filtered out. So, poll does that too.
See here for various additional horror stories:
http://www.postgresql.org/message-id/4351.1336927207@sss.pgh.pa.us
