| 243715 |
30-Nov-2012 |
pjd |
Allow OpenSSL to use arc4random(3) on FreeBSD. arc4random(3) was modified
some time ago to use sysctl instead of /dev/random to get random data,
so is now much better choice, especially for sandboxed processes that have
no direct access to /dev/random.
Approved by: benl
MFC after: 2 weeks
|
| 237658 |
27-Jun-2012 |
jkim |
Partially redo r226436, i. e., change "the the" to "the". ca(1), dgst(1),
and engine(3) are generated from these pod files during merge process and
we do not want to re-apply these changes over and over again.
Approved by: benl (maintainer, implicit)
|
| 234954 |
03-May-2012 |
bz |
Fix multiple OpenSSL vulnerabilities.
Security: CVE-2011-4576, CVE-2011-4619, CVE-2011-4109
Security: CVE-2012-0884, CVE-2012-2110
Security: FreeBSD-SA-12:01.openssl
Approved by: so (bz,simon)
|
| 223758 |
04-Jul-2011 |
attilio |
With retirement of cpumask_t and usage of cpuset_t for representing a
mask of CPUs, pc_other_cpus and pc_cpumask become highly inefficient.
Remove them and replace their usage with custom pc_cpuid magic (as,
atm, pc_cpumask can be easilly represented by (1 << pc_cpuid) and
pc_other_cpus by (all_cpus & ~(1 << pc_cpuid))).
This change is not targeted for MFC because of struct pcpu members
removal and dependency by cpumask_t retirement.
MD review by: marcel, marius, alc
Tested by: pluknet
MD testing by: marcel, marius, gonzo, andreast
|
| 222813 |
07-Jun-2011 |
attilio |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are
capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever
value. Anyway, as long as several structures in the kernel are
statically allocated and sized as MAXCPU, it is suggested to keep it
as low as possible for the time being.
Technical notes on this commit itself:
- More functions to handle with cpuset_t objects are introduced.
The most notable are cpusetobj_ffs() (which calculates a ffs(3)
for a cpuset_t object), cpusetobj_strprint() (which prepares a string
representing a cpuset_t object) and cpusetobj_strscan() (which
creates a valid cpuset_t starting from a string representation).
- pc_cpumask and pc_other_cpus are target to be removed soon.
With the moving from cpumask_t to cpuset_t they are now inefficient
and not really useful. Anyway, for the time being, please note that
access to pcpu datas is protected by sched_pin() in order to avoid
migrating the CPU while reading more than one (possible) word
- Please note that size of cpuset_t objects may differ between kernel
and userland. While this is not directly related to the patch itself,
it is good to understand that concept and possibly use the patch
as a reference on how to deal with cpuset_t objects in userland, when
accessing kernland members.
- KTR_CPUMASK is changed and now is represented through a string, to be
set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but
private testing has been done until to MAXCPU=128 on a real 8x8x2(htt)
machine (amd64).
Please note that the FreeBSD version is not yet bumped because of
the upcoming pcpu changes. However, note that this patch is not
targeted for MFC.
People to thank for the time spent on this patch:
- sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested
several revision of the patches and really helped in improving
stability of this work.
- marius fixed several bugs in the sparc64 implementation and reviewed
patches related to ktr.
- jeff and jhb discussed the basic approach followed.
- kib and marcel made targeted review on some specific part of the
patch.
- marius, art, nwhitehorn and andreast reviewed MD specific part of
the patch.
- marius, andreast, gonzo, nwhitehorn and jceel tested MD specific
implementations of the patch.
- Other people have made contributions on other patches that have been
already committed and have been listed separately.
Companies that should be mentioned for having participated at several
degrees:
- Yahoo! for having offered the machines used for testing on big
count of CPUs.
- The FreeBSD Foundation for having sponsored my devsummit attendance,
which has been instrumental.
- Sandvine for having offered offices and infrastructure during
development.
(I really hope I didn't forget anyone, if it happened I apologize in
advance).
|
| 207736 |
07-May-2010 |
mckusick |
Merger of the quota64 project into head.
This joint work of Dag-Erling Smørgrav and myself updates the
FFS quota system to support both traditional 32-bit and new 64-bit
quotas (for those of you who want to put 2+Tb quotas on your users).
By default quotas are not compiled into the kernel. To include them
in your kernel configuration you need to specify:
options QUOTA # Enable FFS quotas
If you are already running with the current 32-bit quotas, they
should continue to work just as they have in the past. If you
wish to convert to using 64-bit quotas, use `quotacheck -c 64';
if you wish to revert from 64-bit quotas back to 32-bit quotas,
use `quotacheck -c 32'.
There is a new library of functions to simplify the use of the
quota system, do `man quotafile' for details. If your application
is currently using the quotactl(2), it is highly recommended that
you convert your application to use the quotafile interface.
Note that existing binaries will continue to work.
Special thanks to John Kozubik of rsync.net for getting me
interested in pursuing 64-bit quota support and for funding
part of my development time on this project.
|
| 205128 |
13-Mar-2010 |
simon |
Merge OpenSSL 0.9.8m into head.
This also "reverts" some FreeBSD local changes so we should now
be back to using entirely stock OpenSSL. The local changes were
simple $FreeBSD$ lines additions, which were required in the CVS
days, and the patch for FreeBSD-SA-09:15.ssl which has been
superseded with OpenSSL 0.9.8m's RFC5746 'TLS renegotiation
extension' support.
MFC after: 3 weeks
|
| 186872 |
07-Jan-2009 |
simon |
Prevent cross-site forgery attacks on lukemftpd(8) due to splitting
long commands into multiple requests. [09:01]
Fix incorrect OpenSSL checks for malformed signatures due to invalid
check of return value from EVP_VerifyFinal(), DSA_verify, and
DSA_do_verify. [09:02]
Security: FreeBSD-SA-09:01.lukemftpd
Security: FreeBSD-SA-09:02.openssl
Obtained from: NetBSD [SA-09:01]
Obtained from: OpenSSL Project [SA-09:02]
Approved by: so (simon)
|
| 175292 |
13-Jan-2008 |
simon |
Unbreak detection of cryptodev support for FreeBSD which was broken
with OpenSSL 0.9.8 import.
Note that this does not enable cryptodev by default, as it was the
case with OpenSSL 0.9.7 in FreeBSD base, but this change makes it
possible to enable cryptodev at all.
This has been submitted upstream as:
http://rt.openssl.org/Ticket/Display.html?id=1624
Submitted by: nork
|
| 110049 |
29-Jan-2003 |
nectar |
Background:
When libdes was replaced with OpenSSL's libcrypto, there were a few
interfaces that the former implemented but the latter did not. Because
some software in the base system still depended upon these interfaces,
we simply included them in our libcrypto (rnd_keys.c).
Now, finally get around to removing the dependencies on these
interfaces. There were basically two cases:
des_new_random_key -- This is just a wrapper for des_random_key, and
these calls were replaced.
des_init_random_number_generator et. al. -- A few functions were used
by the application to seed libdes's PRNG. These are not necessary
when using libcrypto, as OpenSSL internally seeds the PRNG from
/dev/random. These calls were simply removed.
Again, some of the Kerberos 4 files have been taken off the vendor
branch. I do not expect there to be future imports of KTH Kerberos 4.
|
| 57510 |
26-Feb-2000 |
peter |
At great personal risk (to my already fragile sanity), reorganize
the rsa stubs for libcrypto. libcrypto.so now uses dlopen() to
implement the backends for either the native or rsaref implemented
RSA code.
This involves:
- unifying the libcrypto and openssl(1) source so there is no
#ifdef RSAref variations.
- using weak symbols and dlopen()/dlsym() routines to access the
rsa method vectors.
Releases will enable the user to choose International, US (rsaref) or
no RSA code at install time.
'make world' will DTRT depending on whether you have the international
or US source. For US users, you must either install rsaref (the port
or package) or (if you don't fear RSA Inc) use the (superior)
International rsa_eay.c code.
This has been discussed at great length by the affected folks and even
we have a great deal of confusion. This is a checkpoint so we can tune
the results. This works for me in all permutations I can think of and
should result in a CD/ftp 'release' just about doing the right thing now.
|