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 execution might alway
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 abort
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
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
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 some checks
> for array-length e
5 matches
Mail list logo
