linux-kernel - Re: [PATCH] tomoyo: common: Fix potential Spectre v1 vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <96483333-99e1-dce1-864a-5456ba6350d2@i-love.sakura.ne.jp>
Date:   Thu, 1 Aug 2019 20:02:46 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        Dan Carpenter <dan.carpenter@...cle.com>
Cc:     Kentaro Takeda <takedakn@...data.co.jp>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tomoyo: common: Fix potential Spectre v1 vulnerability

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