C5P and later cores (also known as 'ACE', which is part of the VIA PadLock
security engine). Ported from OpenBSD.
Reviewed on tech-crypto and port-i386, no objections to commiting this.
created with ONCE_DECL() is local. This results in reinitializing
the driver list when crypto_get_driverid() (and leaks memory). Fix
this by making the marker static.
Fixes PR/35412.
Ack freza@.
XXX: We still install rmd160.h and sha2.h in /usr/include/crypto, unlike
the other hash functions which get installed in /usr/include for compatibility.
- struct timeval time is gone
time.tv_sec -> time_second
- struct timeval mono_time is gone
mono_time.tv_sec -> time_uptime
- access to time via
{get,}{micro,nano,bin}time()
get* versions are fast but less precise
- support NTP nanokernel implementation (NTP API 4)
- further reading:
Timecounter Paper: http://phk.freebsd.dk/pubs/timecounter.pdf
NTP Nanokernel: http://www.eecis.udel.edu/~mills/ntp/html/kern.html
Maybe we get away with this (at least on 32bit archs) because the structure
is 24 bytes and I bet the minimum allocation size is 32.
Fixed coverty CIDs 2732 and 2733
- use vmspace rather than proc or lwp where appropriate.
the latter is more natural to specify an address space.
(and less likely to be abused for random purposes.)
- fix a swdmover race.
framework. There is no need to waste the space if you are only using
algoritms provided by hardware accelerators. To get the software
implementations, add "pseudo-device swcr" to your kernel config.
- Lazily initialize the opencrypto framework when crypto drivers
(either hardware or swcr) register themselves with the framework.
Fix vulnerability to a denial-of-service attack which passes a
length-0 crypto op. Check for zero length and return EINVAL, taken from:
http://cvsweb.FreeBSD.org/src/sys/opencrypto/cryptodev.c.diff?r1=1.25&r2=1.26
Original FreeBSD log mesage:
Modified files:
sys/opencrypto cryptodev.c
Log:
Fix bogus check. It was possible to panic the kernel by giving 0 length.
This is actually a local DoS, as every user can use /dev/crypto if there
is crypto hardware in the system and cryptodev.ko is loaded (or compiled
into the kernel).
Reported by: Mike Tancsa <mike@sentex.net>
thanks to Sam Leffler for passing on a heads-up about this issue.
1. make fileops const
2. add 2 new negative errno's to `officially' support the cloning hack:
- EDUPFD (used to overload ENODEV)
- EMOVEFD (used to overload ENXIO)
3. Created an fdclone() function to encapsulate the operations needed for
EMOVEFD, and made all cloners use it.
4. Centralize the local noop/badop fileops functions to:
fnullop_fcntl, fnullop_poll, fnullop_kqfilter, fbadop_stat
will be hardware-accelerated. Avoids copyin()/copyout() overhead and
spending exceessive tie inside the kernel.
Pullup after: 24 hours, or confirmation by Jason Thorpe that this is the
consensus tech-kern agreed upon last summer.
clients, and a pseudo-device for userspace access.
The attribute is named `opencrypto'. The pseudo-device is renamed to
"crypto", which has a dependency on "opencrypto". The sys/conf/majors
entry and pseudo-device attach entrypoint are updated to match the
new pseudo-device name.
Fast IPsec (sys/netipsec/files.ipsec) now lists a dependency on the
"opencrypto" attribute. Drivers for crypto accelerators (ubsec,
hifn775x) also pull in opencrypto, as providers of opencrypto transforms.
for using /dev/crypto for OpenSSL:
1. Add comments explaining crypto_devallowsoft, explaining the
OpenBSD-style three-way logic actully implemented in crypto_newsession().
2. Pass crypto_devallowsoft as the final argument to crypto_newsession(),
instead of a constant 0 value.
3. Set the default value of crypto_devallowsoft to 1, to allow
/dev/crypto access only for hardware-supported transforms.
Items 1-3 may be revised to match the FreeBSD two-way logic, if the
consensus is that there's no point to forcing software transforms.
But as a first step, let the description match what the code actually does.
GC unused variables usercrypto, userasmcrypto, cryptodevallowsoft from
cryptodev.c, in favour of variables crypto_usercrypto, crypto_userasmcrypto,
crypto_devallowsoft, which are used as well as defined in crypto.c.
compiler will emit code to first copy it onto the stack before
copying it into the destination context structure. With this change,
it will only be copied once.
the old one. Rename the functions/structures from cast_* to cast128_*.
Adapt the KAME IPsec to use the new CAST-128 code, which has a simpler
API and smaller footprint.
ad