History log of /freebsd-current/sys/geom/eli/g_eli.h
Revision Date Author Comments
# 95ee2897 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix


# 2dbc9a38 28-Sep-2021 Gleb Smirnoff <glebius@FreeBSD.org>

Fix memory deadlock when GELI partition is used for swap.

When we get low on memory, the VM system tries to free some by swapping
pages. However, if we are so low on free pages that GELI allocations block,
then the swapout operation cannot complete. This keeps the VM system from
being able to free enough memory so the allocation can complete.

To alleviate this, keep a UMA pool at the GELI layer which is used for data
buffer allocation in the fast path, and reserve some of that memory for swap
operations. If an IO operation is a swap, then use the reserved memory. If
the allocation still fails, return ENOMEM instead of blocking.

For non-swap allocations, change the default to using M_NOWAIT. In general,
this *should* be better, since it gives upper layers a signal of the memory
pressure and a chance to manage their failure strategy appropriately. However,
a user can set the kern.geom.eli.blocking_malloc sysctl/tunable to restore
the previous M_WAITOK strategy.

Submitted by: jtl
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D24400


# 0c97af56 14-Sep-2020 Warner Losh <imp@FreeBSD.org>

We don't need the sc_ekeys_lock in standalone environment.

When we bring in geli into the boot loader, we are single threaded so
we don't have to worry about locking. We have no mutexes, and don't need
to use them, so comment it out.

MFC After: 3 days


# a3d565a1 09-Jun-2020 John Baldwin <jhb@FreeBSD.org>

Add a crypto capability flag for accelerated software drivers.

Use this in GELI to print out a different message when accelerated
software such as AESNI is used vs plain software crypto.

While here, simplify the logic in GELI a bit for determing which type
of crypto driver was chosen the first time by examining the
capabilities of the matched driver after a single call to
crypto_newsession rather than making separate calls with different
flags.

Reviewed by: delphij
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D25126


# bfe26b97 15-Apr-2020 John Baldwin <jhb@FreeBSD.org>

Mark eli_metadata_crypto_supported inline.

This quiets warnings about it not being always used.

Reported by: kevans


# e2b99193 14-Apr-2020 John Baldwin <jhb@FreeBSD.org>

Remove support for geli(4) algorithms deprecated in r348206.

This removes support for reading and writing volumes using the
following algorithms:

- Triple DES
- Blowfish
- MD5 HMAC integrity

In addition, this commit adds an explicit whitelist of supported
algorithms to give a better error message when an invalid or
unsupported algorithm is used by an existing volume.

Reviewed by: cem
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D24343


# c0341432 27-Mar-2020 John Baldwin <jhb@FreeBSD.org>

Refactor driver and consumer interfaces for OCF (in-kernel crypto).

- The linked list of cryptoini structures used in session
initialization is replaced with a new flat structure: struct
crypto_session_params. This session includes a new mode to define
how the other fields should be interpreted. Available modes
include:

- COMPRESS (for compression/decompression)
- CIPHER (for simply encryption/decryption)
- DIGEST (computing and verifying digests)
- AEAD (combined auth and encryption such as AES-GCM and AES-CCM)
- ETA (combined auth and encryption using encrypt-then-authenticate)

Additional modes could be added in the future (e.g. if we wanted to
support TLS MtE for AES-CBC in the kernel we could add a new mode
for that. TLS modes might also affect how AAD is interpreted, etc.)

The flat structure also includes the key lengths and algorithms as
before. However, code doesn't have to walk the linked list and
switch on the algorithm to determine which key is the auth key vs
encryption key. The 'csp_auth_*' fields are always used for auth
keys and settings and 'csp_cipher_*' for cipher. (Compression
algorithms are stored in csp_cipher_alg.)

