From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6924371667242188800 X-Received: by 2002:a05:651c:14d:: with SMTP id c13mr5325958ljd.164.1613066247794; Thu, 11 Feb 2021 09:57:27 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:8952:: with SMTP id b18ls1250713ljk.3.gmail; Thu, 11 Feb 2021 09:57:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJx7xZ89UCniFRSWn6FUOaIRHRCgsQfeHgG3Nr2oX2hJiij60np4A3bUDsinvwoKe9jyyrPm X-Received: by 2002:a05:651c:291:: with SMTP id b17mr3263519ljo.274.1613066246483; Thu, 11 Feb 2021 09:57:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613066246; cv=none; d=google.com; s=arc-20160816; b=Rv2MXpz9DX5z5gZQvJXp5Bedv6dWxlJ/HqDSMqhN60ZWa9t9YKKJ9Z1FqLrmxZq8al NWX/rPNsTLJj+KInaXrqRwbVyCd5Wf4RX2DwGm5Q405wVLd/JpbTIRhSShNVXXlKvtJ3 tAXYd+S+E7U8yLLEYR12ujNuauLSH32u+qIiQeCmLa3WXOPbcwdo4/X4MKs7mCf0EtLG fdHG5mdcmSg4B/imqPdN8izvAI4ipNAIW+bexCv76AApVQ8erHx1Xdptj8Wd7icpRw59 8c7cuRmBFIccon/uVFZoHRKldp+YoAOgL0YUcc3TtVNoPb98htHBXRytcN6iCgoI0TMu Uq+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=gln70O1fJ0XLlV4XjdemWieMZJBFK+cguGeNI2BWh74=; b=Gjy9DHRSmDF9A66wOpamylBY2dgsq5QU3Iv4+H2MpdhfcXAAMWT02I1l+P8VCisFl0 9tR/UYke665Znm9e7JJilLFsgcpWYWWvGxRzsbxhenatDUZh05Gkq6z1/0b8fzVEGStz qbn1g6OviZvwb8SxXDopBJPZUaJ1LrsKEA8Z/ZTlZloN5eyeGsv2tYMXSQtwR1lqYr2v vBsj6jxOw64JbVL4vyDL+cdW6TOc+uoS7xHL5rP+TwyIScFN1uHJrCh055ZUaN8E01oQ DX6zq7ZBPAJZ9kZegWXX+2M8G4VHRp5WseejZLjbKCaP8+dZSprJeUibl9bEr+4+QUXx vZAg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id y3si164650lfb.6.2021.02.11.09.57.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 09:57:26 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 11BHvPpd021315 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Feb 2021 18:57:25 +0100 Received: from [139.22.42.110] ([139.22.42.110]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 11BHvOPx015092; Thu, 11 Feb 2021 18:57:24 +0100 Subject: Re: [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems To: Henning Schild , "Bezdeka, Florian (T RDA IOT SES-DE)" Cc: "amikan@ilbers.de" , "isar-users@googlegroups.com" , "vijaikumar.kanagarajan@gmail.com" , "Gylstorff, Quirin (T RDA IOT SES-DE)" References: <20210201185815.382326-1-florian.bezdeka@siemens.com> <491c833c-c35c-d130-e8e6-f31aee4204aa@ilbers.de> <20210211092338.293c5306@md1za8fc.ad001.siemens.net> <9b7b9865-2381-d2df-8495-4a208b82304f@siemens.com> <8f7c5554a0e8f4ef52526f84a90c418fd8d9c1d3.camel@siemens.com> <20210211112147.7d683a25@md1za8fc.ad001.siemens.net> <20210211151318.2eb38893@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <5f187abe-0b77-5ba9-e5a5-3da5ce072b7e@siemens.com> Date: Thu, 11 Feb 2021 18:57:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210211151318.2eb38893@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: zYouseisDzaZ 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)" > : > >> 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)" >>>> : >>>> >>>>> 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. >>>> >>>>> 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 -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux