linux-kernel - Re: [PATCH] atm: zatm: Fix potential Spectre v1

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]

Date:   Thu, 03 May 2018 15:25:03 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     rdunlap@...radead.org
Cc:     gustavo@...eddedor.com, 3chas3@...il.com,
        linux-atm-general@...ts.sourceforge.net, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] atm: zatm: Fix potential Spectre v1

From: Randy Dunlap <rdunlap@...radead.org>
Date: Thu, 3 May 2018 12:09:40 -0700

> Just for (my) info:  all of these types of patches are to prevent
> what is loaded in cache when the index is out of range, right?
> Not some random pool_info[random], but pool_info[valid, i.e., 0].
> 
> Since the value of pool is already sanity checked and -EINVAL is
> returned when it's out of range.

Well, the whole point is that the cpu can speculate execution past the
range check and execute the indexed read anyways.  So even if the
value is "sanity checked" the cpu can execute ahead and load things
into the cache, just cancelling the register state updates later when
the range check is fully resolved.