Re: First kernel patch (optimization)

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5246 bytes --]

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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]