linux-kernel - Re: [PATCH V2] ARM: mach-shmobile: Don't init CNTVOFF if PSCI is available

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: <CAMuHMdVYff-YsGxJykT_p31iyw9f4yVY967_i166TSm__WRG9g@mail.gmail.com>
Date:   Fri, 3 May 2019 13:38:42 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Oleksandr Tyshchenko <olekstysh@...il.com>
Cc:     Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Julien Grall <julien.grall@....com>,
        Simon Horman <horms@...ge.net.au>,
        Magnus Damm <magnus.damm@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Biju Das <biju.das@...renesas.com>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
Subject: Re: [PATCH V2] ARM: mach-shmobile: Don't init CNTVOFF if PSCI is available

Hi Oleksandr,

On Fri, May 3, 2019 at 1:21 PM Oleksandr Tyshchenko <olekstysh@...il.com> wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
>
> If PSCI is available then most likely we are running on PSCI-enabled
> U-Boot which, we assume, has already taken care of resetting CNTVOFF
> before switching to non-secure mode and we don't need to.
>
> Also, don't init CNTVOFF if we are running on top of Xen hypervisor,
> as CNTVOFF is controlled by hypervisor itself and shouldn't be touched
> by Dom0 in such case.
>
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
> CC: Julien Grall <julien.grall@....com>

Thanks for your patch!

> ---
>    You can find previous discussion here:
>    https://lkml.org/lkml/2019/4/17/810
>
>    Changes in v2:
>       - Clarify patch subject/description
>       - Don't use CONFIG_ARM_PSCI option, check whether the PSCI is available,
>         by using psci_smp_available()
>       - Check whether we are running on top of Xen, by using xen_domain()
> ---
>  arch/arm/mach-shmobile/setup-rcar-gen2.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> index eea60b2..bc8537b 100644
> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> @@ -17,7 +17,9 @@
>  #include <linux/of.h>
>  #include <linux/of_fdt.h>
>  #include <linux/of_platform.h>
> +#include <xen/xen.h>
>  #include <asm/mach/arch.h>
> +#include <asm/psci.h>
>  #include <asm/secure_cntvoff.h>
>  #include "common.h"
>  #include "rcar-gen2.h"
> @@ -63,7 +65,16 @@ void __init rcar_gen2_timer_init(void)
>         void __iomem *base;
>         u32 freq;
>
> -       secure_cntvoff_init();
> +       /*
> +        * If PSCI is available then most likely we are running on PSCI-enabled
> +        * U-Boot which, we assume, has already taken care of resetting CNTVOFF
> +        * before switching to non-secure mode and we don't need to.
> +        * Another check is to be sure that we are not running on top of Xen
> +        * hypervisor, as CNTVOFF is controlled by hypervisor itself and
> +        * shouldn't be touched by Dom0 in such case.
> +        */
> +       if (!psci_smp_available() && !xen_domain())
> +               secure_cntvoff_init();
>
>         if (of_machine_is_compatible("renesas,r8a7745") ||
>             of_machine_is_compatible("renesas,r8a77470") ||

How do you prevent secure_cntvoff_init() from being called for secondary
CPUs in arch/arm/mach-shmobile/headsmp-apmu.S?

With PSCI, it is not called if "enable-method" in DT is "psci"', so that case
is covered, I guess.

What about XEN? Do you override the "enable-method"?
If yes, perhaps a check for "renesas,apmu" is more appropriate?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds