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] [day] [month] [year] [list]

Message-ID: <aCrjj1A8udt1UJLc@perf>
Date: Mon, 19 May 2025 16:53:51 +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 Mon, May 19, 2025 at 08:12:24AM +0100, Marc Zyngier wrote:
> On Mon, 19 May 2025 02:43:49 +0100,
> Youngmin Nam <youngmin.nam@...sung.com> wrote:
> > 
> > [1  <text/plain; utf-8 (8bit)>]
> > 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 ?
> 
> No. Your hypervisor already has *two* private timers it can freely
> make use of (virtual and physical EL2 timers), and doesn't need to
> encroach on something that a guest (be it Linux or any other guest)
> relies on.
> 
> The alternative is to trap and emulate the EL1 timer for the guest so
> that it *appears* to be functional. But that's obviously bad from a
> performance perspective.
> 
> > Or is this kind of optimization strictly tied to KVM's internal behavior
> > and not something the kernel is expected to support generically?
> 
> It is purely Linux/KVM specific, and only works because we own both
> side of that equation, meaning we can enforce whatever is required to
> make the two work together. This obviously isn't possible with third
> party software. Look at it from a different point of view: how would
> you make this work with, say, Windows? or MacOS?
> 
> On the bright side, the architecture already gives you everything you
> need to implement your hypervisor. Just use it correctly.
> 
> Thanks,
> 
> 	M.

Hi Marc,

Thank you very much for the detailed explanation and your time.
Your clarification about the architectural intent and KVM-specific behavior
was really helpful and made things much clearer on our side.

Best regards,
Youngmin

> 
> -- 
> Without deviation from the norm, progress is not possible.
>