On Mon, Feb 20, 2023 at 04:34:02AM -0800, KP Singh wrote:
On Mon, Feb 20, 2023 at 4:20 AM KP Singh kpsingh@kernel.org wrote:
On Mon, Feb 20, 2023 at 4:13 AM Josh Poimboeuf jpoimboe@kernel.org wrote:
On Mon, Feb 20, 2023 at 01:01:27PM +0100, KP Singh wrote:
+static inline bool spectre_v2_user_no_stibp(enum spectre_v2_mitigation mode) +{
/* When IBRS or enhanced IBRS is enabled, STIBP is not needed.** However, With KERNEL_IBRS, the IBRS bit is cleared on return* to user and the user-mode code needs to be able to enable protection* from cross-thread training, either by always enabling STIBP or* by enabling it via prctl.*/return (spectre_v2_in_ibrs_mode(mode) &&!cpu_feature_enabled(X86_FEATURE_KERNEL_IBRS));+}
The comments and code confused me, they both seem to imply some distinction between IBRS and KERNEL_IBRS, but in the kernel those are functionally the same thing. e.g., the kernel doesn't have a user IBRS mode.
And, unless I'm missing some subtlety here, it seems to be a convoluted way of saying that eIBRS doesn't need STIBP in user space.
Actually, there is a subtlety, STIBP is not needed in IBRS and eIBRS however, with KERNEL_IBRS we only enable IBRS (by setting and unsetting the IBRS bit of SPEC_CTL) in the kernel context and this is why we need to allow STIBP in userspace. If it were for pure IBRS, we would not need it either (based on my reading). Now, with spectre_v2_in_ibrs_mode, as per the current implementation implies that KERNEL_IBRS is chosen, but this may change. Also, I would also prefer to have it more readable in the sense that:
"If the kernel decides to write 0 to the IBRS bit on returning to the user, STIBP needs to to be allowed in user space"
We will never enable IBRS in user space. We tried that years ago and it was very slow.