linux-kernel - RE: [PATCH 2/2] arch: arm64: configs: Enable UBI and UBIFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PH0PR11MB5673A2BA9D39B9CD4C775DA5CB27A@PH0PR11MB5673.namprd11.prod.outlook.com>
Date:   Tue, 27 Jun 2023 03:40:06 +0000
From:   "Lee, Kah Jing" <kah.jing.lee@...el.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] arch: arm64: configs: Enable UBI and UBIFS

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> Sent: Monday, 26 June, 2023 4:39 PM
> To: Lee, Kah Jing <kah.jing.lee@...el.com>; Dinh Nguyen
> <dinguyen@...nel.org>; Rob Herring <robh+dt@...nel.org>; Krzysztof
> Kozlowski <krzysztof.kozlowski+dt@...aro.org>; Conor Dooley
> <conor+dt@...nel.org>; Catalin Marinas <catalin.marinas@....com>; Will
> Deacon <will@...nel.org>
> Cc: linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 2/2] arch: arm64: configs: Enable UBI and UBIFS
> 
> On 26/06/2023 06:16, Lee, Kah Jing wrote:
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> >> Sent: Saturday, 24 June, 2023 3:30 PM
> >> To: Lee, Kah Jing <kah.jing.lee@...el.com>; Dinh Nguyen
> >> <dinguyen@...nel.org>; Rob Herring <robh+dt@...nel.org>; Krzysztof
> >> Kozlowski <krzysztof.kozlowski+dt@...aro.org>; Conor Dooley
> >> <conor+dt@...nel.org>; Catalin Marinas <catalin.marinas@....com>;
> >> Will Deacon <will@...nel.org>
> >> Cc: linux-kernel@...r.kernel.org
> >> Subject: Re: [PATCH 2/2] arch: arm64: configs: Enable UBI and UBIFS
> >>
> >> On 24/06/2023 05:42, Lee, Kah Jing wrote:
> >>>>>> So you miss init ramdisk.
> >>>>> Currently we are using the bootargs to mount the rootfs from QSPI
> >>>>> NOR
> >>>> flash:
> >>>>> [    0.000000] Kernel command line: earlycon panic=-1 ubi.mtd=1
> >>>> root=ubi0:rootfs rootfstype=ubifs rw rootwait
> >>>>> Is it possible to mount the ubifs rootfs with the ubifs=m config
> >>>>> during
> >> boot?
> >>>>
> >>>> I think yes. rootfs devices are for example modules, so filesystem
> >>>> can be as well.
> >>> Was going through mtd ubifs page -
> >>> http://www.linux-mtd.infradead.org/faq/ubifs.html
> >>> Quoted: 'In order to mount UBIFS as the root file system, you have
> >>> to compile UBIFS into the kernel (instead of compiling it as a
> >>> kernel
> >>> module) and specify proper kernel boot arguments and make the kernel
> >> mount UBIFS on boot.'
> >>
> >> Why? Module loaded by initramfs would also understand cmdline
> >> arguments, right?
> > The suggestion is to use initramfs for rootfs -> remount UBIFS as chroot?
> > The concern is additional initrd image and steps to store in the
> > limited NOR flash (256MB, Boot data + Uboot - ~66MB, UBIFS image -
> > ~88MB, kernel.itb - ~10MB = 164MB).
> > With the mounting Rootfs from UBIFS volume, we can skip the initrd
> > step, and save some space for the user operations.
> > Let me know if I understands that correctly.
> 
> arm64 defconfig creates huge development config for all platforms, so why
> would you ever use it in resource-constrained system? It would barely fit.
> defconfig modules take 50 MB alone and you don't need most of them.
> 
> I think you misunderstood the purpose of this defconfig and now try to apply
> some arguments for different use cases.
Understood the point. In this case, I would drop this defconfig patch, and
document it for customers to enable through menuconfig. 

Will proceed to send the v3 for only dts changes. 
Thanks for the time.
> 
> Best regards,
> Krzysztof

Regards, 
Lee, Kah Jing