On Mon, Feb 20, 2023 at 3:25 AM KP Singh <kpsingh@xxxxxxxxxx> wrote:
>
> On Mon, Feb 20, 2023 at 3:20 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Feb 20, 2023 at 03:11:24AM -0800, KP Singh wrote:
> > > 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."
> >
> > Yes, but you already have a patch here, what "help" do you need? You
> > didn't specify any help, you just sent us a patch with no context. This
> > wasn't any sort of a "report" or "hey, I think we found a problem over
> > here, does this change look correct", right?
> >
> > So please be specific as to what you are asking for, otherwise we have
> > to guess (i.e. you cc:ed a seemingly random set of people but not the
>
> I don't see how it matters who I cc on the list. Anyways, I am still
Cc on my report, I mean.
> not clear on what one is supposed to do in the case when one has a
> patch for an issue already. Should this not be send it to security@?
>
> > x86 maintainers). And then you resent it to a public list, so there's
> > no need for security@k.o to get involved in at all as it's a public
> > issue now.
>
> Agreed.
> >
> > thanks,
> >
> > greg k-h
