#
296373 |
|
04-Mar-2016 |
marius |
- Copy stable/10@296371 to releng/10.3 in preparation for 10.3-RC1 builds. - Update newvers.sh to reflect RC1. - Update __FreeBSD_version to reflect 10.3. - Update default pkg(8) configuration to use the quarterly branch.
Approved by: re (implicit) |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
238116 |
|
04-Jul-2012 |
pjd |
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
|
#
226840 |
|
27-Oct-2011 |
pjd |
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
|
#
226733 |
|
25-Oct-2011 |
pjd |
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
|
#
226730 |
|
25-Oct-2011 |
pjd |
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
|
#
226721 |
|
25-Oct-2011 |
pjd |
When metadata is at newer version than the highest supported, return EOPNOTSUPP when decoding.
MFC after: 3 days
|
#
221629 |
|
08-May-2011 |
pjd |
Detect and handle metadata of version 6.
MFC after: 1 week
|
#
221628 |
|
08-May-2011 |
pjd |
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
|
#
221626 |
|
08-May-2011 |
pjd |
Remove prototype for a function that no longer exist.
MFC after: 1 week
|
#
220922 |
|
21-Apr-2011 |
pjd |
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
|
#
214163 |
|
21-Oct-2010 |
pjd |
Free opencrypto sessions on suspend, as they also might keep encryption keys.
|
#
214118 |
|
20-Oct-2010 |
pjd |
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.
|
#
213165 |
|
25-Sep-2010 |
pjd |
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
|
#
213072 |
|
23-Sep-2010 |
pjd |
Update copyright years.
MFC after: 1 week
|
#
213070 |
|
23-Sep-2010 |
pjd |
Add support for AES-XTS. This will be the default now.
MFC after: 1 week
|
#
213067 |
|
23-Sep-2010 |
pjd |
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
|
#
213062 |
|
23-Sep-2010 |
pjd |
Define default overwrite count, so that userland can use it.
MFC after: 1 week
|
#
212845 |
|
19-Sep-2010 |
brian |
Support attaching version 4 metadata
Reviewed by: pjd
|
#
211927 |
|
28-Aug-2010 |
pjd |
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
|
#
172031 |
|
01-Sep-2007 |
pjd |
Add support for Camellia encryption algorithm.
PR: kern/113790 Submitted by: Yoshisato YANAGISAWA <yanagisawa@csg.is.titech.ac.jp> Approved by: re (bmah)
|
#
162353 |
|
16-Sep-2006 |
pjd |
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
|
#
161220 |
|
11-Aug-2006 |
pjd |
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.
|
#
161217 |
|
11-Aug-2006 |
pjd |
Forgot to bump version number after G_ELI_FLAG_READONLY flag addition.
|
#
161127 |
|
09-Aug-2006 |
pjd |
Allow geli to operate on read-only providers.
Initial patch from: vd MFC after: 2 weeks
|
#
159307 |
|
05-Jun-2006 |
pjd |
Implement data integrity verification (data authentication) for geli(8).
Supported by: Wheel Sp. z o.o. (http://www.wheel.pl)
|
#
157305 |
|
30-Mar-2006 |
pjd |
Revert previous change, as I fixed MD5(9).
|
#
157293 |
|
30-Mar-2006 |
pjd |
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
|
#
155174 |
|
01-Feb-2006 |
pjd |
Remove trailing spaces.
|
#
149323 |
|
20-Aug-2005 |
pjd |
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
|
#
149303 |
|
19-Aug-2005 |
pjd |
- Add a missing period. - Fix number of spaces.
MFC after: 3 days
|
#
148867 |
|
08-Aug-2005 |
pjd |
Be case-insensitive when dealing with algorithm names.
PR: kern/84659 Submitted by: Benjamin Lutz <benlutz@datacomm.ch>
|
#
148456 |
|
27-Jul-2005 |
pjd |
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
|