- Drivers no longer register a list of supported algorithms. This
doesn't quite work when you factor in modes (e.g. a driver might
support both AES-CBC and SHA2-256-HMAC separately but not combined
for ETA). Instead, a new 'crypto_probesession' method has been
added to the kobj interface for symmteric crypto drivers. This
method returns a negative value on success (similar to how
device_probe works) and the crypto framework uses this value to pick
the "best" driver. There are three constants for hardware
(e.g. ccr), accelerated software (e.g. aesni), and plain software
(cryptosoft) that give preference in that order. One effect of this
is that if you request only hardware when creating a new session,
you will no longer get a session using accelerated software.
Another effect is that the default setting to disallow software
crypto via /dev/crypto now disables accelerated software.

Once a driver is chosen, 'crypto_newsession' is invoked as before.

- Crypto operations are now solely described by the flat 'cryptop'
structure. The linked list of descriptors has been removed.

A separate enum has been added to describe the type of data buffer
in use instead of using CRYPTO_F_* flags to make it easier to add
more types in the future if needed (e.g. wired userspace buffers for
zero-copy). It will also make it easier to re-introduce separate
input and output buffers (in-kernel TLS would benefit from this).

Try to make the flags related to IV handling less insane:

- CRYPTO_F_IV_SEPARATE means that the IV is stored in the 'crp_iv'
member of the operation structure. If this flag is not set, the
IV is stored in the data buffer at the 'crp_iv_start' offset.

- CRYPTO_F_IV_GENERATE means that a random IV should be generated
and stored into the data buffer. This cannot be used with
CRYPTO_F_IV_SEPARATE.

If a consumer wants to deal with explicit vs implicit IVs, etc. it
can always generate the IV however it needs and store partial IVs in
the buffer and the full IV/nonce in crp_iv and set
CRYPTO_F_IV_SEPARATE.

The layout of the buffer is now described via fields in cryptop.
crp_aad_start and crp_aad_length define the boundaries of any AAD.
Previously with GCM and CCM you defined an auth crd with this range,
but for ETA your auth crd had to span both the AAD and plaintext
(and they had to be adjacent).

crp_payload_start and crp_payload_length define the boundaries of
the plaintext/ciphertext. Modes that only do a single operation
(COMPRESS, CIPHER, DIGEST) should only use this region and leave the
AAD region empty.

If a digest is present (or should be generated), it's starting
location is marked by crp_digest_start.

Instead of using the CRD_F_ENCRYPT flag to determine the direction
of the operation, cryptop now includes an 'op' field defining the
operation to perform. For digests I've added a new VERIFY digest
mode which assumes a digest is present in the input and fails the
request with EBADMSG if it doesn't match the internally-computed
digest. GCM and CCM already assumed this, and the new AEAD mode
requires this for decryption. The new ETA mode now also requires
this for decryption, so IPsec and GELI no longer do their own
authentication verification. Simple DIGEST operations can also do
this, though there are no in-tree consumers.

To eventually support some refcounting to close races, the session
cookie is now passed to crypto_getop() and clients should no longer
set crp_sesssion directly.

- Assymteric crypto operation structures should be allocated via
crypto_getkreq() and freed via crypto_freekreq(). This permits the
crypto layer to track open asym requests and close races with a
driver trying to unregister while asym requests are in flight.

- crypto_copyback, crypto_copydata, crypto_apply, and
crypto_contiguous_subsegment now accept the 'crp' object as the
first parameter instead of individual members. This makes it easier
to deal with different buffer types in the future as well as
separate input and output buffers. It's also simpler for driver
writers to use.

- bus_dmamap_load_crp() loads a DMA mapping for a crypto buffer.
This understands the various types of buffers so that drivers that
use DMA do not have to be aware of different buffer types.

- Helper routines now exist to build an auth context for HMAC IPAD
and OPAD. This reduces some duplicated work among drivers.

- Key buffers are now treated as const throughout the framework and in
device drivers. However, session key buffers provided when a session
is created are expected to remain alive for the duration of the
session.

