linux-kernel - Re: [PATCH v2 6/6] arm64: use activity monitors for frequency invariance

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: <20200130154923.GB5208@arm.com>
Date:   Thu, 30 Jan 2020 15:49:23 +0000
From:   Ionela Voinescu <ionela.voinescu@....com>
To:     Valentin Schneider <valentin.schneider@....com>
Cc:     catalin.marinas@....com, will@...nel.org, mark.rutland@....com,
        maz@...nel.org, suzuki.poulose@....com, sudeep.holla@....com,
        dietmar.eggemann@....com, peterz@...radead.org, mingo@...hat.com,
        ggherdovich@...e.cz, vincent.guittot@...aro.org,
        linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/6] arm64: use activity monitors for frequency
 invariance

Hi Valentin,

On Wednesday 29 Jan 2020 at 23:39:11 (+0000), Valentin Schneider wrote:
> On 29/01/2020 17:13, Valentin Schneider wrote:
> > I had a brief look at the Arm ARM, for the arch timer it says it is
> > "typically in the range 1-50MHz", but then also gives an example with 20KHz
> > in a low-power mode.
> > 
> > If we take say 5GHz max CPU frequency, our lower bound for the arch timer
> > (with that SCHED_CAPACITY_SCALE² trick) is about ~4.768KHz. It's not *too*
> > far from that 20KHz, but I'm not sure we would actually be executing stuff
> > in that low-power mode.
> > 
> 
> I mixed up a few things in there; that low-power mode is supposed to do
> higher increments, so it would emulate a similar frequency as the non-low-power
> mode. Thus the actual frequency matters less than what is reported in CNTFRQ
> (though we hope to get the behaviour we're told we should see), so we should
> be quite safe from that ~5KHz value. Still, to make it obvious, I don't think
> something like this would hurt:
> 
> ---
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 9a5464c625b45..a72832093575a 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -885,6 +885,17 @@ static int arch_timer_starting_cpu(unsigned int cpu)
>  	return 0;
>  }
>  
> +static int validate_timer_rate(void)
> +{
> +	if (!arch_timer_rate)
> +		return 1;
> +
> +	/* Arch timer frequency < 1MHz is shady */
> +	WARN_ON(arch_timer_rate < 1000000);
> +
> +	return 0;
> +}
> +
>  /*
>   * For historical reasons, when probing with DT we use whichever (non-zero)
>   * rate was probed first, and don't verify that others match. If the first node
> @@ -900,7 +911,7 @@ static void arch_timer_of_configure_rate(u32 rate, struct device_node *np)
>  		arch_timer_rate = rate;
>  
>  	/* Check the timer frequency. */
> -	if (arch_timer_rate == 0)
> +	if (validate_timer_rate())
>  		pr_warn("frequency not available\n");
>  }
>  
> @@ -1594,7 +1605,7 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table)
>  	 * CNTFRQ value. This *must* be correct.
>  	 */
>  	arch_timer_rate = arch_timer_get_cntfrq();
> -	if (!arch_timer_rate) {
> +	if (validate_timer_rate()) {
>  		pr_err(FW_BUG "frequency not available.\n");
>  		return -EINVAL;
>  	}
> ---
> 

Okay, I'll add this as a separate patch to the series and put you as
author. That is if you want me to tie this check to this usecase that
proves its usefulness. Otherwise it can stand on its own as well if
you want to submit it separately.

In regards to the ratio computation for frequency invariance where this
plays a role, I'll do a check and bail out if the ratio is 0, which I'm
ashamed to not have added before :).

Thanks,
Ionela.


> > Long story short, we're probably fine, but it would nice to shove some of
> > the above into comments (especially the SCHED_CAPACITY_SCALE² trick)
> >