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: <50fc1bd3-909e-41c4-a991-9d81e32ef92c@intel.com>
Date: Tue, 28 May 2024 07:18:54 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Tony W Wang-oc <TonyWWang-oc@...oxin.com>, tglx@...utronix.de,
 mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
 hpa@...or.com, keescook@...omium.org, tony.luck@...el.com,
 gpiccoli@...lia.com, mat.jonczyk@...pl, rdunlap@...radead.org,
 alexandre.belloni@...tlin.com, mario.limonciello@....com, yaolu@...inos.cn,
 bhelgaas@...gle.com, justinstitt@...gle.com, linux-kernel@...r.kernel.org,
 linux-hardening@...r.kernel.org
Cc: CobeChen@...oxin.com, TimGuo@...oxin.com, LeoLiu-oc@...oxin.com
Subject: Re: [PATCH] x86/hpet: Read HPET directly if panic in progress

On 5/27/24 23:38, Tony W Wang-oc wrote:
...> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index c96ae8fee95e..ecadd0698d6a 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -804,6 +804,12 @@ static u64 read_hpet(struct clocksource *cs)
>  	if (in_nmi())
>  		return (u64)hpet_readl(HPET_COUNTER);
>  
> +	/*
> +	 * Read HPET directly if panic in progress.
> +	 */
> +	if (unlikely(atomic_read(&panic_cpu) != PANIC_CPU_INVALID))
> +		return (u64)hpet_readl(HPET_COUNTER);
> +

There is literally one other piece of the code in the kernel doing
something similar: the printk() implementation.  There's no other
clocksource or timekeeping code that does this on any architecture.

Why doesn't this problem apply to any other clock sources?

Why should the problem be fixed in the clock sources themselves?  Why
doesn't printk() deadlock on systems using the HPET?

In other words, I think we should fix pstore to be more like printk
rather than hacking around this in each clock source.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