- GCM and CCM sessions now only specify a cipher algorithm and a cipher
key. The redundant auth information is not needed or used.

- For cryptosoft, split up the code a bit such that the 'process'
callback now invokes a function pointer in the session. This
function pointer is set based on the mode (in effect) though it
simplifies a few edge cases that would otherwise be in the switch in
'process'.

It does split up GCM vs CCM which I think is more readable even if there
is some duplication.

- I changed /dev/crypto to support GMAC requests using CRYPTO_AES_NIST_GMAC
as an auth algorithm and updated cryptocheck to work with it.

- Combined cipher and auth sessions via /dev/crypto now always use ETA
mode. The COP_F_CIPHER_FIRST flag is now a no-op that is ignored.
This was actually documented as being true in crypto(4) before, but
the code had not implemented this before I added the CIPHER_FIRST
flag.

- I have not yet updated /dev/crypto to be aware of explicit modes for
sessions. I will probably do that at some point in the future as well
as teach it about IV/nonce and tag lengths for AEAD so we can support
all of the NIST KAT tests for GCM and CCM.

- I've split up the exising crypto.9 manpage into several pages
of which many are written from scratch.

- I have converted all drivers and consumers in the tree and verified
that they compile, but I have not tested all of them. I have tested
the following drivers:

- cryptosoft
- aesni (AES only)
- blake2
- ccr

and the following consumers:

- cryptodev
- IPsec
- ktls_ocf
- GELI (lightly)

I have not tested the following:

- ccp
- aesni with sha
- hifn
- kgssapi_krb5
- ubsec
- padlock
- safe
- armv8_crypto (aarch64)
- glxsb (i386)
- sec (ppc)
- cesa (armv7)
- cryptocteon (mips64)
- nlmsec (mips64)

Discussed with: cem
Relnotes: yes
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D23677


# ac03832e 07-Aug-2019 Conrad Meyer <cem@FreeBSD.org>

GEOM: Reduce unnecessary log interleaving with sbufs

Similar to what was done for device_printfs in r347229.

Convert g_print_bio() to a thin shim around g_format_bio(), which acts on an
sbuf; documented in g_bio.9.

Reviewed by: markj
Discussed with: rlibby
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D21165


# e7630efb 12-Jun-2019 Mariusz Zaborski <oshogbo@FreeBSD.org>

geli: partially revert r348709

Let's change the unsigned arguments to the signed one, but let's don't
change pointers to the array notation.

Requested by: pjd


# 1808673c 05-Jun-2019 Mariusz Zaborski <oshogbo@FreeBSD.org>

geli: build warning fixes

Submitted by: Aaron Prieger <aprieger@llnw.com>
Reviewed by: sbruno
Differential Revision: https://reviews.freebsd.org/D11068


# 2f07cdf8 03-Apr-2019 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Implement automatic online expansion of GELI providers - if the underlying
provider grows, GELI will expand automatically and will move the metadata
to the new location of the last sector.

This functionality is turned on by default. It can be turned off with the
-R flag, but it is not recommended - if the underlying provider grows and
automatic expansion is turned off, it won't be possible to attach this
provider again, as the metadata is no longer located in the last sector.

If the automatic expansion is turned off and the underlying provider grows,
GELI will only log a message with the previous size of the provider, so
recovery can be easier.

Obtained from: Fudo Security


# 1df7f415 16-Jul-2018 Conrad Meyer <cem@FreeBSD.org>

OCF: Convert consumers to the session id typedef

These were missed in the earlier r336269.

No functional change.

Sponsored by: Dell EMC Isilon


# 31f7586d 09-May-2018 Mariusz Zaborski <oshogbo@FreeBSD.org>

Introduce the 'n' flag for the geli attach command.

If the 'n' flag is provided the provided key number will be used to
decrypt device. This can be used combined with dryrun to verify if the key
is set correctly. This can be also used to determine which key slot we want to
change on already attached device.

Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D15309


