linux-kernel - Re: [PATCH] arm64: Support 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: <8b4fb239-ba11-616f-9d0a-5cc009d047a4@alliedtelesis.co.nz>
Date:   Tue, 21 Mar 2023 04:15:00 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Anshuman Khandual <anshuman.khandual@....com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: Support CMDLINE_EXTEND

Hi,

On 21/03/23 16:54, Anshuman Khandual wrote:
> Hello Chris,
>
> On 3/21/23 02:44, Chris Packham wrote:
>> Support extending the bootloader provided command line for arm64
>> targets. This support is already present via generic DT/EFI code the
>> only thing required is for the architecture to make it selectable.
> Does this config really depend on given platform's active support or
> it is just matter of selecting this for interested platforms ?
Most modern platforms using DT or UEFI should be able to use the common 
code. There are some older ones (arm and powerpc) that have other/legacy 
methods of passing the kernel command line so retaining support for that 
while at the same time providing support for the generic methods as well 
could get tricky. It looks as though it won't be too bad as the code 
seems to use the same Kconfig options.
> Could
> this config definition be unified in a single place i.e arch/Kconfig
> and be selected (unconditionally or conditionally) on all subscribing
> platforms. There seems to be a redundancy in defining the exact same
> config the same way, on multiple platforms.
>
> $git grep "config CMDLINE_EXTEND"
>
> arch/arm/Kconfig:config CMDLINE_EXTEND
> arch/loongarch/Kconfig:config CMDLINE_EXTEND
> arch/powerpc/Kconfig:config CMDLINE_EXTEND
> arch/riscv/Kconfig:config CMDLINE_EXTEND
> arch/sh/Kconfig:config CMDLINE_EXTEND

Same applies to CMDLINE_FROM_BOOTLOADER/CMDLINE_FORCE. Although sh uses 
CMDLINE_OVERWRITE instead of CMDLINE_FORCE. I guess it'd be possible to 
move it to some common place and have the arches source it like they do 
for things like power management.

> I guess this redundancy should be removed as a pre-requisite, before
> enabling it on arm64 as proposed here, which in itself seems alright.
I was kind of hoping it wouldn't be a pre-requisite mainly because it 
turns a quick patch I can actually test on hardware I have in front of 
me to something that I can't test on half the platforms that are 
affected. I also haven't had to co-ordinate a change across 6 maintainer 
trees before. But I guess I can give it a try if that's the only way of 
getting it in.
>
>> Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
>> ---
>>   arch/arm64/Kconfig | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 1023e896d46b..3c837b085f21 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -2228,6 +2228,12 @@ config CMDLINE_FROM_BOOTLOADER
>>   	  the boot loader doesn't provide any, the default kernel command
>>   	  string provided in CMDLINE will be used.
>>   
>> +config CMDLINE_EXTEND
>> +	bool "Extend bootloader kernel arguments"
>> +	help
>> +	  The command-line arguments provided by the boot loader will be
>> +	  appended to the default kernel command string.
>> +
>>   config CMDLINE_FORCE
>>   	bool "Always use the default kernel command string"
>>   	help