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>] [day] [month] [year] [list]
Message-ID: <20241120073637.iwQyy4q7@linutronix.de>
Date: Wed, 20 Nov 2024 08:36:37 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Clark Williams <clark.williams@...il.com>
Cc: Clark Williams <clrkwllms@...nel.org>,
	Huacai Chen <chenhuacai@...nel.org>,
	Huacai Chen <chenhuacai@...ngson.cn>,
	Xuerui Wang <kernel@...0n.name>, loongarch@...ts.linux.dev,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-rt-devel@...ts.linux.dev, Guo Ren <guoren@...nel.org>,
	Jiaxun Yang <jiaxun.yang@...goat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] LoongArch: Allow to enable PREEMPT_RT

On 2024-11-20 02:17:53 [+0000], Clark Williams wrote:
> On Mon, Nov 18, 2024 at 7:37 AM Sebastian Andrzej Siewior <
> bigeasy@...utronix.de> wrote:
> 
> > On 2024-11-14 08:43:21 [-0600], Clark Williams wrote:
> > > We see similar problems with chronyd accessing the RTC on aarch64
> > > systems that use UEFI. Accessing anything via the EFI Runtime is very
> > > slow. Probably going to turn off 'rtcsync' in chronyd when running
> > > low-latency workloads.
> >
> > But isn't "we call into EFI and have no clue what happens" exactly the
> > reason why we disable EFI runtime services?
> >
> >
> I've had customers want access to EFI variables. I believe we default EFI
> runtime to be off and allow it to be turned on.

So the efi-rtc is accessed via functions calls into EFI. So you call in
there and they do (probably) access the RTC via i2c and remain in EFI
(block) for the entire process. That is why the access is disabled. The
difference here is that the bus access is slow so every read/ write
seems to take a while.

The EFI variable access by itself is fine however the variables might be
saved in NAND flash. The write access may trigger an erase process and
relocate the data and so may the read if too many bit flips were
detected.

> Clark

Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