# 3728855a 27-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys/geom: adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.


# 3453dc72 26-Aug-2017 Mariusz Zaborski <oshogbo@FreeBSD.org>

Hide length of geli passphrase during boot.

Introduce additional flag to the geli which allows to restore previous
behavior.

Reviewed by: AllanJude@, cem@ (previous version)
MFC: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D11751


# d109d8ad 21-Apr-2017 Alexander Motin <mav@FreeBSD.org>

Dump md_iterations as signed, which it really is.

PR: 208305
PR: 196834
MFC after: 2 weeks


# ec5c0e5b 31-Mar-2017 Allan Jude <allanjude@FreeBSD.org>

Implement boot-time encryption key passing (keybuf)

This patch adds a general mechanism for providing encryption keys to the
kernel from the boot loader. This is intended to enable GELI support at
boot time, providing a better mechanism for passing keys to the kernel
than environment variables. It is designed to be extensible to other
applications, and can easily handle multiple encrypted volumes with
different keys.

This mechanism is currently used by the pending GELI EFI work.
Additionally, this mechanism can potentially be used to interface with
GRUB, opening up options for coreboot+GRUB configurations with completely
encrypted disks.

Another benefit over the existing system is that it does not require
re-deriving the user key from the password at each boot stage.

Most of this patch was written by Eric McCorkle. It was extended by
Allan Jude with a number of minor enhancements and extending the keybuf
feature into boot2.

GELI user keys are now derived once, in boot2, then passed to the loader,
which reuses the key, then passes it to the kernel, where the GELI module
destroys the keybuf after decrypting the volumes.

Submitted by: Eric McCorkle <eric@metricspace.net> (Original Version)
Reviewed by: oshogbo (earlier version), cem (earlier version)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9575


# 85c15ab8 19-Feb-2017 Allan Jude <allanjude@FreeBSD.org>

improve PBKDF2 performance

The PBKDF2 in sys/geom/eli/pkcs5v2.c is around half the speed it could be

GELI's PBKDF2 uses a simple benchmark to determine a number of iterations
that will takes approximately 2 seconds. The security provided is actually
half what is expected, because an attacker could use the optimized
algorithm to brute force the key in half the expected time.

With this change, all newly generated GELI keys will be approximately 2x
as strong. Previously generated keys will talk half as long to calculate,
resulting in faster mounting of encrypted volumes. Users may choose to
rekey, to generate a new key with the larger default number of iterations
using the geli(8) setkey command.

Security of existing data is not compromised, as ~1 second per brute force
attempt is still a very high threshold.

PR: 202365
Original Research: https://jbp.io/2015/08/11/pbkdf2-performance-matters/
Submitted by: Joe Pixton <jpixton@gmail.com> (Original Version), jmg (Later Version)
Reviewed by: ed, pjd, delphij
Approved by: secteam, pjd (maintainer)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D8236


# ae8b1f90 31-Oct-2016 Ruslan Bukin <br@FreeBSD.org>

Fix alignment issues on MIPS: align the pointers properly.

All the 5520 GEOM_ELI tests passed successfully on MIPS64EB.

Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
Differential Revision: https://reviews.freebsd.org/D7905


# d8736625 07-Apr-2016 Allan Jude <allanjude@FreeBSD.org>

Create the GELIBOOT GEOM_ELI flag

This flag indicates that the user wishes to use the GELIBOOT feature to boot from a fully encrypted root file system.
Currently, GELIBOOT does not support key files, and in the future when it does, they will be loaded differently.
Due to the design of GELI, and the desire for secrecy, the GELI metadata does not know if key files are used or not, it just adds the key material (if any) to the HMAC before the optional passphrase, so there is no way to tell if a GELI partition requires key files or not.

Since the GELIBOOT code in boot2 and the loader does not support keys, they will now only attempt to attach if this flag is set. This will stop GELIBOOT from prompting for passwords to GELIs that it cannot decrypt, disrupting the boot process

