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  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]
Date:   Wed, 6 Jan 2021 12:23:56 +0000
From:   Mark Rutland <>
Cc:     Will Deacon <>,,
Subject: Re: Set DBGCLAIM when self-host debug is enabled

On Wed, Jan 06, 2021 at 06:29:53PM +0800, wrote:
> Hi Will and Mark,

Hi Tingwei,

> In recent implementation of save/restore ARM debug registers in
> EL2/EL3, we found it's necessary to know whether self-host debug is
> enabled so EL2/EL3 can avoid saving/restoring debug registers but no
> one is using debug.

In what situation are you considering? I assume you mean idle sequences

Generally our expectation for CPU_SUSPEND is:

* Where StateType==0, the debug state is preserved with all other
  PE state.

* Where StateType==1 and the PE returns "warm" without having entered a
  powerdown state, the debug state is preserved along with all other PE

* Where StateType==1, and the PE returns "cold" after having entered a
  powerdown state (i.e. we return via the entry point address), the
  debug state is not preserved.

... and I'm missing where you could avoid saving the state. What
situation(s) did you have in mind?

> In ARM PSCI, it has one option to set DBGCLAIM[1] to 1 to indicate
> that debug is in use by a self-host debugger. Do you think it's
> resonable to add this to Kernel?
> For example, can we set DBGCLAIM[1] to 1 in enable_debug_monitors()
> and clear it in disable_debug_monitors().

I was under the impression that this was solely for the benefit of an
external debugger, and should have no functional impact on the PSCI
implementation from the kernel's PoV, so as above I think we need a
better description of the case you're trying to address.


Powered by blists - more mailing lists