[gentoo-user] Re: Spectre-NG

2018-05-09 Thread Martin Vaeth
Rich Freeman wrote: > On Tue, May 8, 2018 at 4:19 AM Martin Vaeth wrote: > >> Rich Freeman wrote: >> > >> > Higher-level languages will probably become nearly immune to Spectre > just >> > as most are nearly immune to buffer overflows. > >> Quite the opposite: Higher-level languages *always* do

Re: [gentoo-user] Re: Spectre-NG

2018-05-09 Thread Wols Lists
On 09/05/18 19:18, Martin Vaeth wrote: > As mentioned, I wonder why gcc/clang do not yet support this > horribly slow but spectre-safe option. It can't be that hard to > implement in the actual code-producing back-end. Given the response by the gcc team to security people complaining that gcc was

Re: [gentoo-user] Re: Spectre-NG

2018-05-09 Thread Rich Freeman
On Wed, May 9, 2018 at 2:18 PM Martin Vaeth wrote: > Rich Freeman wrote: > > On Tue, May 8, 2018 at 4:19 AM Martin Vaeth wrote: > > > >> Rich Freeman wrote: > >> > > >> > Higher-level languages will probably become nearly immune to Spectre > > just > >> > as most are nearly immune to buffer ov

[gentoo-user] Re: Spectre-NG

2018-05-09 Thread Ian Zimmerman
On 2018-05-09 20:04, Wols Lists wrote: > > As mentioned, I wonder why gcc/clang do not yet support this > > horribly slow but spectre-safe option. It can't be that hard to > > implement in the actual code-producing back-end. > > Given the response by the gcc team to security people complaining th

[gentoo-user] Re: Spectre-NG

2018-05-09 Thread Martin Vaeth
Rich Freeman wrote: > On Wed, May 9, 2018 at 2:18 PM Martin Vaeth wrote: > >> Which would be the horribly slow case I mentioned above. > > I'm saying that high-level languages can be made safe. > > You're saying that making high-level languages safe comes at a performance > cost. A performance c