From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 948E81382C5 for ; Wed, 9 May 2018 19:16:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 83CB2E0D78; Wed, 9 May 2018 19:16:18 +0000 (UTC) Received: from mail-pg0-f65.google.com (mail-pg0-f65.google.com [74.125.83.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 040ECE0D65 for ; Wed, 9 May 2018 19:16:18 +0000 (UTC) Received: by mail-pg0-f65.google.com with SMTP id z4-v6so23074486pgu.13 for ; Wed, 09 May 2018 12:16:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=EzmJxN3nk9TxNuHcwvzRgYI7DSf/BYvPJmrUd3ULeIY=; b=ChbR+5cHi6sWEcMHMdijgKKLu0ePZ8a4FdhIsmkeOVfMBMLD7mMFnHbVxCop+Cs822 OZtuNFEFxqc7ggyxq0hwXVUPp9G4KcihdYamc53jTjVqyYsMnLAccUbwnZdfRgJ63u2V lNkIpDp40RSdCcKiMZZQ6LEoqGGuKy14nkcQ8LkcOgDXRBZooOmd41I1LijF+cw7At7h OXjf+Q7/jT8oLg7QR/TXXYd4UCRNcGVWpMsrwbSKjeCxFrRuHiCXuQdKHrBmfwPiWWYE W9d7q74kqAypBhZdz7yCcQ+bK6DRgHTmS7lcByMw8s9zuk8tPYc93kN45mWr2rZhPAoO 12+w== X-Gm-Message-State: ALQs6tCaFaCANBEIvLccTUYGdSANZtl+NLwYZX+p56AAbVoP5XBBL0gd FykJ7VdUd3sveeiySUljBkpiro8rO2RRffAdK+4FAy/c X-Google-Smtp-Source: AB8JxZqjf4ydHxrVrF9Mcee4/b/a8dwNTgRUxHgusIDe3ZHh7CVek1VFWS3PEyC1ReOYFyJprZKdGEZU2D34Z8Ik64E= X-Received: by 2002:a63:ae49:: with SMTP id e9-v6mr35842113pgp.38.1525893376662; Wed, 09 May 2018 12:16:16 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 References: <1549166.RPGoRN5ZiQ@dell_xps> In-Reply-To: From: Rich Freeman Date: Wed, 09 May 2018 19:16:06 +0000 Message-ID: Subject: Re: [gentoo-user] Re: Spectre-NG To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: c5711dac-6d68-4ff9-9c5b-0cf2ed547ff7 X-Archives-Hash: 3697eeb9040706afa4fc854a4c8e0995 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 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 make them non-vulnerable by making them horribly slow > >> (by omitting speculative execution completely for the corresponding > >> conditionals). > > > > Sure, but my point is that you CAN make them non-vulnerable by changing the > > compiler. > 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. These are not in contradiction. In fact the whole reason low-level languages still exist to this day (besides legacy code) is that most of the benefits of high-level languages come at a performance cost. Safety is just one of them. This is just as true for buffer overflows and memory management. If you take a lot of care, you can avoid the need for bounds checks on every array access. If you get it wrong, it can go horribly wrong. High-level languages tend to compensate by doing bounds checks even when they might not be needed. A lot of C programmers do the same with manual bounds checks or equivalent functions like strncpy. Again, I'm using buffer overflows as a more familiar analogy for others - I fully understand that bounds checks actually make Spectre worse. > If slowness is not the issue, one could fix the C compiler in the same way > by avoiding speculative exection for every conditional jump. Sure, but that is way more overhead than necessary. We only need to sterilize these for data passed from an untrusted source (I think). If a function declares an internal variable as a loop counter you don't need to disable speculative execution every time you increment and check the counter, and a loop is obviously exactly where you want to make this distinction. A low level language needs to use heuristics to try to figure out if a conditional jump is safe to speculatively execute (probably at compile time). A high-level language has access to more context and can probably more reliably determine which ones need protection. On the other hand it will probably do a lot more bounds-checking in general. I'm not sure which would end up costing more to make reliably safe. I think that in general language features that more clearly separate trusted vs untrusted data would probably help here. -- Rich