Files
linux/include/linux
Dave Hansen 74e19ef0ff uaccess: Add speculation barrier to copy_from_user()
The results of "access_ok()" can be mis-speculated.  The result is that
you can end speculatively:

	if (access_ok(from, size))
		// Right here

even for bad from/size combinations.  On first glance, it would be ideal
to just add a speculation barrier to "access_ok()" so that its results
can never be mis-speculated.

But there are lots of system calls just doing access_ok() via
"copy_to_user()" and friends (example: fstat() and friends).  Those are
generally not problematic because they do not _consume_ data from
userspace other than the pointer.  They are also very quick and common
system calls that should not be needlessly slowed down.

"copy_from_user()" on the other hand uses a user-controller pointer and
is frequently followed up with code that might affect caches.  Take
something like this:

	if (!copy_from_user(&kernelvar, uptr, size))
		do_something_with(kernelvar);

If userspace passes in an evil 'uptr' that *actually* points to a kernel
addresses, and then do_something_with() has cache (or other)
side-effects, it could allow userspace to infer kernel data values.

Add a barrier to the common copy_from_user() code to prevent
mis-speculated values which happen after the copy.

Also add a stub for architectures that do not define barrier_nospec().
This makes the macro usable in generic code.

Since the barrier is now usable in generic code, the x86 #ifdef in the
BPF code can also go away.

Reported-by: Jordy Zomer <jordyzomer@google.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>   # BPF bits
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-02-21 14:45:22 -08:00
..
2023-01-16 09:26:05 +01:00
2022-10-27 13:23:43 +02:00
2022-11-04 12:59:25 +02:00
2022-12-11 21:25:58 +01:00
2023-01-11 06:52:43 -05:00
2023-02-01 17:29:30 +01:00
2023-02-16 21:23:52 +00:00
2023-01-16 09:26:06 +01:00
2023-01-09 17:00:54 +01:00
2022-07-05 20:25:39 +02:00
2023-02-15 19:38:50 +01:00
2022-09-26 12:19:12 -07:00
2022-12-07 09:43:12 -07:00
2023-02-03 08:20:55 -07:00
2022-09-26 19:46:29 -07:00
2022-09-26 10:13:13 -07:00
2022-09-26 10:13:13 -07:00
2022-09-15 09:32:06 -07:00
2023-01-13 11:48:15 +01:00
2023-01-13 11:48:16 +01:00
2022-12-02 18:12:40 +08:00
2022-11-18 09:14:10 +01:00
2022-12-11 18:12:17 -08:00
2022-06-28 10:37:25 -03:00
2023-01-29 15:18:33 -07:00
2023-01-29 15:18:33 -07:00
2023-01-19 09:24:28 +01:00
2023-01-11 06:52:43 -05:00
2022-10-24 12:30:26 +03:00
2022-10-03 14:02:45 -07:00
2022-11-11 18:18:05 -08:00
2023-01-19 09:24:28 +01:00
2022-09-01 18:04:43 +02:00
2023-02-15 19:38:53 +01:00
2022-06-27 06:29:12 -06:00
2022-09-08 12:59:00 -06:00
2022-09-26 13:31:20 +02:00
2022-11-15 00:42:02 -08:00
2022-12-11 19:30:20 -08:00
2022-09-01 18:08:44 +02:00
2023-02-13 10:11:20 +02:00
2022-07-17 17:31:38 -07:00
2022-10-03 14:03:19 -07:00
2023-01-19 09:24:28 +01:00
2023-01-19 09:24:28 +01:00
2022-11-09 19:28:49 -08:00
2022-06-19 10:38:26 +01:00
2022-07-27 14:04:52 +02:00
2023-01-19 09:24:30 +01:00
2023-01-19 09:24:30 +01:00
2022-08-02 12:34:04 -04:00
2022-08-22 14:26:30 +01:00
2022-08-09 14:11:34 -04:00
2022-07-29 20:16:58 -04:00
2022-10-16 17:58:54 -05:00
2022-10-03 17:34:32 -07:00
2022-09-26 19:46:27 -07:00
2023-01-16 09:26:06 +01:00
2023-01-04 14:44:13 -07:00
2023-01-19 09:24:28 +01:00
2022-12-20 03:13:45 +01:00
2022-10-23 18:06:54 -04:00
2023-01-19 09:24:28 +01:00
2022-06-27 14:41:31 +02:00
2022-12-09 19:47:41 -08:00
2023-01-03 17:49:22 -08:00
2022-09-07 12:42:25 +01:00
2022-09-29 15:20:29 +02:00
2022-12-10 13:36:05 -05:00
2023-01-13 11:48:16 +01:00
2022-09-22 16:12:34 +02:00
2022-09-22 16:12:34 +02:00
2023-01-08 20:59:17 -07:00
2022-08-28 16:52:28 +01:00
2022-10-07 09:32:40 -04:00
2022-06-13 09:54:52 -07:00
2022-09-26 19:46:18 -07:00
2022-07-10 21:17:30 -04:00
2023-01-19 09:24:28 +01:00
2022-10-24 12:12:32 -07:00