PR: 208251
Reviewed by: ed, oshogbo, wblock
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D5867


# 4332feca 06-Jan-2016 Allan Jude <allanjude@FreeBSD.org>

Make additional parts of sys/geom/eli more usable in userspace

The upcoming GELI support in the loader reuses parts of this code
Some ifdefs are added, and some code is moved outside of existing ifdefs

The HMAC parts of GELI are broken out into their own file, to separate
them from the kernel crypto/openssl dependant parts that are replaced
in the boot code.

Passed the GELI regression suite (tools/regression/geom/eli)
Files=20 Tests=14996
Result: PASS

Reviewed by: pjd, delphij
MFC after: 1 week
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D4699


# 7a3f5d11 27-Dec-2015 Allan Jude <allanjude@FreeBSD.org>

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


# 46e34470 08-Aug-2015 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Enable BIO_DELETE passthru in GELI, so TRIM/UNMAP can work as expected when
GELI is used on a SSD or inside virtual machine, so that guest can tell
host that it is no longer using some of the storage.

Enabling BIO_DELETE passthru comes with a small security consequence - an
attacker can tell how much space is being really used on encrypted device and
has less data no analyse then. This is why the -T option can be given to the
init subcommand to turn off this behaviour and -t/T options for the configure
subcommand can be used to adjust this setting later.

PR: 198863
Submitted by: Matthew D. Fuller fullermd at over-yonder dot net

This commit also includes a fix from Fabian Keil freebsd-listen at
fabiankeil.de for 'configure' on onetime providers which is not strictly
related, but is entangled in the same code, so would cause conflicts if
separated out.


# 457bbc4f 04-Jul-2012 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Use correct part of the Master-Key for generating encryption keys.
Before this change the IV-Key was used to generate encryption keys,
which was incorrect, but safe - for the XTS mode this key was unused
anyway and for CBC mode it was used differently to generate IV
vectors, so there is no risk that IV vector collides with encryption
key somehow.

Bump version number and keep compatibility for older versions.

MFC after: 2 weeks


# 0c879bd9 27-Oct-2011 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Before this change when GELI detected hardware crypto acceleration it will
start only one worker thread. For software crypto it will start by default
N worker threads where N is the number of available CPUs.

This is not optimal if hardware crypto is AES-NI, which uses CPU for AES
calculations.

Change that to always start one worker thread for every available CPU.
Number of worker threads per GELI provider can be easly reduced with
kern.geom.eli.threads sysctl/tunable and even for software crypto it
should be reduced when using more providers.

While here, when number of threads exceeds number of CPUs avilable don't
reduce this number, assume the user knows what he is doing.

Reported by: Yuri Karaban <dev@dev97.com>
MFC after: 3 days


# 1f8c92e6 25-Oct-2011 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Add support for creating GELI devices with older metadata version for use
with older FreeBSD versions:
- Add -V option to 'geli init' to specify version number. If no -V is given
the most recent version is used.
- If -V is given don't allow to use features not supported by this version.
- Print version in 'geli list' output.
- Update manual page and add table describing which GELI version is
supported by which FreeBSD version, so one can use it when preparing GELI
device for older FreeBSD version.

Inspired by: Garrett Cooper <yanegomi@gmail.com>
MFC after: 3 days


# effb9912 25-Oct-2011 Pawel Jakub Dawidek <pjd@FreeBSD.org>

When decoding metadata, check magic string, so we know this is not GELI device
before we check its version. We don't want to report that some garbage is
unsupported version if this is not even GELI provider.

MFC after: 3 days


# e880ff00 25-Oct-2011 Pawel Jakub Dawidek <pjd@FreeBSD.org>

When metadata is at newer version than the highest supported, return
EOPNOTSUPP when decoding.

MFC after: 3 days


