tomoyo: common: Fix potential Spectre v1 vulnerability

profile is controlled by user-space via /sys/kernel/security/tomoyo/profile, hence leading to a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

security/tomoyo/common.c:498 tomoyo_assign_profile() warn: potential spectre issue 'ns->profile_ptr' [r] (local cap)

security/tomoyo/common.c:499 tomoyo_assign_profile() warn: possible spectre second half.  'ptr'
security/tomoyo/common.c:505 tomoyo_assign_profile() warn: possible spectre second half.  'ptr'
security/tomoyo/common.c:523 tomoyo_assign_profile() warn: possible spectre second half.  'ptr'

Fix this by sanitizing profile before using it to index ns->profile_ptr

Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/[email protected]/

---
 security/tomoyo/common.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

index dd3d5942e669..45858dbcfdb9 100644
@@ -8,6 +8,7 @@
 #include <linux/uaccess.h>
 #include <linux/slab.h>
 #include <linux/security.h>
+#include <linux/nospec.h>
 #include "common.h"
 
 /* String table for operation mode. */

@@ -488,13 +489,15 @@ static void tomoyo_print_number_union(struct tomoyo_io_buffer *head,
  * Returns pointer to "struct tomoyo_profile" on success, NULL otherwise.
  */
 static struct tomoyo_profile *tomoyo_assign_profile
-(struct tomoyo_policy_namespace *ns, const unsigned int profile)
+(struct tomoyo_policy_namespace *ns, unsigned int profile)
 {
 	struct tomoyo_profile *ptr;
 	struct tomoyo_profile *entry;
 
 	if (profile >= TOMOYO_MAX_PROFILES)
 		return NULL;
+	profile = array_index_nospec(profile, TOMOYO_MAX_PROFILES);
+
 	ptr = ns->profile_ptr[profile];
 	if (ptr)
 		return ptr;

2.22.0

Hello.

Thanks for a patch, but I have a question.

It is true that "profile" value is given from user-space, and it will be true that speculative execution would access "ns->profile_ptr[profile]" before whether "profile >= TOMOYO_MAX_PROFILES" is true is concluded. But

which memory address is vulnerable to Spectre variant 1 attack? How can an attacker gain information from memory speculatively accessed by "ns->profile_ptr[profile]" ? Where is the memory access which corresponds to "arr2->data[index2]" demonstrated at
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html ?

Since I'm not familiar with Spectre/Meltdown problem, this patch sounds as if "Oh, let's suppress Smatch warning". I want to know whether this problem is real and this patch is worth keeping [email protected] ...