| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
when it finds corrupt data.
PR: kern/165695
Submitted by: Robert Simmons <rsimmons0@gmail.com>
Reviewed by: pjd
Approved by: cperciva
MFC after: 1 week
|
|
|
|
|
|
| |
PR: 167382
Submitted by: John W. O'Brien (john%saltant.com)
X-Needs-MFC: r226840
|
| |
|
|
|
|
|
|
|
|
| |
PR: docs/165668
Submitted by: Robert Simmons <rsimmons0@gmail.com>
Reviewed by: kaduk@mit.edu
Approved by: cperciva
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
given GEOM provider or if not providers are given it will print versions
supported by userland geli(8) utility and by ELI GEOM class.
MFC after: 3 days
|
|
|
|
|
|
|
| |
support, inform the user about that instead of 'MD5 hash mismatch'.
Suggested by: Garrett Cooper <yanegomi@gmail.com>
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
| |
As a side-effect it is now possible to backup unsupported (newer)
GELI metadata versions.
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
kern.geom.eli.version
kern.geom.eli.key_cache_limit
kern.geom.eli.key_cache_hits
kern.geom.eli.key_cache_misses
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
I'm sorry to anyone who felt offended by this.
PR: docs/155385
Reported by: maga_lena <mirto@riseup.net>
MFC after: 1 week
|
|
|
|
|
| |
WARNS=6 causes "warning: cast increases required alignment of target type"
on arm, ia64, mips, and sparc64.
|
| |
|
|
|
|
|
|
| |
While I'm here remove redundancy and inconsistencies.
Obtained from: Juniper Networks
|
|
|
|
|
|
|
| |
* Correct a typo while I'm there.
Reviewed by: pjd
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
| |
big sector size. When gctl error is set gctl_has_param() always returns
'false', which prevents geli(8) from finding some arguments and also masks
an error, which is generates in such case.
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Suggested by: kib
Approved by: kib (mentor)
MFC after: 5 days
|
|
|
|
|
|
|
|
|
|
| |
This is especially useful for things like installers, where regular
geli prompt can't be used.
- Add support for specifing multiple -K or -k options, so there is no
need to cat all keyfiles and read them from standard input.
Requested by: Kris Moore <kris@pcbsd.org>, thompsa
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
| |
- Flush write cache after each write.
MFC after: 1 week
|
|
|
|
|
|
| |
- fsync() created filed.
MFC after: 1 week
|
|
|
|
|
|
|
| |
don't want situation where old size is equal to new size, as we will trash
newly written metadata.
MFC after: 1 week
|
|
|
|
|
|
| |
- Flush cache after writing metadata.
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to growing the filesystem.
Refuse to attach providers where the metadata provider size is
wrong. This makes post-boot attaches behave consistently with
pre-boot attaches. Also refuse to restore metadata to a provider
of the wrong size without the new -f switch. The new -f switch
forces the metadata restoration despite the provider size, and
updates the provider size in the restored metadata to the correct
value.
Helped by: pjd
Reviewed by: pjd
|
| |
|
|
|
|
|
|
|
| |
understand everything correctly, we don't really need it.
- Provide default numeric value as strings. This allows to simplify
a lot of code.
- Bump version number.
|
|
|
|
| |
- Make optional string values always an empty string.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
once it is lost, all data is gone.
Option '-B none' can by used to prevent backup. Option '-B path' can be
used to backup metadata to a different file than the default, which is
/var/backups/<prov>.eli.
The 'geli init' command also prints backup file location and gives short
procedure how to restore metadata.
The 'geli setkey' command now warns that even after passphrase change or keys
update there could be version of the master key encrypted with old
keys/passphrase in the backup file.
Add regression tests to verify that new functionality works as expected.
Update other regression tests so they don't create backup files.
Reviewed by: keramida, rink
Dedicated to: a friend who lost 400GB of his live by accidentally overwritting geli metadata
MFC after: 2 weeks
|
|
|
|
| |
- Keep options in alphabetical order.
|
| |
|
|
|
|
|
|
| |
PR: kern/113790
Submitted by: Yoshisato YANAGISAWA <yanagisawa@csg.is.titech.ac.jp>
Approved by: re (bmah)
|
|
|
|
|
|
|
| |
In order to support gpart(8), geom(8) needs to support a named
argument. Also, optional string parameters are a requirement.
Both have been added to the infrastructure. The former required
all existing classes to be adjusted.
|
| |
|
|
|
|
| |
leaving the functions.
|
|
|
|
|
|
|
|
| |
to problems when the geli device is used with file system or as a swap.
Hopefully will prevent problems like kern/98742 in the future.
MFC after: 1 week
|
|
|
|
|
|
|
| |
course! It won't protect against reply attacks - try harder to explain
them correctly.
MFC after: 1 week
|
|
|
|
| |
Spotted by: Tomasz Dudzisz
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- First configured key is based only on keyfile (no passphrase).
- Device is attached.
- User changes first key (setkey) from keyfile to passphrase and doesn't
specify number of iterations (with -i option).
...geli(8) won't store calculated number of iterations in metadata.
This result in device beeing unaccesable after detach.
One can recover from this situation by guessing number of iterations
generated, storing it in metadata and trying to attach device.
Recovery procedure isn't nice, but one's data is not lost.
Reported by: Thomas Nickl <T.Nickl@gmx.net>
MFC after: 1 week
|
|
|
|
| |
Changes: 98722
|
| |
|
|
|
|
| |
Submitted by: Matthias Lederhofer <matled@gmx.net>
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
MFC after: 1 week
|