# 964d172c 08-May-2011 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Detect and handle metadata of version 6.

MFC after: 1 week


# ad0a5236 08-May-2011 Pawel Jakub Dawidek <pjd@FreeBSD.org>

When support for multiple encryption keys was committed, GELI integrity mode
was not updated to pass CRD_F_KEY_EXPLICIT flag to opencrypto. This resulted in
always using first key.

We need to support providers created with this bug, so set special
G_ELI_FLAG_FIRST_KEY flag for GELI provider in integrity mode with version
smaller than 6 and pass the CRD_F_KEY_EXPLICIT flag to opencrypto only if
G_ELI_FLAG_FIRST_KEY doesn't exist.

Reported by: Anton Yuzhaninov <citrin@citrin.ru>
MFC after: 1 week


# 9d644a40 08-May-2011 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Remove prototype for a function that no longer exist.

MFC after: 1 week


# 1e09ff3d 21-Apr-2011 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Instead of allocating memory for all the keys at device attach,
create reasonably large cache for the keys that is filled when
needed. The previous version was problematic for very large providers
(hundreds of terabytes or serval petabytes). Every terabyte of data
needs around 256kB for keys. Make the default cache limit big enough
to fit all the keys needed for 4TB providers, which will eat at most
1MB of memory.

MFC after: 2 weeks


# 3ac01bc2 21-Oct-2010 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Free opencrypto sessions on suspend, as they also might keep encryption keys.


# 5ad4a7c7 20-Oct-2010 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Bring in geli suspend/resume functionality (finally).

Before this change if you wanted to suspend your laptop and be sure that your
encryption keys are safe, you had to stop all processes that use file system
stored on encrypted device, unmount the file system and detach geli provider.

