linux-kernel - Re: [QUESTION] arch_counter_register() restricts CNTPT access when booted in EL1, even if EL2 is supported

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: <aCqM1Z2ApdvGYfb9@perf>
Date: Mon, 19 May 2025 10:43:49 +0900
From: Youngmin Nam <youngmin.nam@...sung.com>
To: Marc Zyngier <maz@...nel.org>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>, Thomas Gleixner
	<tglx@...utronix.de>, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, junhosj.choi@...sung.com,
	hajun.sung@...sung.com, joonki.min@...sung.com, d7271.choe@...sung.com,
	jkkkkk.choi@...sung.com, jt1217.kim@...sung.com, qperret@...gle.com,
	willdeacon@...gle.com, dhyun.cha@...sung.com, kn_hong.choi@...sung.com,
	mankyum.kim@...sung.com, Youngmin Nam <youngmin.nam@...sung.com>
Subject: Re: [QUESTION] arch_counter_register() restricts CNTPT access when
 booted in EL1, even if EL2 is supported

On Fri, May 16, 2025 at 10:28:56AM +0100, Marc Zyngier wrote:
> On Fri, 16 May 2025 07:53:58 +0100,
> Youngmin Nam <youngmin.nam@...sung.com> wrote:
> > 
> > [1  <text/plain; utf-8 (8bit)>]
> > Hi arm arch timer experts,
> > 
> > While reviewing the arm_arch_timer code in Linux 6.12,
> > I noticed that the function arch_counter_register() restricts the
> > use of the physical counter (cntpct_el0) on systems where the kernel
> > is running in EL1, even if EL2 is supported and cntpct_el0 is
> > accessible.
> > 
> > In our case:
> > - We are not using pKVM.
> > - The kernel is booted in EL1.
> > - We disabled VIRT_PPI and explicitly selected PHYS_NONSECURE_PPI for the timer refering to below code.
> 
> That's not legal. The architecture guarantees that there is a virtual
> timer and a physical timer. No ifs, no buts.
> 
> [...]
> 
> > As I understand it, `is_hyp_mode_available()` checks whether the
> > kernel booted into EL2 — not whether EL2 is *supported* by the
> > hardware.
> > 
> > Therefore, even on systems where EL2 exists and `cntpct_el0` is
> > accessible from EL1, the kernel still forces the use of `cntvct_el0`
> > if the boot EL is EL1.
> 
> Yes, because it isn't architecturally valid to not have a virtual
> timer. This isn't about EL2 being present of not. The switch to the
> physical timer is purely an optimisation for KVM so that it doesn't
> have to switch the virtual timer back and forth when running a guest,
> as the virtual timer is the most likely used timer.
> 

Thanks for the clarification.

As a follow-up question:

We are working on a system that uses a vendor-specific hypervisor instead of KVM.
In this setup, we also want to optimize timer virtualization overhead and are considering using
the physical timer (CNTPT) in the host context for performance reasons, just like KVM does.

Would it be acceptable (from the upstream kernel's perspective) to make a similar switch
to the physical timer in this case ?

Or is this kind of optimization strictly tied to KVM's internal behavior
and not something the kernel is expected to support generically?

Any guidance or recommendation would be appreciated.

Best regards,
Youngmin

> > Is this restriction to `cntvct_el0` in EL1 an architectural
> > requirement, or simply a conservative default to avoid possible
> > traps on some systems?
> 
> Both. Crucially, it isn't possible to trap the virtual timer on some
> older implementations.
> 
> > If the hardware clearly supports EL2 and allows CNTPT access from
> > EL1, could this restriction be relaxed?
> 
> Absolutely not. Having the virtual timer is a hard requirement from
> both the architecture *and* Linux. Feel free to emulate it from EL2 if
> you want (and can trap it).
> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.
>