On Mon, Feb 20, 2023 at 2:52 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Feb 20, 2023 at 11:39:30AM +0100, KP Singh wrote:
> > With the introduction of KERNEL_IBRS, STIBP is no longer needed
> > to prevent cross thread training in the kernel space. When KERNEL_IBRS
> > was added, it also disabled the user-mode protections for spectre_v2.
> > KERNEL_IBRS does not mitigate cross thread training in the userspace.
> >
> > In order to demonstrate the issue, one needs to avoid syscalls in the
> > victim as syscalls can shorten the window size due to
> > a user -> kernel -> user transition which sets the
> > IBRS bit when entering kernel space and clearing any training the
> > attacker may have done.
> >
> > Allow users to select a spectre_v2_user mitigation (STIBP always on,
> > opt-in via prctl) when KERNEL_IBRS is enabled.
> >
> > Reported-by: José Oliveira <joseloliveira11@xxxxxxxxx>
> > Reported-by: Rodrigo Branco <rodrigo@xxxxxxxxxxxxxxxxx>
> > Reviewed-by: Alexandra Sandulescu <aesa@xxxxxxxxxx>
> > Reviewed-by: Jim Mattson <jmattson@xxxxxxxxxx>
> > Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: KP Singh <kpsingh@xxxxxxxxxx>
> > ---
> > arch/x86/kernel/cpu/bugs.c | 25 +++++++++++++++++--------
> > 1 file changed, 17 insertions(+), 8 deletions(-)
>
> As this is posted publicly, there's no need to send it to
> security@xxxxxxxxxx, it doesn't need to be involved.
Sure, it's okay. Please do note in my first patch, I did follow
https://www.kernel.org/doc/Documentation/admin-guide/security-bugs.rst,
if you want folks to explicitly Cc maintainers with their fix or
report, I think it's worth mentioning in the guidelines there as the
current language seems to imply that the maintainers will be pulled in
by the security team:
"It is possible that the security team will bring in extra help from
area maintainers to understand and fix the security vulnerability."
- KP
>
> thanks,
>
> greg k-h
