From: Ian Zimmerman <itz@very.loosely.org>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Spectre-NG
Date: Wed, 9 May 2018 15:50:13 -0700 [thread overview]
Message-ID: <20180509225012.tbzlrx2b623tkc7f@matica.foolinux.mooo.com> (raw)
In-Reply-To: <5AF34625.9010708@youngman.org.uk>
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 that
> gcc was optimising out security-sensitive code (namely, a two-fingered
> salute near enough), I doubt the gcc team would have any interest in
> optimisations that SLOWED DOWN the resultant code.
>
> I suspect that might be one of the forces driving the kernel towards
> CLANG - a development team that is not obsessed with performance at
> the expense of breaking any code that uses undefined features.
I'm afraid I side with the gcc people in this interminable flamewar.
Code may be "security-sensitive" but buggy. Is the compiler writer
really responsible for guessing what the programmer meant to accomplish
with buggy code? It would of course be preferable if the compiler could
just abort with an error when it detects UB, but that turns out to be
very hard to impossible in the case of C. That's just a built in
problem with the language.
Further, I don't think the llvm/clang position on these cases is all
that different, although there may be a difference in emotional
attitude.
> Unfortunately, when dealing with hardware, one is forced to rely on
> undefined features. A strong point of C, until the compiler decides to
> go "rogue" on you ...
I don't understand what you mean here. In the disputed cases there was
always a well-defined way (slightly more verbose but not prohibitively
so) to code the desired behavior.
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.
next prev parent reply other threads:[~2018-05-09 22:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-07 11:15 [gentoo-user] Spectre-NG Mick
2018-05-07 11:45 ` Rich Freeman
2018-05-08 8:19 ` [gentoo-user] Spectre-NG Martin Vaeth
2018-05-08 20:15 ` Rich Freeman
2018-05-09 18:18 ` Martin Vaeth
2018-05-09 19:04 ` Wols Lists
2018-05-09 22:50 ` Ian Zimmerman [this message]
2018-05-10 13:35 ` Wol's lists
2018-05-10 16:52 ` Ian Zimmerman
2018-05-09 19:16 ` Rich Freeman
2018-05-10 5:34 ` Martin Vaeth
2018-05-10 13:58 ` Rich Freeman
2018-05-10 15:31 ` Martin Vaeth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180509225012.tbzlrx2b623tkc7f@matica.foolinux.mooo.com \
--to=itz@very.loosely.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox