Merging backported fscrypt to 4.4?

Merging backported fscrypt to 4.4?

[Anton Altaparmakov]

Hi Greg,

As 4.4 is now going to be "the stable kernel" until 2022 and we have backported fscrypt to 4.4.  Currently we (that is Tuxera) have it as an out of tree proof of concept module and we could maintain it like that but given the kernel is going to be around for another 5 years perhaps it would be useful for everyone to have fscrypt in the stable 4.4 tree itself...  Then ext4/f2fs could support fscrypt based encryption in the 4.4 kernel which is of interest to many device manufacturers (which is why we have done the backport - it was driven by customers)...

What do you think?  Would you accept a backported fscrypt into the stable 4.4 tree?

Note, the reason I am asking before sending patches is that we need to make some changes to our current backport if it is going into the kernel as we need to update the struct inode and struct super_block.  (We currently work around this in the out of tree fscrypt module but it would be much cleaner to have it all done in the correct places as it is in the current fscrypt in mainline.)

Best regards,

	Anton
-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer

Re: Merging backported fscrypt to 4.4?

[Greg KH]

On Thu, Oct 12, 2017 at 11:59:03AM +0000, Anton Altaparmakov wrote:
> Hi Greg,
> 
> As 4.4 is now going to be "the stable kernel" until 2022 and we have backported fscrypt to 4.4.  Currently we (that is Tuxera) have it as an out of tree proof of concept module and we could maintain it like that but given the kernel is going to be around for another 5 years perhaps it would be useful for everyone to have fscrypt in the stable 4.4 tree itself...  Then ext4/f2fs could support fscrypt based encryption in the 4.4 kernel which is of interest to many device manufacturers (which is why we have done the backport - it was driven by customers)...
> 
> What do you think?  Would you accept a backported fscrypt into the stable 4.4 tree?

The LTS rules are still the same, no matter if I maintain it for a few
months, or a few years/decades.  So how does adding a bunch of new code
for no in-kernel users fit into the existing rules?

If a device manufacture wants the fscrypt feature, great, use a newer
kernel (like 4.9 or better yet, 4.14.)  It's always best to use newer
kernels, right?

> Note, the reason I am asking before sending patches is that we need to make some changes to our current backport if it is going into the kernel as we need to update the struct inode and struct super_block.  (We currently work around this in the out of tree fscrypt module but it would be much cleaner to have it all done in the correct places as it is in the current fscrypt in mainline.)

You should convince your customers to use a more modern kernel :)

thanks,

greg k-h

Re: Merging backported fscrypt to 4.4?

[Anton Altaparmakov]

Hi Greg,

Thanks a lot for the quick reply!

> On 12 Oct 2017, at 13:11, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Oct 12, 2017 at 11:59:03AM +0000, Anton Altaparmakov wrote:
>> Hi Greg,
>> 
>> As 4.4 is now going to be "the stable kernel" until 2022 and we have backported fscrypt to 4.4.  Currently we (that is Tuxera) have it as an out of tree proof of concept module and we could maintain it like that but given the kernel is going to be around for another 5 years perhaps it would be useful for everyone to have fscrypt in the stable 4.4 tree itself...  Then ext4/f2fs could support fscrypt based encryption in the 4.4 kernel which is of interest to many device manufacturers (which is why we have done the backport - it was driven by customers)...
>> 
>> What do you think?  Would you accept a backported fscrypt into the stable 4.4 tree?
> 
> The LTS rules are still the same, no matter if I maintain it for a few
> months, or a few years/decades.  So how does adding a bunch of new code
> for no in-kernel users fit into the existing rules?

ext4/f2fs are in-kernel users.

> If a device manufacture wants the fscrypt feature, great, use a newer
> kernel (like 4.9 or better yet, 4.14.)  It's always best to use newer
> kernels, right?.
> 
>> Note, the reason I am asking before sending patches is that we need to make some changes to our current backport if it is going into the kernel as we need to update the struct inode and struct super_block.  (We currently work around this in the out of tree fscrypt module but it would be much cleaner to have it all done in the correct places as it is in the current fscrypt in mainline.)
> 
> You should convince your customers to use a more modern kernel :)

In fact one of our customers were moving to a more recent kernel and cancelled the move when the announcement about the longer 4.4 kernel life time was made!!!

Now that 4.4 has a longer supported time than any newer kernel we will probably see a lot of devices get stuck on 4.4 kernel for the next decade at least...  This was one of those small announcements that are going to affect the entire embedded world for years to come!

Best regards,

	Anton

> thanks,
> 
> greg k-h

-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer

Re: Merging backported fscrypt to 4.4?

[Greg KH]

On Thu, Oct 12, 2017 at 12:30:09PM +0000, Anton Altaparmakov wrote:
> Hi Greg,
> 
> Thanks a lot for the quick reply!
> 
> > On 12 Oct 2017, at 13:11, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Oct 12, 2017 at 11:59:03AM +0000, Anton Altaparmakov wrote:
> >> Hi Greg,
> >> 
> >> As 4.4 is now going to be "the stable kernel" until 2022 and we have backported fscrypt to 4.4.  Currently we (that is Tuxera) have it as an out of tree proof of concept module and we could maintain it like that but given the kernel is going to be around for another 5 years perhaps it would be useful for everyone to have fscrypt in the stable 4.4 tree itself...  Then ext4/f2fs could support fscrypt based encryption in the 4.4 kernel which is of interest to many device manufacturers (which is why we have done the backport - it was driven by customers)...
> >> 
> >> What do you think?  Would you accept a backported fscrypt into the stable 4.4 tree?
> > 
> > The LTS rules are still the same, no matter if I maintain it for a few
> > months, or a few years/decades.  So how does adding a bunch of new code
> > for no in-kernel users fit into the existing rules?
> 
> ext4/f2fs are in-kernel users.

But it's just moving code around for those users, not fixing any bugs,
right?

> > If a device manufacture wants the fscrypt feature, great, use a newer
> > kernel (like 4.9 or better yet, 4.14.)  It's always best to use newer
> > kernels, right?.
> > 
> >> Note, the reason I am asking before sending patches is that we need to make some changes to our current backport if it is going into the kernel as we need to update the struct inode and struct super_block.  (We currently work around this in the out of tree fscrypt module but it would be much cleaner to have it all done in the correct places as it is in the current fscrypt in mainline.)
> > 
> > You should convince your customers to use a more modern kernel :)
> 
> In fact one of our customers were moving to a more recent kernel and
> cancelled the move when the announcement about the longer 4.4 kernel
> life time was made!!!

Um, that's not really very wise.  You should council them about that...

> Now that 4.4 has a longer supported time than any newer kernel we will
> probably see a lot of devices get stuck on 4.4 kernel for the next
> decade at least...  This was one of those small announcements that are
> going to affect the entire embedded world for years to come!

Those devices were stuck on 4.4 anyway, the SoC vendors were not
updating their kernel version, which is why I'm doing this longer term
support, to keep those devices secure.  Otherwise they would all be in
big trouble...

Note, I will say that if I do not see these devices get new kernel
updates, then I'll figure that the work I'm doing here doesn't even
matter to anyone, and then I'll just stop the support...

Anyway, that's a side note, I don't really understand why you need/want
fscrypt, if the only in-kernel filesystems that need it, already have
this support?

thanks,

greg k-h

Re: Merging backported fscrypt to 4.4?

[Anton Altaparmakov]

Hi Greg,

> On 12 Oct 2017, at 13:49, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Oct 12, 2017 at 12:30:09PM +0000, Anton Altaparmakov wrote:
>> Hi Greg,
>> 
>> Thanks a lot for the quick reply!
>> 
>>> On 12 Oct 2017, at 13:11, Greg KH <gregkh@linuxfoundation.org> wrote:
>>> On Thu, Oct 12, 2017 at 11:59:03AM +0000, Anton Altaparmakov wrote:
>>>> Hi Greg,
>>>> 
>>>> As 4.4 is now going to be "the stable kernel" until 2022 and we have backported fscrypt to 4.4.  Currently we (that is Tuxera) have it as an out of tree proof of concept module and we could maintain it like that but given the kernel is going to be around for another 5 years perhaps it would be useful for everyone to have fscrypt in the stable 4.4 tree itself...  Then ext4/f2fs could support fscrypt based encryption in the 4.4 kernel which is of interest to many device manufacturers (which is why we have done the backport - it was driven by customers)...
>>>> 
>>>> What do you think?  Would you accept a backported fscrypt into the stable 4.4 tree?
>>> 
>>> The LTS rules are still the same, no matter if I maintain it for a few
>>> months, or a few years/decades.  So how does adding a bunch of new code
>>> for no in-kernel users fit into the existing rules?
>> 
>> ext4/f2fs are in-kernel users.
> 
> But it's just moving code around for those users, not fixing any bugs,
> right?

Probably true, yes.  I admit I had forgotten they already had that code in 4.4 and it was moved out to fscrypt afterwards...

>>> If a device manufacture wants the fscrypt feature, great, use a newer
>>> kernel (like 4.9 or better yet, 4.14.)  It's always best to use newer
>>> kernels, right?.
>>> 
>>>> Note, the reason I am asking before sending patches is that we need to make some changes to our current backport if it is going into the kernel as we need to update the struct inode and struct super_block.  (We currently work around this in the out of tree fscrypt module but it would be much cleaner to have it all done in the correct places as it is in the current fscrypt in mainline.)
>>> 
>>> You should convince your customers to use a more modern kernel :)
>> 
>> In fact one of our customers were moving to a more recent kernel and
>> cancelled the move when the announcement about the longer 4.4 kernel
>> life time was made!!!
> 
> Um, that's not really very wise.  You should council them about that...
> 
>> Now that 4.4 has a longer supported time than any newer kernel we will
>> probably see a lot of devices get stuck on 4.4 kernel for the next
>> decade at least...  This was one of those small announcements that are
>> going to affect the entire embedded world for years to come!
> 
> Those devices were stuck on 4.4 anyway, the SoC vendors were not
> updating their kernel version, which is why I'm doing this longer term
> support, to keep those devices secure.  Otherwise they would all be in
> big trouble...
> 
> Note, I will say that if I do not see these devices get new kernel
> updates, then I'll figure that the work I'm doing here doesn't even
> matter to anyone, and then I'll just stop the support...

Ok, that is good to know.

> Anyway, that's a side note, I don't really understand why you need/want
> fscrypt, if the only in-kernel filesystems that need it, already have
> this support?

Ah, sorry for not explaining better - we have our own flash friendly file system (TFFS), which is not in the tree so we have a vested interest in fscrypto being part of the mainline kernel rather than maintaining it separately.

Best regards,

	Anton

> thanks,
> 
> greg k-h

-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer

Re: Merging backported fscrypt to 4.4?

[Greg KH]

On Thu, Oct 12, 2017 at 01:26:26PM +0000, Anton Altaparmakov wrote:
> > Anyway, that's a side note, I don't really understand why you need/want
> > fscrypt, if the only in-kernel filesystems that need it, already have
> > this support?
> 
> Ah, sorry for not explaining better - we have our own flash friendly
> file system (TFFS), which is not in the tree so we have a vested
> interest in fscrypto being part of the mainline kernel rather than
> maintaining it separately.

Ok, that makes more sense.  No, sorry, I'm not going to make changes to
any kernel for an out-of-tree chunk of code.  We wouldn't do that in
Linus's latest tree, so of course we wouldn't do it in a stable kernel
tree.

Get your filesystem merged and then we can talk :)

thanks,

greg k-h

Re: Merging backported fscrypt to 4.4?

[Anton Altaparmakov]

Hi Greg,

> On 12 Oct 2017, at 14:45, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Oct 12, 2017 at 01:26:26PM +0000, Anton Altaparmakov wrote:
>>> Anyway, that's a side note, I don't really understand why you need/want
>>> fscrypt, if the only in-kernel filesystems that need it, already have
>>> this support?
>> 
>> Ah, sorry for not explaining better - we have our own flash friendly
>> file system (TFFS), which is not in the tree so we have a vested
>> interest in fscrypto being part of the mainline kernel rather than
>> maintaining it separately.
> 
> Ok, that makes more sense.  No, sorry, I'm not going to make changes to
> any kernel for an out-of-tree chunk of code.  We wouldn't do that in
> Linus's latest tree, so of course we wouldn't do it in a stable kernel
> tree.
> 
> Get your filesystem merged and then we can talk :)

Yes, once you reminded me ext4 and f2fs already have the crypto code in 4.4 already just not pulled out into fscrypt I figured that was the answer!

But this little discussion was very useful anyway as we now will have it in the archives to point customers at the fact that they should be updating their kernels and only if they really can't move to a newer kernel should they stay with 4.4 but then make sure they upgrade within the 4.4 updates or the support will go away and won't stay till 2022.

I fear too many companies would have taken the "will be supported till 2022" as some "contractually guaranteed fact" which it of course is not and it is great to have that in writing in the archives.

Best regards,

	Anton

> thanks,
> 
> greg k-h

-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer

Re: Merging backported fscrypt to 4.4?

[Willy Tarreau]

On Thu, Oct 12, 2017 at 01:26:26PM +0000, Anton Altaparmakov wrote:
> >>> You should convince your customers to use a more modern kernel :)
> >> 
> >> In fact one of our customers were moving to a more recent kernel and
> >> cancelled the move when the announcement about the longer 4.4 kernel
> >> life time was made!!!
> > 
> > Um, that's not really very wise.  You should council them about that...

In fact given that 4.9 will be maintained for a long time as well, there
is no really valid excuse for rolling back to 4.4.

Willy

Re: Merging backported fscrypt to 4.4?

[Anton Altaparmakov]

Hi Willy,

> On 12 Oct 2017, at 18:26, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Oct 12, 2017 at 01:26:26PM +0000, Anton Altaparmakov wrote:
>>>>> You should convince your customers to use a more modern kernel :)
>>>> 
>>>> In fact one of our customers were moving to a more recent kernel and
>>>> cancelled the move when the announcement about the longer 4.4 kernel
>>>> life time was made!!!
>>> 
>>> Um, that's not really very wise.  You should council them about that...
> 
> In fact given that 4.9 will be maintained for a long time as well, there
> is no really valid excuse for rolling back to 4.4.

Interesting.  https://www.kernel.org/category/releases.html still states 4.4 has projected EOL 2022 whilst 4.9 is 2019 so I can see why companies are looking and it and jumping onto 4.4...

Best regards,

	Anton

> Willy

-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer

Re: Merging backported fscrypt to 4.4?

[Willy Tarreau]

Hi Anton,

On Fri, Oct 13, 2017 at 08:57:28AM +0000, Anton Altaparmakov wrote:
> Hi Willy,
> 
> > On 12 Oct 2017, at 18:26, Willy Tarreau <w@1wt.eu> wrote:
> > On Thu, Oct 12, 2017 at 01:26:26PM +0000, Anton Altaparmakov wrote:
> >>>>> You should convince your customers to use a more modern kernel :)
> >>>> 
> >>>> In fact one of our customers were moving to a more recent kernel and
> >>>> cancelled the move when the announcement about the longer 4.4 kernel
> >>>> life time was made!!!
> >>> 
> >>> Um, that's not really very wise.  You should council them about that...
> > 
> > In fact given that 4.9 will be maintained for a long time as well, there
> > is no really valid excuse for rolling back to 4.4.
> 
> Interesting.  https://www.kernel.org/category/releases.html still states 4.4
> has projected EOL 2022 whilst 4.9 is 2019 so I can see why companies are
> looking and it and jumping onto 4.4...

Well, debian 9 settled on 4.9 and will be maintained till 2022 as well :

     https://wiki.debian.org/LTS

Based on the good work done on the previous kernels, we can expect to
have a very good kernel till that date as well. Sadly there's less
communication about this but you can probably use this to reassure your
customers that it's stupid to roll back to 4.4 to reach the same EOL as
4.9 with less features and/or riskier backports.

Just my two cents. At least our appliances are now shipping on 4.9 ;-)

Willy