| Message ID | 20190731185457.GA21407@embeddedor (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | tomoyo: common: Fix potential Spectre v1 vulnerability | expand |
Hello. Thanks for a patch, but I have a question. On 2019/08/01 3:54, Gustavo A. R. Silva wrote: > profile is controlled by user-space via /sys/kernel/security/tomoyo/profile, 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 > hence leading to a potential exploitation of the Spectre variant 1 > vulnerability. 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 stable@vger.kernel.org ... > @@ -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; > By the way, since /sys/kernel/security/tomoyo/profile is writable by only explicitly whitelisted domains/programs (&& by only root user by default), I think that it is OK to treat this "profile" value as trusted.
diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c index dd3d5942e669..45858dbcfdb9 100644 --- a/security/tomoyo/common.c +++ b/security/tomoyo/common.c @@ -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;
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/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> --- security/tomoyo/common.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)