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 for Android: free password hash cracker in your pocket

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

Message-ID: <5b6953ac-6bf6-6663-a566-40f0ae9f9572@kernel.org>
Date:   Tue, 27 Jun 2023 00:08:30 -0500
From:   Dinh Nguyen <dinguyen@...nel.org>
To:     "Lee, Kah Jing" <kah.jing.lee@...el.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.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



On 6/26/23 22:40, Lee, Kah Jing wrote:
>> -----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.
>>

You can still have the defconfig build them as modules. Then you can 
include them in your initramfs.

Dinh