Re: [PATCH] x86/speculation: Fix user-mode spectre-v2 protection with KERNEL_IBRS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
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.

thanks,

greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux