Re: [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems

[Henning Schild <henning.schild@siemens.com>]

Am Thu, 11 Feb 2021 18:57:24 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 11.02.21 15:13, Henning Schild wrote:
> > Am Thu, 11 Feb 2021 14:31:58 +0100
> > schrieb "Bezdeka, Florian (T RDA IOT SES-DE)"
> > <florian.bezdeka@siemens.com>:
> >   
> >> On Thu, 2021-02-11 at 12:47 +0000, [ext]
> >> florian.bezdeka@siemens.com wrote:  
> >>> On Thu, 2021-02-11 at 11:21 +0100, Henning Schild wrote:    
> >>>> Am Thu, 11 Feb 2021 10:57:31 +0100
> >>>> schrieb "Bezdeka, Florian (T RDA IOT SES-DE)"
> >>>> <florian.bezdeka@siemens.com>:
> >>>>    
> >>>>> On Thu, 2021-02-11 at 10:09 +0100, Jan Kiszka wrote:    
> >>>>>> On 11.02.21 09:23, Henning Schild wrote:    
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> i never got around to reviewing this. But did we just fork
> >>>>>>> wic? These patches need to go into wic and we later
> >>>>>>> backport them once they are accepted upstream.
> >>>>>>>
> >>>>>>> Maybe they are already ... did not check.
> >>>>>>>
> >>>>>>> When it comes to changing bitbake or wic, we should really
> >>>>>>> not ... We have forks of some files, like the wic plugins
> >>>>>>> and bitbake config, those are fine but should also stay
> >>>>>>> very close to upstream.
> >>>>>>>
> >>>>>>> The recently applied patch from Vijai also violates that.
> >>>>>>> Since the fork of the plugins was not updated with the wic
> >>>>>>> bump and the repair just takes a few bits of what we
> >>>>>>> probably should take.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>    
> >>>>>>
> >>>>>> If you are referring to
> >>>>>> https://groups.google.com/d/msgid/isar-users/20201126091750.28048-1-Vijaikumar_Kanagarajan%40mentor.com
> >>>>>> That one was "only" patching an isar version, though I agree
> >>>>>> that we should make sure to realign it with the original
> >>>>>> plugins if we are now imbalanced.
> >>>>>>
> >>>>>> This one here is more critical as it changed a formerly
> >>>>>> vanilla wic file. That should be fixed quickly.
> >>>>>>
> >>>>>> Florian, maybe you can propose a similar change to OE
> >>>>>> upstream? In the meantime, is there a chance to move the
> >>>>>> changes out of partition.py, to a file that is isar-specific?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>    
> >>>>>
> >>>>> I guess the "RFC" tag of this series has been overlooked. It
> >>>>> was not intended for merging (yet). Part one (forwarding wic
> >>>>> warnings to bitbake) is a pure ISAR change and could be taken
> >>>>> as is (if no further comments come up).    
> >>>>
> >>>> I guess that calls for a revert. And for more attention on the
> >>>> maintainers side.

Florian, maybe you send a revert series. Not your fault but maybe your
call.

Henning

> >>>>> Sorry for the long description of the series, but if you read
> >>>>> closely I already mentioned that the second part should go to
> >>>>> OE. I sent it out for feedback collection only.
> >>>>>
> >>>>> The upstreaming to OE will take some time due to internal
> >>>>> clarifications. I never contributed to OE before, so some kind
> >>>>> of approval process has to be followed first.
> >>>>>
> >>>>> At first glance there was no easy way moving the warnings from
> >>>>> wic to ISAR. We would have to re-parse the wic template file
> >>>>> again and check all the partitions afterwards. wic has all the
> >>>>> necessary information at hand so I guess that's way easier.    
> >>>>
> >>>> I guess it can be moved into a task after wic. Here one would
> >>>> need to parse the partition table, which kind of sucks. "losetup"
> >>>> or "kpartx" might help but will not work in kas-container setups
> >>>> because they need root.
> >>>> We once had patches allowing wic to retain all partition images
> >>>> instead of throwing them away after disk assembly. Having a
> >>>> switch for wic to say ... do those partitions ... later do the
> >>>> disk would be generic, allow hooking in this and other things.
> >>>>
> >>>> Isar also has a class that creates ext4 images without, after
> >>>> which such a check should also be done.    
> >>>
> >>> Yes. But instead of spreading the warnings around it would be nice
> >>> to have a single place where we could do the Y2038 checks. So
> >>> maybe it should be a base feature of "image.bbclass"? Or
> >>> ext4-img.bbclass should call wic instead of the mke2fs utilities
> >>> directly?
> >>>
> >>> BTW: The name ext4-img.bbclass is kind of misleading. You could
> >>> simply create ext{2,3} file systems by setting MKE2FS_ARGS to
> >>> something like "-t ext2".
> >>>    
> >>>>
> >>>> Is ext4 the only fs we care about? We have some layers doing
> >>>> ubifs, squashfs and all sorts of funny things.    
> >>>
> >>> Up to now I cared about the filesystems supported by wic. So
> >>> ext{2,3,4}, btrfs and squashfs. squashfs will overflow in 2106
> >>> (u32) and btrfs will "never" overflow (u64).
> >>>
> >>> ubifs is similar to btrfs, so not affected by Y2038.
> >>>    
> >>>>
> >>>> Maybe the kernel does warn "on device" so we could have a systemd
> >>>> unit warning for all filesystems ... which would probably best
> >>>> find its place in the kernel and or debian.    
> >>>
> >>> At least for affected ext file systems the kernel will warn (on
> >>> mount). But I considered that as "too late".    
> >>
> >> To be more specific: Linux >= 5.4 warns. That's why I guess that
> >> many projects did not realize that they are already affected by
> >> the Y2038 problem because of older kernel versions.  
> > 
> > Which sounds like that warning needs backporting into the debian10
> > kernel and maybe cip. Not sure Isar is the best place, but a valid
> > one that could help.
> > 
> > Maybe mkfs could warn ... as well.
> >   
> 
> Right, and we want such warnings seen at image *build time*, not only
> on the target during runtime. That is the key idea behind this
> instrumentation.
> 
> Jan
>