This isn't very handy. If you are a lucky user of a laptop where suspend/resume
actually works with FreeBSD (I'm not!) you most likely want to suspend your
laptop, because you don't want to start everything over again when you turn
your laptop back on.

And this is where geli suspend/resume steps in. When you execute:

# geli suspend -a

geli will wait for all in-flight I/O requests, suspend new I/O requests, remove
all geli sensitive data from the kernel memory (like encryption keys) and will
wait for either 'geli resume' or 'geli detach'.

Now with no keys in memory you can suspend your laptop without stopping any
processes or unmounting any file systems.

When you resume your laptop you have to resume geli devices using 'geli resume'
command. You need to provide your passphrase, etc. again so the keys can be
restored and suspended I/O requests released.

Of course you need to remember that 'geli suspend' won't clear file system
cache and other places where data from your geli-encrypted file system might be
present. But to get rid of those stopping processes and unmounting file system
won't help either - you have to turn your laptop off. Be warned.

Also note, that suspending geli device which contains file system with geli
utility (or anything used by 'geli resume') is not very good idea, as you won't
be able to resume it - when you execute geli(8), the kernel will try to read it
and this read I/O request will be suspended.


# a7d5f7eb 19-Oct-2010 Jamie Gritton <jamie@FreeBSD.org>

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.


# f95168e0 25-Sep-2010 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Change g_eli_debug to int, so one can turn off any GELI output by setting
kern.geom.eli.debug sysctl to -1.

MFC after: 2 weeks


# 9839c97b 22-Sep-2010 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Update copyright years.

MFC after: 1 week


# 9a5a1d1e 23-Sep-2010 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Add support for AES-XTS. This will be the default now.

MFC after: 1 week


# c6a26d4c 23-Sep-2010 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Implement switching of data encryption key every 2^20 blocks.
This ensures the same encryption key won't be used for more than
2^20 blocks (sectors). This will be the default now.

MFC after: 1 week


# b35bfe7e 23-Sep-2010 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Define default overwrite count, so that userland can use it.

MFC after: 1 week


# 0f81f304 19-Sep-2010 Brian Somers <brian@FreeBSD.org>

Support attaching version 4 metadata

Reviewed by: pjd


# efb46508 28-Aug-2010 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Correct offset conversion to little endian. It was implemented in version 2,
but because of a bug it was a no-op, so we were still using offsets in native
byte order for the host. Do it properly this time, bump version to 4 and set
the G_ELI_FLAG_NATIVE_BYTE_ORDER flag when version is under 4.

MFC after: 2 weeks


# d7f03759 19-Oct-2008 Ulf Lilleengen <lulf@FreeBSD.org>

- Import the HEAD csup code which is the basis for the cvsmode work.


# 864cba96 01-Sep-2007 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Add support for Camellia encryption algorithm.

PR: kern/113790
Submitted by: Yoshisato YANAGISAWA <yanagisawa@csg.is.titech.ac.jp>
Approved by: re (bmah)


# 8abd1ad1 16-Sep-2006 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Add 'configure' subcommand which for now only allows setting and removing
of the BOOT flag. It can be performed on both attached and detached
providers.

Requested by: Matthias Lederhofer <matled@gmx.net>
MFC after: 1 week


# 2bd4ade6 11-Aug-2006 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Before using byte offset for IV creation, covert it to little endian.
This way one will be able to use provider encrypted on eg. i386 on
eg. sparc64. This doesn't really buy us much today, because UFS isn't
endian agnostic.

We retain backward compatibility by setting G_ELI_FLAG_NATIVE_BYTE_ORDER
flag on devices with version number less than 2 and not converting the
offset.


# d04c304d 11-Aug-2006 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Forgot to bump version number after G_ELI_FLAG_READONLY flag addition.


# 85059016 09-Aug-2006 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Allow geli to operate on read-only providers.

Initial patch from: vd
MFC after: 2 weeks


# eaa3b919 05-Jun-2006 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Implement data integrity verification (data authentication) for geli(8).

Supported by: Wheel Sp. z o.o. (http://www.wheel.pl)


# 700e04d9 30-Mar-2006 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Revert previous change, as I fixed MD5(9).


# 8e888089 30-Mar-2006 Pawel Jakub Dawidek <pjd@FreeBSD.org>

md_hash field in g_eli_metadata structure is not 4 byte aligned, which
case panic on sparc64.

The problem is in MD5(9) implementation. The Encode() function takes
'unsigned char *output' as its first argument, which is then assigned to
'u_int32_t *op'. If the 'output' argument is not 4 byte aligned (and in
geli(8) case it is not), sparc64 machine will panic.

I don't know how to fix MD5(9) in a clean way, so I'm implementing a
work-around in geli(8).

Reported by: brueffer
MFC after: 3 days


# 38ea96ac 31-Jan-2006 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Remove trailing spaces.


# efd9ac0d 20-Aug-2005 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Add a __packed keyword to g_eli_metadata struct definition, so
sizeof(struct g_eli_metadata) will return the exact number of bytes needed
for storing it on the disk.
Without this change GELI was unusable on amd64 (and probably other 64-bit
archs), because sizeof(struct g_eli_metadata) was greater than 512 bytes
and geli(8) was failing on assertion.

Reported by: Michael Reifenberger <mike@Reifenberger.com>
MFC after: 3 days


# fcd46203 19-Aug-2005 Pawel Jakub Dawidek <pjd@FreeBSD.org>

- Add a missing period.
- Fix number of spaces.

MFC after: 3 days


# 6eb1d21f 08-Aug-2005 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Be case-insensitive when dealing with algorithm names.

PR: kern/84659
Submitted by: Benjamin Lutz <benlutz@datacomm.ch>


# c58794de 27-Jul-2005 Pawel Jakub Dawidek <pjd@FreeBSD.org>

Add GEOM_ELI class which provides GEOM providers encryption.
For features list and usage see manual page: geli(8).

Sponsored by: Wheel Sp. z o.o.
http://www.wheel.pl
MFC after: 1 week