linux-kernel - Re: Smatch check for Spectre stuff

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180425150314.jgkm4elvoylccvfp@lakrids.cambridge.arm.com>
Date:   Wed, 25 Apr 2018 16:03:15 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Dan Carpenter <dan.carpenter@...cle.com>,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        "Gustavo A. R. Silva" <gustavo@...eddedor.com>
Subject: Re: Smatch check for Spectre stuff

On Wed, Apr 25, 2018 at 03:48:52PM +0100, Alan Cox wrote:
> > 2) Compiler transformations can elide binary operations, so we cannot
> >    rely on source level AND (&) or MOD (%) operations to narrow the
> >    range of an expression, regardless of the types of either operand.
> > 
> >    This means that source-level AND and MOD operations cannot be relied
> >    upon under speculation.
> 
> You need to use volatiles and memory barriers if trying to do it
> explicitly in C. The compilers will do some really quite insanely
> brilliant things otherwise. That's one reason that not using fences is
> really tricky and belongs wrapped in helpers.

Sure thing -- the point is that source-level analysis tools must take
that into account.

> > I suspect this means *many* more potential spectre gadgets. :(
> 
> I expect so as well as probably a lot of false positives - the tools in
> the space are all pretty new.
> 
> Array access isn't always needed either. Remember that something as
> simple as
> 
> 	x = size_table[user];
> 	memset(buf, 0, x);
> 
> can speculatively reveal things, as can 'classical' side channels such as
> variable length instruction timings.

As discussed in the other sub-thread, the plan is to kill sequences at
the first load, which should prevent the leak via a subsequent
value-dependent sequence.

i.e. the above would be:

	user_nospec = array_index_nospec(user, ARRAY_SIZE(size_table));
	x = size_table[user_nospec];
	memset(buf, 0, x);

... which IIUC avoids the leak in this particular case.

Mark.