[gentoo-user] Re: Spectre-NG

2018-05-10 Thread Ian Zimmerman
On 2018-05-10 14:35, Wol's lists wrote: > > Code may be "security-sensitive" but buggy. Is the compiler writer > > really responsible for guessing what the programmer meant to > > accomplish with buggy code? > > What do you mean by "buggy"? Relying on UB, or not telling the compiler the whole

[gentoo-user] Re: Spectre-NG

2018-05-10 Thread Martin Vaeth
Rich Freeman wrote: > On Thu, May 10, 2018 at 1:34 AM Martin Vaeth wrote: > >> As a simple example, assume that you have read a password file >> into a string of your language and now access a single password. >> No matter, how you mark the end of the password

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

2018-05-10 Thread Rich Freeman
On Thu, May 10, 2018 at 1:34 AM Martin Vaeth wrote: > As a simple example, assume that you have read a password file > into a string of your language and now access a single password. > No matter, how you mark the end of the password (fixed-length, \0, \n, > ...) speculative

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

2018-05-10 Thread Wol's lists
On 09/05/18 23:50, Ian Zimmerman wrote: Code may be "security-sensitive" but buggy. Is the compiler writer really responsible for guessing what the programmer meant to accomplish with buggy code? What do you mean by "buggy"? It would of course be preferable if the compiler could just

[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

[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

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

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

[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. > >>

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

2018-05-08 Thread Rich Freeman
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*

[gentoo-user] Re: Spectre-NG

2018-05-08 Thread Martin Vaeth
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 some checks for array-length etc, and it is the _checks_ which are