329099 |
10-Feb-2018 |
kevans |
MFC Loader Fixes 2017q1: r311458,r312237,r312314,r312374,r312947,r313042, r313047,r313166,r313328,r313332,r313333,r313337,r313348,r313349,r313389, r313442,r313451,r313575,r313645,r313710,r314114,r314213,r314275,r314945, r314948,r315008,r315408,r315427,r315645,r315646,r315648,r315653,r315850, r316064,r316078,r316079,r316100,r316104,r316111,r316112,r316171,r316279, r316280,r316287,r316311,r316343,r316424,r316436
r311458: Use compiler driver to link BERI boot loaders
r312237: loader.efi: find_currdev() can leak memory
r312314: loader: move device path definitions to include/efidevp.h
r312374: loader: efi devpath api usage should be more aware of NULL pointers
r312947: Remove "-Xassembler -G0" from CFLAGS.
r313042: loader.efi environment related cleanups
r313047: loader: disk/part api needs to use uint64_t offsets
r313166: loader: libefi/env.c warnings in arm build
r313328: loader: Implement disk_ioctl() to support DIOCGSECTORSIZE and DIOCGMEDIASIZE.
r313332: loader: bcache read ahead block count should take account the large sectors
r313333: loader: Replace EFI part devices.
r313337: loader: 313329 missed ZFS guard in loader/main.c
r313348: loader: biosdisk fix for 2+TB disks
r313349: loader: disk io should not use alloca()
r313389: efipart is also using the '%S' printf format, add -Wno-format for it.
r313442: loader: possible NULL pointer dereference in efipart.c
r313451: loader: possible NULL pointer dereference in bcache.c
r313575: makefs: make the buffer functions look exactly like the kernel ones
r313645: loader: implement MEDIA_FILEPATH_DP support in efipart
r313710: loader: cstyle fixes and DIOCGMEDIASIZE should use uint64_t
r314114: Use LDFLAGS with CC instead of _LDFLAGS.
r314213: Remove control+r handling from geliboot's pwgets()
r314275: Remove unused macro from common/drv.c.
r314945: Some style(9) fixes. No functional changes.
r314948: Try to extract the RFC1048 data from PXE.
r315008: r314948 seems to be missing a variable or two that will break
r315408: loader: remove open_disk cache
r315427: loader: biosdisk should report IO error from INT13
r315645: loader: disk_cleanup was left in userboot_disk.c
r315646: loader: pxe.h constants have wrong values
r315648: libstand: verify value provided by nfs.read_size
r315653: loader: verify the value from dhcp.interface-mtu and use snprintf o set mtu
r315850: The original author abused Nd (one-line description, used by makewhatis)
r316064: Fix build with path names with 'align' or 'nop' in them.
r316078: gpt*boot: Save a bit more memory when LOADER_NO_GELI_SUPPORT is specified
r316079: Simply retire the sedification of the boot2.s file.
r316100: Remove -fno-guess-branch-probability and -fno-unit-at-a-time.
r316104: Use `NO_WCAST_ALIGN` instead of spelling it out as -Wno-cast-align in CFLAGS
r316111: loader: move bios getsecs into time.c
r316112: loader: ls command should display file types properly
r316171: xfsread inlined uses more space, so remove the inline tag.
r316279: loader: efipart should check disk size from partition table
r316280: loader: simplify efi_zfs_probe and avoid double probing for zfs.
r316287: Remove OLD_NFSV2 from loader and libstand
r316311: Add explicit_bzero() to libstand, and switch GELIBoot to using it
r316343: Implement boot-time encryption key passing (keybuf)
r316424: Fix sparc64 build broken by r316343 and r316076
r316436: Restore EFI boot environment functionality broken in r313333
PR: 216940 217298 217935 |
309023 |
22-Nov-2016 |
asomers |
MFC r307584
Fix C++ includability of crypto headers with static array sizes
C99 allows array function parameters to use the static keyword for their sizes. This tells the compiler that the parameter will have at least the specified size, and calling code will fail to compile if that guarantee is not met. However, this syntax is not legal in C++.
This commit reverts r300824, which worked around the problem for sys/sys/md5.h only, and introduces a new macro: min_size(). min_size(x) can be used in headers as a static array size, but will still compile in C++ mode. |
301010 |
31-May-2016 |
allanjude |
Connect the SHA-512t256 and Skein hashing algorithms to ZFS
Support for the new hashing algorithms in ZFS was introduced in r289422 However it was disconnected because FreeBSD lacked implementations of SHA-512 (truncated to 256 bits), and Skein.
These implementations were introduced in r300921 and r300966 respectively
This commit connects them to ZFS and enabled these new checksum algorithms
This new algorithms are not supported by the boot blocks, so do not use them on your root dataset if you boot from ZFS.
Relnotes: yes Sponsored by: ScaleEngine Inc.
|
300921 |
29-May-2016 |
allanjude |
Import the skein hashing algorithm, based on the threefish block cipher
Connect it to userland (libmd, libcrypt, sbin/md5) and kernel (crypto.ko)
Support for skein as a ZFS checksum algorithm was introduced in r289422 but is disconnected because FreeBSD lacked a Skein implementation.
A further commit will enable it in ZFS.
Reviewed by: cem Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D6166
|
300903 |
28-May-2016 |
allanjude |
Implement SHA-512 truncated (224 and 256 bits)
This implements SHA-512/256, which generates a 256 bit hash by calculating the SHA-512 then truncating the result. A different initial value is used, making the result different from the first 256 bits of the SHA-512 of the same input. SHA-512 is ~50% faster than SHA-256 on 64bit platforms, so the result is a faster 256 bit hash.
The main goal of this implementation is to enable support for this faster hashing algorithm in ZFS. The feature was introduced into ZFS in r289422, but is disconnected because SHA-512/256 support was missing. A further commit will enable it in ZFS.
This is the follow on to r292782
Reviewed by: cem Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D6061
|
292963 |
30-Dec-2015 |
allanjude |
Break up opencrypto/xform.c so it can be reused piecemeal
Keep xform.c as a meta-file including the broken out bits existing code that includes xform.c continues to work as normal
Individual algorithms can now be reused elsewhere, including outside of the kernel
Reviewed by: bapt (previous version), gnn, delphij Approved by: secteam MFC after: 1 week Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D4674
|
292782 |
27-Dec-2015 |
allanjude |
Replace sys/crypto/sha2/sha2.c with lib/libmd/sha512c.c
cperciva's libmd implementation is 5-30% faster
The same was done for SHA256 previously in r263218
cperciva's implementation was lacking SHA-384 which I implemented, validated against OpenSSL and the NIST documentation
Extend sbin/md5 to create sha384(1)
Chase dependancies on sys/crypto/sha2/sha2.{c,h} and replace them with sha512{c.c,.h}
Reviewed by: cperciva, des, delphij Approved by: secteam, bapt (mentor) MFC after: 2 weeks Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D3929
|
285289 |
08-Jul-2015 |
jmg |
address an issue where consumers, like IPsec, can reuse the same session in multiple threads w/o locking.. There was a single fpu context shared per session, if multiple threads were using the session, and both migrated away, they could corrupt each other's fpu context...
This patch adds a per cpu context and a lock to protect it...
It also tries to better address unloading of the aesni module... The pause will be removed once the OpenCrypto Framework provides a better method for draining callers into _newsession...
I first discovered the fpu context sharing issue w/ a flood ping over an IPsec tunnel between two bhyve machines... The patch in D3015 was used to verify that this fix does fix the issue...
Reviewed by: gnn, kib (both earlier versions) Differential Revision: https://reviews.freebsd.org/D3016
|
285216 |
06-Jul-2015 |
jmg |
Fix for non-random IV's when CRD_F_IV_PRESENT and CRD_F_IV_EXPLICIT flags are not specified... This bug was introduced in r275732...
This only affects IPsec ESP only policies w/ the aesni module loaded, other subsystems specify one or both of the flags...
Reviewed by: gnn, delphij, eri
|
281606 |
16-Apr-2015 |
rodrigc |
In the version of gcc in the FreeBSD tree, this modification was made to the compiler in svn r242182:
#if STDC_HOSTED #include <mm_malloc.h> #endif
A similar change was done to clang in the FreeBSD tree in svn r218893:
However, for external gcc toolchains, this patch is not in the compiler's header file.
This patch to FreeBSD's aesni code allows compilation with an external gcc toolchain.
Differential Revision: https://reviews.freebsd.org/D2285 Reviewed by: jmg, dim Approved by: dim
|
275732 |
12-Dec-2014 |
jmg |
Add some new modes to OpenCrypto. These modes are AES-ICM (can be used for counter mode), and AES-GCM. Both of these modes have been added to the aesni module.
Included is a set of tests to validate that the software and aesni module calculate the correct values. These use the NIST KAT test vectors. To run the test, you will need to install a soon to be committed port, nist-kat that will install the vectors. Using a port is necessary as the test vectors are around 25MB.
All the man pages were updated. I have added a new man page, crypto.7, which includes a description of how to use each mode. All the new modes and some other AES modes are present. It would be good for someone else to go through and document the other modes.
A new ioctl was added to support AEAD modes which AES-GCM is one of them. Without this ioctl, it is not possible to test AEAD modes from userland.
Add a timing safe bcmp for use to compare MACs. Previously we were using bcmp which could leak timing info and result in the ability to forge messages.
Add a minor optimization to the aesni module so that single segment mbufs don't get copied and instead are updated in place. The aesni module needs to be updated to support blocked IO so segmented mbufs don't have to be copied.
We require that the IV be specified for all calls for both GCM and ICM. This is to ensure proper use of these functions.
Obtained from: p4: //depot/projects/opencrypto Relnotes: yes Sponsored by: FreeBSD Foundation Sponsored by: NetGate
|
267815 |
24-Jun-2014 |
kib |
Put the aesni_cipher_setup() and aesni_cipher_process() functions into the file which is compiled with SSE disabled. The functions set up the FPU context for kernel, and compiler optimizations which could lead to use of XMM registers before the fpu_kern_enter(9) is called or after fpu_kern_leave(9), panic the machine.
Discussed with: jmg Sponsored by: The FreeBSD Foundation MFC after: 1 week
|
267767 |
23-Jun-2014 |
kib |
Add FPU_KERN_KTHR flag to fpu_kern_enter(9), which avoids saving FPU context into memory for the kernel threads which called fpu_kern_thread(9). This allows the fpu_kern_enter() callers to not check for is_fpu_kern_thread() to get the optimization.
Apply the flag to padlock(4) and aesni(4). In aesni_cipher_process(), do not leak FPU context state on error.
Sponsored by: The FreeBSD Foundation MFC after: 1 week
|
263218 |
16-Mar-2014 |
jmg |
replace the kernel's version w/ cperciva's implementation... In all my tests, it is faster ~20%, even on an old IXP425 533MHz it is ~45% faster... This is partly due to loop unrolling, so the code size does significantly increase... I do plan on committing a version that rolls up the loops again for smaller code size for embedded systems where size is more important than absolute performance (it'll save ~6k code)...
The kernel implementation is now shared w/ userland's libcrypt and libmd...
We drop support for sha256 from sha2.c, so now sha2.c only contains sha384 and sha512...
Reviewed by: secteam@
|
257757 |
06-Nov-2013 |
jmg |
make it so that from/to can be missaligned as it can happen (the geli regression manages to do it)... We use a packed struct to coerce gcc/clang into producing unaligned loads (there is not packed pointer attribute, otherwise this would be easier)...
use _storeu_ and _loadu_ when using the structure is overkill...
be better at using types properly... Since we allocate our own key schedule and make sure it's aligned, use the __m128i type in various arguments to functions...
clang ignores __aligned on prototypes and gcc errors on them, leave them in comments to document that these function arguments are require to be aligned...
about all that changes is movdqa -> movdqu from reading the diff of the disassembly output...
Noticed by: symbolics at gmx.com MFC after: 3 days
|
255187 |
03-Sep-2013 |
jmg |
Use the fact that the AES-NI instructions can be pipelined to improve performance... Use SSE2 instructions for calculating the XTS tweek factor... Let the compiler do more work and handle register allocation by using intrinsics, now only the key schedule is in assembly...
Replace .byte hard coded instructions w/ the proper instructions now that both clang and gcc support them...
On my machine, pulling the code to userland I saw performance go from ~150MB/sec to 2GB/sec in XTS mode. GELI on GNOP saw a more modest increase of about 3x due to other system overhead (geom and opencrypto)...
These changes allow almost full disk io rate w/ geli...
Reviewed by: -current, -security Thanks to: Mike Hamburg for the XTS tweek algorithm
|
253208 |
11-Jul-2013 |
andre |
SipHash is a cryptographically strong pseudo-random function (a.k.a. keyed hash function) optimized for speed on short messages returning a 64bit hash/ digest value.
SipHash is simpler and much faster than other secure MACs and competitive in speed with popular non-cryptographic hash functions. It uses a 128-bit key without the hidden cost of a key expansion step. SipHash iterates a simple round function consisting of four additions, four xors, and six rotations, interleaved with xors of message blocks for a pre-defined number of compression and finalization rounds. The absence of secret load/store addresses or secret branch conditions avoid timing attacks. No state is shared between messages. Hashing is deterministic and doesn't use nonces. It is not susceptible to length extension attacks.
Target applications include network traffic authentication, message authentication (MAC) and hash-tables protection against hash-flooding denial-of-service attacks.
The number of update/finalization rounds is defined during initialization:
SipHash24_Init() for the fast and reasonable strong version. SipHash48_Init() for the strong version (half as fast).
SipHash usage is similar to other hash functions:
struct SIPHASH_CTX ctx; char *k = "16bytes long key" char *s = "string"; uint64_t h = 0; SipHash24_Init(&ctx); SipHash_SetKey(&ctx, k); SipHash_Update(&ctx, s, strlen(s)); SipHash_Final(&h, &ctx); /* or */ h = SipHash_End(&ctx); /* or */ h = SipHash24(&ctx, k, s, strlen(s));
It was designed by Jean-Philippe Aumasson and Daniel J. Bernstein and is described in the paper "SipHash: a fast short-input PRF", 2012.09.18: https://131002.net/siphash/siphash.pdf Permanent ID: b9a943a805fbfc6fde808af9fc0ecdfa
Implemented by: andre (based on the paper) Reviewed by: cperciva
|
230426 |
21-Jan-2012 |
kib |
Add support for the extended FPU states on amd64, both for native 64bit and 32bit ABIs. As a side-effect, it enables AVX on capable CPUs.
In particular:
- Query the CPU support for XSAVE, list of the supported extensions and the required size of FPU save area. The hw.use_xsave tunable is provided for disabling XSAVE, and hw.xsave_mask may be used to select the enabled extensions.
- Remove the FPU save area from PCB and dynamically allocate the (run-time sized) user save area on the top of the kernel stack, right above the PCB. Reorganize the thread0 PCB initialization to postpone it after BSP is queried for save area size.
- The dumppcb, stoppcbs and susppcbs now do not carry the FPU state as well. FPU state is only useful for suspend, where it is saved in dynamically allocated suspfpusave area.
- Use XSAVE and XRSTOR to save/restore FPU state, if supported and enabled.
- Define new mcontext_t flag _MC_HASFPXSTATE, indicating that mcontext_t has a valid pointer to out-of-struct extended FPU state. Signal handlers are supplied with stack-allocated fpu state. The sigreturn(2) and setcontext(2) syscall honour the flag, allowing the signal handlers to inspect and manipilate extended state in the interrupted context.
- The getcontext(2) never returns extended state, since there is no place in the fixed-sized mcontext_t to place variable-sized save area. And, since mcontext_t is embedded into ucontext_t, makes it impossible to fix in a reasonable way. Instead of extending getcontext(2) syscall, provide a sysarch(2) facility to query extended FPU state.
- Add ptrace(2) support for getting and setting extended state; while there, implement missed PT_I386_{GET,SET}XMMREGS for 32bit binaries.
- Change fpu_kern KPI to not expose struct fpu_kern_ctx layout to consumers, making it opaque. Internally, struct fpu_kern_ctx now contains a space for the extended state. Convert in-kernel consumers of fpu_kern KPI both on i386 and amd64.
First version of the support for AVX was submitted by Tim Bird <tim.bird am sony com> on behalf of Sony. This version was written from scratch.
Tested by: pho (previous version), Yamagi Burmeister <lists yamagi org> MFC after: 1 month
|
226837 |
27-Oct-2011 |
pjd |
Improve AES-NI performance for AES-XTS: - Operate on uint64_t types when doing XORing, etc. instead of uint8_t. - Don't bzero() temporary block for every AES block. Do it once for entire data block. - AES-NI is available only on little endian architectures. Simplify code that takes block number from IV.
Benchmarks:
Memory-backed md(4) device, software AES-XTS, 4kB sector:
# dd if=/dev/md0.eli bs=1m 59.61MB/s
Memory-backed md(4) device, old AES-NI AES-XTS, 4kB sector:
# dd if=/dev/md0.eli bs=1m 97.29MB/s
Memory-backed md(4) device, new AES-NI AES-XTS, 4kB sector:
# dd if=/dev/md0.eli bs=1m 221.26MB/s
127% performance improvement between old and new code.
Harddisk, raw speed:
# dd if=/dev/ada0 bs=1m 137.63MB/s
Harddisk, software AES-XTS, 4kB sector:
# dd if=/dev/ada0.eli bs=1m 47.83MB/s (34% of raw disk speed)
Harddisk, old AES-NI AES-XTS, 4kB sector:
# dd if=/dev/ada0.eli bs=1m 68.33MB/s (49% of raw disk speed)
Harddisk, new AES-NI AES-XTS, 4kB sector:
# dd if=/dev/ada0.eli bs=1m 108.35MB/s (78% of raw disk speed)
58% performance improvement between old and new code.
As a side-note, GELI with AES-NI using AES-CBC can achive native disk speed.
MFC after: 3 days
|
210409 |
23-Jul-2010 |
kib |
Crypto(4) driver for AESNI.
The aeskeys_{amd64,i386}.S content was mostly obtained from OpenBSD, no objections to the license from core.
Hardware provided by: Sentex Communications Tested by: fabient, pho (previous versions) MFC after: 1 month
|
160568 |
22-Jul-2006 |
pjd |
Set ses_ictx and ses_octx to NULL after freeing them, so we won't free them twice. This is possible for example in situation when session is used in authentication context, then freed and then used in encryption context and freed - in encryption context ses_ictx and ses_octx are not touched at newsession time, but padlock_freesession could still try to free them when they are not NULL.
|
159279 |
05-Jun-2006 |
pjd |
- Pretend to accelerate various HMAC algorithms, so padlock(4) can be used with fast_ipsec(4) and geli(8) authentication (comming soon). If consumer requests only for HMAC algorithm (without encryption), return EINVAL. - Add support for the CRD_F_KEY_EXPLICIT flag, for both encryption and authentication.
|
121259 |
19-Oct-2003 |
phk |
Add a testcase which validates that the same buffer can be passed to rijndael_blockDecrypt() as both input and output.
This property is important because inside rijndael we can get away with allocating just a 16 byte "work" buffer on the stack (which is very cheap), whereas the calling code would need to allocate the full sized buffer, and in all likelyhood would have to do so with an expensive malloc(9).
|
57121 |
10-Feb-2000 |
shin |
Prototype fix for IPsec authentication related functions
Some of IPsec authentication related functions should have 'const' for its 2nd argument, but not now. But if someone try to use them, and passed const data for those functions, then much bogus compile warnings will be generated. So those funcs prototype should be modified.
Requested by: archie Approved by: jkh
|