linux-kernel - Re: [PATCH] net: core: Fix 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181223041253.bxqru567rs32mecg@ast-mbp.dhcp.thefacebook.com>
Date:   Sat, 22 Dec 2018 20:12:55 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     "Gustavo A. R. Silva" <gustavo@...eddedor.com>
Cc:     David Miller <davem@...emloft.net>, ast@...nel.org,
        daniel@...earbox.net, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: core: Fix Spectre v1 vulnerability

On Sat, Dec 22, 2018 at 09:37:02PM -0600, Gustavo A. R. Silva wrote:
> 
> Can't we have the case in which the code can be "trained" to read
> perfectly valid values for prog->len for quite a while, making the
> microcode come into place and speculate about:
> 
> 1013         if (flen == 0 || flen > BPF_MAXINSNS)
> 1014                 return false;
> 
> and then make flen to be greater than BPF_MAXINSNS?

Yes. The user space can train line 1013 to mispredict by passing
smaller flen N times and then passing large flen.
Why do you think it's exploitable?

Without the patch in the mispredicted path the cpu will do
if (0 < flen) condition and since flen is hot in the cache
it will happily execute the filter[0] load...
and about 12-20 u-ops later (depending on u-arch of cpu) when
branch predictor realizes that it's a miss, the cpu will ignore
the values computed in the shadow cpu registers used by speculative execution
and go back to the 'return false' execution path.
The side effect of bringing filter[0] value in L1 cache is still there.
The cpu is incapable to undo that cache load. That's what spectre1 is about.
Do you see how filter[0] value in cpu L1 cache is exploitable?

I took another look at the following patches:
"net: core: Fix Spectre v1 vulnerability"
"nfc: af_nfc: Fix Spectre v1 vulnerability"
"can: af_can: Fix Spectre v1 vulnerability"
and I have to say that none of them are necessary.
I'm not sure whether there were other patches that pretend to fix spectre1.