Encrypt only some drives in a pool?

[EEE3]

I'm in the process of decrypting my pool and seeing how FreeNAS stores the drive info in the sqlite database got me wondering... would there be any (performance) value in having an option to only encrypt enough drives to make the pool unusable? For example, if it's a RAIDZ2 pool then encrypt only 3 drives. It seems like this would have performance benefits in circumstances the number of drives in the pool surpasses the number of CPU cores that can perform AES-NI. Perhaps the most elegant solution would be a sliding scale which could range from the number of drives to make the pool unmountable all the way to all drives. The recommended/optimal level might set the number of encrypted drives match the number of CPU cores.

And yes, obviously this would allow partial data recovery for someone determined to get at it but I would think for some people this would be adequate for their use case (e.g. simple theft from home).

I'm asking because I was thinking of maybe contributing to FreeNAS by adding code to decrypt/encrypt existing pools and what I describe above is functionality that you sorta could get for free along the way, assuming offering it makes any sense....

-E

 

[cyberjock]

Um, I'm seeing no value in encrypting "some" of a pool. If you lose enough disks to have an unmountable pool you can kiss all of your data goodbye. It's an "all or none" type of deal. Performance-wise the only value I can see is if someone somehow thought that the were going to use a non-AES CPU and wanted to encrypt your disks only enough to prevent mounting the pool. But to be honest, the entire idea is just ludicrous to actually consider implementing in a machine that would actually store data. I'd expect if you tried to add this "feature" it would not be accepted into the master branch. There's just no reasonable reason someone would willing want to do this.

The reality of it is without an AES-NI compatible CPU performance will just... suck. With AES-NI CPUs you'll never really be burdened with the encryption anyway. So who cares?

 

[jkh]

I'm in the process of decrypting my pool and seeing how FreeNAS stores the drive info in the sqlite database got me wondering... would there be any (performance) value in having an option to only encrypt enough drives to make the pool unusable?

Not really, no. The way data is distributed around the available drives would make it both a performance and security crapshoot. Maybe you'd get performance in some cases and you'd definitely lose security in others (the pool would not be "unusable" from an attack perspective; that's not how attacks work). All in all, this is NOT an idea worth pursuing, sorry. :)

 

[EEE3]

The reality of it is without an AES-NI compatible CPU performance will just... suck. With AES-NI CPUs you'll never really be burdened with the encryption anyway. So who cares?

Well, the reason I care is because even with AES-NI CPU's you *are* still burdened by it. For most people it probably is indeed good enough but for those pushing beyond 1GigE speeds it's a problem. My setup uses a pretty decent processor, a Xeon E3-1230 V3, and I see a bottleneck. Maybe it's the geli code that needs optimizing (I think I saw improvements in a recent FreeBSD commit actually), maybe it's AES-NI in the processor hitting its limits, maybe it's something else, that part is unclear, but something is capping it compared to unencrypted pool speeds. I figured this might be an interesting compromise to relieve some of the overhead by only encrypting enough of the drives to make it difficult to mount the pool without the key. Not impossible to access the data, just *a lot* more difficult unless you know what you're doing.

Not really, no. The way data is distributed around the available drives would make it both a performance and security crapshoot. Maybe you'd get performance in some cases and you'd definitely lose security in others (the pool would not be "unusable" from an attack perspective; that's not how attacks work). All in all, this is NOT an idea worth pursuing, sorry. :)

OK, thanks for the quick and honest response. I'll move on. :)

-E

 

[Dusan]

My setup uses a pretty decent processor, a Xeon E3-1230 V3, and I see a bottleneck.

You should look forward to FreeNAS 9.2.0 :). In FreeNAS 9.1.1 geli is only utilizing one core when using AES-NI. This commit https://bugs.freenas.org/projects/f...ions/b6e9abdd5936f233014b35a4a1f35f3f15b6e164 will make it use all available cores in the next version.

EDIT: I just realized that even now it uses one thread per provider (disk), so you will probably only see a speedup if you currently have less (encrypted) drives than CPU cores.

 

[EEE3]

EDIT: I just realized that even now it uses one thread per provider (disk), so you will probably only see a speedup if you currently have less (encrypted) drives than CPU cores.

Oh well, 10 drives in my pool so it won't help my situation out.

FWIW, this was the FreeBSD commit I previously mentioned:
http://freebsd.1045724.n5.nabble.com/patch-to-improve-AES-NI-performance-td5838064.html

http://svnweb.freebsd.org/base?view=revision&revision=254856

Did this make it into FreeNAS yet? I don't see it but maybe I'm not looking in the right place.

-E

 

[cyberjock]

We'll find out.. hopefully real soon as 9.2.0 is beta already...

https://bugs.freenas.org/issues/3539

 

[Dusan]

Did this make it into FreeNAS yet? I don't see it but maybe I'm not looking in the right place.

The change is not yet in the TrueOS branch used by FreeNAS (https://github.com/trueos/trueos/blob/feature/unified_freebsd/sys/crypto/aesni/aesni_wrap.c)

 

[cyberjock]

Dusan, that ticket is closed already. jpaetzel says it is already implemented. If its not you might want to update that ticket to say its not. Something is a little odd here and I'm not sure what...

 

[Dusan]

I now understand the confusion. There are actually two patches. You only pasted this one into the bug:
http://freebsd.1045724.n5.nabble.com/patch-to-improve-AES-NI-performance-td5838064.html
I was checking for existence of this one:
http://svnweb.freebsd.org/base?view=revision&revision=254856

 

[cyberjock]

Ah. Ok. So I assume the proper patch is applied?

 

[Dusan]

Ah. Ok. So I assume the proper patch is applied?

Nope. Completely different patch is applied :) (but that one should also improve AES-NI performance: https://bugs.freenas.org/projects/f...ions/979eccffe64c2f6b93a2bf0a2152a2552e208e0d). For those interested, more details are in redmine (https://bugs.freenas.org/issues/3539#note-8).