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 t
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 (fixed-length, \0, \n,
>> ...) specu
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
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
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
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
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
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
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 vulnerable.
You can only mak
11 matches
Mail list logo
