On 6/11/2025 5:58 AM, Juergen Gross wrote:
Here is a patch I cooked. I added an ALTERNATIVE() hack because the
new instructions can't be more than 6 bytes long. But with the patch you
just sent, it shouldn't be needed.
I have meanwhile dropped the patch copying the original indirect call.
R
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
-off-by: Xin Li (Intel)
Cc: sta...@vger.kernel.org
---
Change in v6:
*) Add TB from Sohil.
Change in v5:
*) Accurately rephrase the shortlog (hpa).
Change in v4:
*) Add a selftest to the patch set (Dave Hansen).
Change in v3:
*) Use "#ifdef CONFIG_X86_FRED" instead of IS_ENABLED(CONFI
Signed-off-by: Xin Li (Intel)
Cc: sta...@vger.kernel.org
---
Changes in v6:
*) Replace a "sub $128, %rsp" with "add $-128, %rsp" (hpa).
*) Declared loop_count_on_same_ip inside sigtrap() (Sohil).
*) s/sigtrap/SIGTRAP (Sohil).
Changes in v5:
*) Do "sub $-128, %rsp&quo
/
Changes in v6:
*) Replace a "sub $128, %rsp" with "add $-128, %rsp" (hpa).
*) Declared loop_count_on_same_ip inside sigtrap() (Sohil).
*) s/sigtrap/SIGTRAP (Sohil).
*) Add TB from Sohil to the first patch.
Xin Li (Intel) (2):
x86/fred/signal: Prevent immediate repeat of
On 6/6/2025 4:34 PM, Sohil Mehta wrote:
On 6/6/2025 10:45 AM, Xin Li (Intel) wrote:
---
arch/x86/include/asm/sighandling.h | 22 ++
arch/x86/kernel/signal_32.c| 4
arch/x86/kernel/signal_64.c| 4
3 files changed, 30 insertions(+)
Tested-by
.
This test checks for that specific scenario—verifying whether the kernel
correctly prevents an infinite SIGTRAP loop in this edge case when FRED
is enabled.
The test should _always_ pass with IDT event delivery, thus no need to
disable the test even when FRED is not enabled.
Signed-off-by: Xin Li
-step trap upon completion of
ERETU. Therefore, another #DB is triggered before any user space
instruction is executed, which leads to an infinite loop in which the
SIGTRAP handler keeps being invoked on the same user space IP.
Suggested-by: H. Peter Anvin (Intel)
Signed-off-by: Xin Li (Intel)
Cc
-...@zytor.com/
Changes in v5:
*) Accurately rephrase the shortlog (hpa).
*) Do "sub $-128, %rsp" rather than "add $128, %rsp", which is more
efficient in code size (hpa).
*) Add TB from Sohil.
*) Add Cc: sta...@vger.kernel.org to all patches.
Xin Li (Intel) (2):
x86/
.
This test checks for that specific scenario—verifying whether the kernel
correctly prevents an infinite SIGTRAP loop in this edge case when FRED
is enabled.
The test should _always_ pass with IDT event delivery, thus no need to
disable the test even when FRED is not enabled.
Signed-off-by: Xin Li
. Therefore, another #DB is triggered before any user space
instruction is executed, which leads to an infinite loop in which the
SIGTRAP handler keeps being invoked on the same user space IP.
Suggested-by: H. Peter Anvin (Intel)
Signed-off-by: Xin Li (Intel)
Cc: sta...@vger.kernel.org
---
Change
.
[1] https://lore.kernel.org/lkml/20250523050153.3308237-1-...@zytor.com/
[2] https://lore.kernel.org/lkml/20250530230707.2528916-1-...@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
.
This test checks for that specific scenario—verifying whether the kernel
correctly prevents an infinite SIGTRAP loop in this edge case.
Signed-off-by: Xin Li (Intel)
---
tools/testing/selftests/x86/Makefile | 2 +-
.../selftests/x86/test_sigtrap_handler.c | 80 +++
2
On 5/13/2025 3:24 PM, H. Peter Anvin wrote:
On May 12, 2025 11:06:02 PM PDT, "Jürgen Groß" wrote:
On 13.05.25 07:55, Xin Li wrote:
On 5/12/2025 4:24 AM, Juergen Gross wrote:
Now with the mentioned patch really attached. :-)
Does it allow patching with an instruction more than 6
On 5/12/2025 4:20 AM, Jürgen Groß wrote:
On 09.05.25 10:18, Xin Li wrote:
On 5/6/2025 2:20 AM, Juergen Gross wrote:
I'm trying to evaluate how to add the immediate form MSR instructions
on top of this patch set. And I'm close to get it done.
There is something to consider when ru
On 5/12/2025 11:06 PM, Jürgen Groß wrote:
On 13.05.25 07:55, Xin Li wrote:
On 5/12/2025 4:24 AM, Juergen Gross wrote:
Now with the mentioned patch really attached. :-)
Does it allow patching with an instruction more than 6 bytes long?
The immediate form MSR instructions are 9 bytes long
On 5/12/2025 4:24 AM, Juergen Gross wrote:
Now with the mentioned patch really attached. :-)
Does it allow patching with an instruction more than 6 bytes long?
The immediate form MSR instructions are 9 bytes long.
Thanks!
Xin
On 5/6/2025 2:20 AM, Juergen Gross wrote:
Instead of having callback functions for rdmsr/wrmsr on native, switch
to inline the respective instructions directly in order to avoid
overhead with the call interface.
To me, this is a beneficial addition to the existing pvops MSR code.
This requir
On 12/2/2024 10:47 PM, Juergen Gross wrote:
P.S.: As the paravirt maintainer I would have preferred to be Cc-ed in the
initial patch mail.
Looks that Kevin didn't run './scripts/get_maintainer.pl'?
Thanks!
Xin
On 12/2/2024 5:44 PM, Kevin Loughlin wrote:
On Mon, Dec 2, 2024 at 5:28 PM Andrew Cooper wrote:
On 03/12/2024 12:59 am, Kevin Loughlin wrote:
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index d4eb9e1d61b8..c040af2d8eff 100644
--- a/arch/x86/include/asm/parav
On 1/26/2024 8:41 PM, Jinghao Jia wrote:
Both INTs (INT n, INT1, INT3, INTO) and UDs (UD0, UD1, UD2) serve
special purposes in the kernel, e.g., INT3 is used by KGDB and UD2 is
involved in LLVM-KCFI instrumentation. At the same time, attaching
kprobes on these instructions (particularly UDs) will
21 matches
Mail list logo
