linux-kernel - Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline

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: <20fd7d44-8c39-48bc-25c3-990be9d9d911@csgroup.eu>
Date:   Thu, 25 Mar 2021 13:03:55 +0100
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Rob Herring <robh@...nel.org>
Cc:     Daniel Walker <danielwa@...co.com>, Will Deacon <will@...nel.org>,
        Daniel Gimpelevich <daniel@...pelevich.san-francisco.ca.us>,
        Andrew Morton <akpm@...ux-foundation.org>,
        X86 ML <x86@...nel.org>,
        "open list:MIPS" <linux-mips@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        xe-linux-external@...co.com, Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline



Le 24/03/2021 à 18:32, Rob Herring a écrit :
> On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy
> <christophe.leroy@...roup.eu> wrote:
>>
>>
>>
>> Le 09/03/2021 à 22:29, Daniel Walker a écrit :
>>> On Tue, Mar 09, 2021 at 08:47:09AM +0100, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 09/03/2021 à 01:02, Daniel Walker a écrit :
>>>>> This is a scripted mass convert of the config files to use
>>>>> the new generic cmdline. There is a bit of a trim effect here.
>>>>> It would seems that some of the config haven't been trimmed in
>>>>> a while.
>>>>
>>>> If you do that in a separate patch, you loose bisectability.
>>>>
>>>> I think it would have been better to do things in a different way, more or less like I did in my series:
>>>> 1/ Provide GENERIC cmdline at the same functionnality level as what is
>>>> spread in the different architectures
>>>> 2/ Convert architectures to the generic with least churn.
>>>> 3/ Add new features to the generic
>>>
>>> You have to have the churn eventually, no matter how you do it. The only way you
>>> don't have churn is if you never upgrade the feature set.
>>>
>>>
>>>>>
>>>>> The bash script used to convert is as follows,
>>>>>
>>>>> if [[ -z "$1" || -z "$2" ]]; then
>>>>>            echo "Two arguments are needed."
>>>>>            exit 1
>>>>> fi
>>>>> mkdir $1
>>>>> cp $2 $1/.config
>>>>> sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' $1/.config
>>>>
>>>> This is not correct.
>>>>
>>>> By default, on powerpc the provided command line is used only if the bootloader doesn't provide one.
>>>>
>>>> Otherwise:
>>>> - the builtin command line is appended to the one provided by the bootloader
>>>> if CONFIG_CMDLINE_EXTEND is selected
>>>> - the builtin command line replaces to the one provided by the bootloader if
>>>> CONFIG_CMDLINE_FORCE is selected
>>>
>>> I think my changes maintain most of this due to the override of
>>> CONFIG_CMDLINE_PREPEND. This is an upgrade and the inflexibility in powerpc is
>>> an example of why these changes were created in the first place.
>>
>> "inflexibility in powerpc" : Can you elaborate ?
>>
>>>
>>> For example , say the default command line is "root=/dev/issblk0" from iss476
>>> platform. And the bootloader adds "root=/dev/sda1"
>>>
>>> The result is <prepend><bootloader><append>.
>>
>>
>> I'm still having hard time understanding the benefit of having both <prepend> and <append>.
>> Could you please provide a complete exemple from real life, ie what exactly the problem is and what
>> it solves ?
> 
> It doesn't matter. We already have both cases and 'extend' has meant either one.
> 
> What someone wants is policy and the kernel shouldn't be defining the policy.
> 

Ok, so you agree we don't need to provide two CMDLINE, one to be appended and one to be prepended.

Let's only provide once CMDLINE as of today, and ask the user to select whether he wants it appended 
or prepended or replacee. Then no need to change all existing config to rename CONFIG_CMDLINE into 
either of the new ones.

That's the main difference between my series and Daniel's series. So I'll finish taking Will's 
comment into account and we'll send out a v3 soon.

Thanks
Christophe