#
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
|
#
239184 |
|
10-Aug-2012 |
pjd |
Always initialize sc_ekey, because as of r238116 it is always used.
If GELI provider was created on FreeBSD HEAD r238116 or later (but before this change), it is using very weak keys and the data is not protected. The bug was introduced on 4th July 2012.
One can verify if its provider was created with weak keys by running:
# geli dump <provider> | grep version
If the version is 7 and the system didn't include this fix when provider was initialized, then the data has to be backed up, underlying provider overwritten with random data, system upgraded and provider recreated.
Reported by: Fabian Keil <fk@fabiankeil.de> Tested by: Fabian Keil <fk@fabiankeil.de> Discussed with: so MFC after: 3 days
|
#
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
|
#
238115 |
|
04-Jul-2012 |
pjd |
Correct comment.
MFC after: 3 days
|
#
221953 |
|
15-May-2011 |
trociny |
Fix a memory leak possible in g_eli_key_allocate() if the key with the same keyno is added while we aren't holding the lock.
Approved by: pjd (mentor) MFC after: 1 week
|
#
221624 |
|
08-May-2011 |
pjd |
Add magic field to the g_eli_key structure to detect if we are really operating on proper structures.
MFC after: 1 week
|
#
220984 |
|
24-Apr-2011 |
pjd |
One key is expected from providers smaller than or equal to (2^20)*sectorsize bytes. Remove bogus assertion and while here remove another too obvious assertion.
Reported by: Fabian Keil <freebsd-listen@fabiankeil.de> MFC after: 2 weeks
|
#
220923 |
|
21-Apr-2011 |
pjd |
If number of keys for the given provider doesn't exceed the limit, allocate all of them at attach time. This allows to avoid moving keys around in the most-recently-used queue and needs no mutex synchronization nor refcounting.
MFC after: 2 weeks
|
#
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
|