IDT event delivery has a debug hole in which it does not generate #DB
upon returning to userspace before the first userspace instruction is
executed if the Trap Flag (TF) is set.

FRED closes this hole by introducing a software event flag, i.e., bit
17 of the augmented SS: if the bit is set and ERETU would result in
RFLAGS.TF = 1, a single-step trap will be pending upon completion of
ERETU.

However I overlooked properly setting and clearing the bit in different
situations.  Thus when FRED is enabled, if the Trap Flag (TF) is set
without an external debugger attached, it can lead to an infinite loop
in the SIGTRAP handler.  To avoid this, the software event flag in the
augmented SS must be cleared, ensuring that no single-step trap remains
pending when ERETU completes.

This patch set combines the fix [1] and its corresponding selftest [2]
(requested by Dave Hansen) into one patch set.

[1] https://lore.kernel.org/lkml/20250523050153.3308237-1-xin@zytor.com/
[2] https://lore.kernel.org/lkml/20250530230707.2528916-1-xin@zytor.com/


This patch set is based on tip/x86/urgent branch as of today.


Xin Li (Intel) (2):
  x86/fred/signal: Prevent single-step upon ERETU completion
  selftests/x86: Add a test to detect infinite sigtrap handler loop

 arch/x86/include/asm/sighandling.h         | 22 +++++
 arch/x86/kernel/signal_32.c                |  4 +
 arch/x86/kernel/signal_64.c                |  4 +
 tools/testing/selftests/x86/Makefile       |  2 +-
 tools/testing/selftests/x86/sigtrap_loop.c | 97 ++++++++++++++++++++++
 5 files changed, 128 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/x86/sigtrap_loop.c


base-commit: dd2922dcfaa3296846265e113309e5f7f138839f
-- 
2.49.0

On 6/5/2025 11:10 AM, Xin Li (Intel) wrote:

> 
> Xin Li (Intel) (2):
>   x86/fred/signal: Prevent single-step upon ERETU completion
>   selftests/x86: Add a test to detect infinite sigtrap handler loop
> 

I tested the patches on a machine that supports FRED. The results are as
expected:

FRED on  — no Fix   => FAIL
FRED off — no Fix   => PASS
FRED on  — with Fix => PASS
FRED off — with Fix => PASS

Tested-by: Sohil Mehta <sohil.mehta@intel.com>

Though, I haven't tested the 32-bit version of the selftest.

>  arch/x86/include/asm/sighandling.h         | 22 +++++
>  arch/x86/kernel/signal_32.c                |  4 +
>  arch/x86/kernel/signal_64.c                |  4 +
>  tools/testing/selftests/x86/Makefile       |  2 +-
>  tools/testing/selftests/x86/sigtrap_loop.c | 97 ++++++++++++++++++++++
>  5 files changed, 128 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/x86/sigtrap_loop.c
> 

On 6/5/2025 12:32 PM, Sohil Mehta wrote:
> On 6/5/2025 11:10 AM, Xin Li (Intel) wrote:
> 
>>
>> Xin Li (Intel) (2):
>>   x86/fred/signal: Prevent single-step upon ERETU completion
>>   selftests/x86: Add a test to detect infinite sigtrap handler loop
>>
> 
> I tested the patches on a machine that supports FRED. The results are as
> expected:
> 

Seeing a split lock warning when running the test:
x86/split lock detection: #DB: sigtrap_loop_64/4614 took a bus_lock trap
at address: 0x4011ae

Wanted to get this out sooner for awareness. Will figure out more
details and send out an update.

> FRED on  — no Fix   => FAIL
> FRED off — no Fix   => PASS
> FRED on  — with Fix => PASS
> FRED off — with Fix => PASS
> 
> Tested-by: Sohil Mehta <sohil.mehta@intel.com>
> 
> Though, I haven't tested the 32-bit version of the selftest.
> 
>>  arch/x86/include/asm/sighandling.h         | 22 +++++
>>  arch/x86/kernel/signal_32.c                |  4 +
>>  arch/x86/kernel/signal_64.c                |  4 +
>>  tools/testing/selftests/x86/Makefile       |  2 +-
>>  tools/testing/selftests/x86/sigtrap_loop.c | 97 ++++++++++++++++++++++
>>  5 files changed, 128 insertions(+), 1 deletion(-)
>>  create mode 100644 tools/testing/selftests/x86/sigtrap_loop.c
>>

On 6/5/2025 2:51 PM, Sohil Mehta wrote:
>>> Xin Li (Intel) (2):
>>>    x86/fred/signal: Prevent single-step upon ERETU completion
>>>    selftests/x86: Add a test to detect infinite sigtrap handler loop
>>>
>> I tested the patches on a machine that supports FRED. The results are as
>> expected:
>>
> Seeing a split lock warning when running the test:
> x86/split lock detection: #DB: sigtrap_loop_64/4614 took a bus_lock trap
> at address: 0x4011ae
> 
> Wanted to get this out sooner for awareness. Will figure out more
> details and send out an update.

We investigated this issue, and figured out the reason why we see a
split lock warning when running the test:

1) The warning is not caused by the test.
2) It's a false warning.
3) It happens even when bus lock detection (BLD) is not enabled.
4) It happens only on the first #DB on a CPU.

The root cause is that Linux writes 0 to DR6 at boot time, which results
in different values in DR6 depending on whether they support BLD or not.

On CPUs that support BLD, writing 0 to DR6 sets DR6 to 0xFFFF07F0, i.e.,
bit 11 of DR6, its BLD flag, is cleared.  Otherwise 0xFFFF0FF0.

But Intel SDM says, other than BLD induced #DB, DR6.BLD is not modified.
To avoid confusion in identifying debug exceptions, software debug-
exception handlers should set bit 11 to 1 before returning.  DR6.BLD
is always 1 if the processor does not support OS bus-lock detection.

Because Linux clears DR6.BLD on CPUs that support BLD at boot time, the
first #DB will be INCORRECTLY interpreted as a BLD #DB, thus the
warning, no matter whether BLD is enabled or not.

We will be working on a fix to initialize DR6 and DR7 with their
architectural reset values instead of 0s.

Thanks!
     Xin