#
330737 |
|
10-Mar-2018 |
asomers |
MFC r323314, r323338, r328849
r323314: Audit userspace geom code for leaking memory to disk
Any geom class using g_metadata_store, as well as geom_virstor which duplicated g_metadata_store internally, would dump sectorsize - mdsize bytes of userspace memory following the metadata block stored. This is most or all geom classes (gcache, gconcat, geli, gjournal, glabel, gmirror, gmultipath, graid3, gshsec, gstripe, and geom_virstor).
PR: 222077 (comment #3) Reported by: Maxim Khitrov <max AT mxcrypt.com> Reviewed by: des Security: yes Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12269
r323338: Fix information leak in geli(8) integrity mode
In integrity mode, a larger logical sector (e.g., 4096 bytes) spans several physical sectors (e.g., 512 bytes) on the backing device. Due to hash overhead, a 4096 byte logical sector takes 8.5625 512-byte physical sectors. This means that only 288 bytes (256 data + 32 hash) of the last 512 byte sector are used.
The memory allocation used to store the encrypted data to be written to the physical sectors comes from malloc(9) and does not use M_ZERO.
Previously, nothing initialized the final physical sector backing each logical sector, aside from the hash + encrypted data portion. So 224 bytes of kernel heap memory was leaked to every block :-(.
This patch addresses the issue by initializing the trailing portion of the physical sector in every logical sector to zeros before use. A much simpler but higher overhead fix would be to tag the entire allocation M_ZERO.
PR: 222077 Reported by: Maxim Khitrov <max AT mxcrypt.com> Reviewed by: emaste Security: yes Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12272
r328849: geom: don't write stack garbage in disk labels
Most consumers of g_metadata_store were passing in partially unallocated memory, resulting in stack garbage being written to disk labels. Fix them by zeroing the memory first.
gvirstor repeated the same mistake, but in the kernel.
Also, glabel's label contained a fixed-size string that wasn't initialized to zero.
PR: 222077 Reported by: Maxim Khitrov <max@mxcrypt.com> Reviewed by: cem X-MFC-With: 323314 X-MFC-With: 323338 Differential Revision: https://reviews.freebsd.org/D14164
|
#
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 |
#
235419 |
|
13-May-2012 |
eadler |
Add missing period at the end of the error message
Submitted by: pjd Approved by: cperciva (implicit) MFC after: 3 days X-MFC-With: r235201
|
#
235201 |
|
09-May-2012 |
eadler |
Clarify error that geli generates 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
|
#
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
|
#
221625 |
|
08-May-2011 |
pjd |
Drop proper key.
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
|
#
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.
|
#
214116 |
|
20-Oct-2010 |
pjd |
- Add missing comments. - Make a comment consistent with others.
|
#
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
|
#
160569 |
|
22-Jul-2006 |
pjd |
Don't forget to initialize crp_olen field, which is used to calculate bio_completed value.
|
#
159344 |
|
06-Jun-2006 |
pjd |
Force commit as I forgot to document:
- Don't initialize crp_olen, it should be set by the driver. - crp_ilen should contain length of the entier buffer.
|
#
159343 |
|
06-Jun-2006 |
pjd |
- Unbreak the build when geli is compiled into the kernel (on as module), by silencing unfounded compiler warning.
Reported by:
|
#
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)
|