Re: [PATCH v2 2/2] x86/cpu/intel: Add implicit RFDS mitigation for Goldmont and Tremont-D

[Joongsun Moon-Lee]

After further investigation and empirical testing on Goldmont N3350,
I am withdrawing this patch series (both Patch 1 and 2).

Based on the feedback and my subsequent analysis, here is the summary of
why I've concluded these patches should not be merged:

1. Latency Verification: To verify if the forced RFDS mitigation actually
   triggers VERW, I measured the average latency of the getpid() syscall
   by comparing a kernel with the mitigation enabled against one
   with it disabled.
   - Mitigation Disabled: ~177 cycles
   - Mitigation Enabled: ~188 cycles
   While this ~6% overhead suggests that VERW is executing some level of
   buffer clearing, it does not specifically prove RFDS-level mitigation.

2. PoC Verification: I ran a PoC to verify Register File clearing via VERW,
   but the results were inconclusive. Due to the complexities of register
   restoration and potential PoC limitations, I could not reliably
   demonstrate RFDS mitigation.

3. Microcode Timeline Mismatch: While Intel's documentation suggests
   a fix is available, the latest microcode for Goldmont N3350 (rev 0x48)
   was released in 2022, predating the 2024 RFDS disclosure.
   Without a confirmed microcode update explicitly clearing Register File,
   forcing this quirk would risk reporting a false "Mitigated" status.

Conclusion: As a security-sensitive part of the kernel, it is better
to leave the status as "Vulnerable: No microcode" rather than misreporting
a mitigation that cannot be verified against the known microcode release
and PoC results.

Thank you for the critical feedback, which prompted me to perform
this deeper dive into the hardware's actual behavior

Best regards,
Joongsun Moon-Lee