linux-kernel - Re: [PATCH v3 1/7] arm64: add support for the AMU extension v1

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: <ade32e03-b56b-7c5d-628d-124e52279d34@arm.com>
Date:   Wed, 12 Feb 2020 16:24:42 +0000
From:   Vladimir Murzin <vladimir.murzin@....com>
To:     Ionela Voinescu <ionela.voinescu@....com>,
        Suzuki Kuruppassery Poulose <suzuki.poulose@....com>
Cc:     mark.rutland@....com, maz@...nel.org, linux-doc@...r.kernel.org,
        peterz@...radead.org, catalin.marinas@....com,
        linux-pm@...r.kernel.org, rjw@...ysocki.net,
        linux-kernel@...r.kernel.org, mingo@...hat.com,
        viresh.kumar@...aro.org, linux-arm-kernel@...ts.infradead.org,
        sudeep.holla@....com, will@...nel.org, valentin.schneider@....com,
        lukasz.luba@....com
Subject: Re: [PATCH v3 1/7] arm64: add support for the AMU extension v1

Hi,

On 2/12/20 4:10 PM, Ionela Voinescu wrote:
> Hi Suzuki,
> 
> On Wednesday 12 Feb 2020 at 11:30:44 (+0000), Suzuki Kuruppassery Poulose wrote:
>>> +static int __init set_disable_amu(char *str)
>>> +{
>>> +	int value = 0;
>>> +
>>> +	disable_amu = get_option(&str, &value) ? !!value : true;
>> minor nit: You could simply use strtobool(str) here, which accepts:
>>
>> disable_amu= [0/1/on/off/y/n]
>>
> Yes, this was intentional as I wanted "disable_amu" to be a valid option
> as well, not only "disable_amu=<option>".
> 
> If you don't mind I'd like to keep it like this. Currently the use of
> AMU is enabled by default, and the most common kernel parameter to
> disable it would be "disable_amu". Allowing "disable_amu=0" is just in
> case we change the default in the kernel to not support AMU and we'd
> like platforms to be able to enable it. 
> 

Sorry for jumping into thread, but can we avoid negatives into naming which
accept values? If is always tricky to get expected effect when both are combined.

If value doesn't really mater than can it be just "noamu"?

If value does matter can it be (per Suzuki) amu=[0/1/on/off/y/n]?

Or can you postpone introduction of "just in case" option till that case happens?

Cheers
Vladimir