On Mon, Feb 20, 2023 at 3:25 AM KP Singh kpsingh@kernel.org wrote:
On Mon, Feb 20, 2023 at 3:20 AM Greg KH gregkh@linuxfoundation.org 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@linuxfoundation.org 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@gmail.com Reported-by: Rodrigo Branco rodrigo@kernelhacking.com Reviewed-by: Alexandra Sandulescu aesa@google.com Reviewed-by: Jim Mattson jmattson@google.com Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS") Cc: stable@vger.kernel.org Signed-off-by: KP Singh kpsingh@kernel.org
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@kernel.org, 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