Re: First kernel patch (optimization)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2015-09-20 06:41, Alexander Holler wrote:
Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:
On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote:

Perhaps not so surprisingly, over a decade later, it is not currently
at the top of the priority list of any of the current file system or
VFS developers, as far as I know.  One of the reasons for that is that
there are a number of other ways of achieving the same functionality.
These include using tmpfs, or using file system level encryption.
They require a bit more system administrator setup than just being
able to set the FS_SECR_FL flag, true, but just because it's more
convenient doesn't mean that it's worth doing.

Again, I don't think that encryption is an alternative. Besides that
there is always the thread that strong encrytion will become regulated,
there is also the very real thread that someone might end up in jail
when using encryption and throwing away the key to delete stuff. E.g.,
as to my knowledge, in the UK you might end up in jail if you don't hand
out a password. So what happens if you've deleted the key and are really
unable to hand it out and the people which have an interest in what
you've once stored don't believe you?
First off, this is why I will never live in the UK. Secondly, this is why if it's something that you don't want to store for a long time (that is, longer than the system will be powered on), you use an ephemeral encryption key. Thirdly, if there is some chance you can lose the key, you make a secure backup (or do like I do and algorithmically generate passwords/encryption keys in a reproducible manner (which is itself secure if you do it right, and of course tell no-one the algorithm you use to generate them)).
So.... this is a feature request.  It's a reasonable feature request,
in that if someone would like to pay $$$ for some consultant to
implement it in a way that is bug-free, I suspect it could go
upstream.  Someone who was very motivated and with the sufficient
skills could also invest their own effort to make a patch that can go
upstream too.  You've elected not, to because you believe it would
take you months of "unpaid time".  That's purely within your rights to
do.  But you don't have the right to try to tell other people what
work to do on their behalf --- not unless you are paying their salary.

First I haven't request that someone implements it for me. Besides that
what you're describing is what maintainers do all the time. Of course,
it's their job to request quality, but, in my humble opinion, very often
they are requesting stuff just to request something.
The problem I see with this argument is:
1. There's a lot of code in the kernel that wouldn't be merged today in the state it's in, this creates a false sense of what quality is expected for new code (BTRFS in particular comes to mind here). 2. If the code can be proven to be racy, you fix it, period. Adding known racy code to the kernel should never happen. The same goes for unsafe usage of locking, RCU, or any subsystem related macros/functions. This should probably be better spelled out in SubmittingPatches. 3. Subsystem maintainers became maintainers because they have a very high degree of knowledge relating to that subsystem, and usually about general kernel programming as well. If a maintainer is asking you to fix something in your patch, I'd be more than willing to bet that they are right in asking you to fix it.
And that "month of unpaid time" was for sure a cynical exaggeration I've
done while having been angry. In fact I believe the way I've outlined
with the ugly code (proof of concept) could be implemented by someone
like you in a weekend. For me it needs quiet some more time because I
had and still have almost zero knowledge about all locks and whatever
else is used in the filesystem code. But nevertheless I was able to fix
up a lot of stuff during another afternoon. E.g. I've added checks if a
file is in use or if AT_WIPE was called on a directory and then returned
errors in those cases. Unfortunately the code changed in 4.2 and that
patch doesn't apply anymore and now, because I don't really need those
implementation details (I'm aware of the problems of my patch), I've
thrown the patch into the waste bin. Besides that my concept doesn't
work on BTRFS what I'm currently using for various reasons (mainly
compression) on most of my systems. And I have no idea if it ever will
(because I don't know why discard on BTRFS doesn't really discard what I
think it should discard. ;) ).
Discard has never really worked properly in BTRFS, although it is being worked on. If you actually care about security though, you shouldn't be using discard except when re-provisioning your storage (there are numerous papers about why on the web), trying to use that for secure deletion is creating a false sense of security.

If you're using in-line compression, then that at least means that it will take somewhat more effort to get a file off of the disk that has been deleted.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux