Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: YASV (Yet Another Security Vulnearability)
Date: Mon, 29 Jul 2024 17:32:19 +0000
Organization: Rocksolid Light
Message-ID: <f415b5e4659be0ee631cfa2f505d9a30@www.novabbs.org>
References: <v7rqbf$1ta84$1@dont-email.me> <20240725104113.000006e8@yahoo.com> <tJtoO.87238$BYv6.980@fx09.iad> <2024Jul26.181750@mips.complang.tuwien.ac.at> <hFToO.27997$iptd.11865@fx36.iad> <2024Jul29.123405@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="785904"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$G3NwI/VJoV9CKUxDr8Gnc.m/Hxlhc2oat8MCZJvbstGRd9Zm93/0q
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 6756
Lines: 116

On Mon, 29 Jul 2024 10:34:05 +0000, Anton Ertl wrote:

> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>Anton Ertl wrote:
> [...]
>>But if I recall correctly the fix for JavaScript was something like
>>a judiciously placed FENCE instruction to block speculation.
>
> "A"?  IIRC Speculative load hardening inserts LFENCE instructions in
> lots of places, IIRC between every branch and a subsequent load.  And
> it relies on an Intel-specific non-architectural (and thus not
> documented in the architecture manual) side effect of LFENCE, and
> AFAIK on AMD CPUs LFENCE does not have that side effect.  And the
> slowdowns I have seen in papers about speculative load hardening have
> been in the region 2.3-2.5.
>
>>And for the kernel this attack surface should be quite small as all of
>>these values are already validated.
>
> Which values are already validated and how does that happen?
>
> What I read about the Linux kernel is that for Spectre V1 the kernel
> developers try to put mitigations in those places where potential
> attacker-controlled data is expected; one such mitigation is to turn
> (predicted) control flow into (non-predicted) data flow.  The problem
> with that approach is that they can miss such a place, and even if it
> works, it's extremely expensive in developer time.
>
> As for missing such places that actually does happen: I read one paper
> or web page where a security researcher needed some hole in the
> Spectre defense of the kernel for his work (I don't remember what that
> was) and thanked somebody else for providing information about such a
> hole.  I am sure this hole is fixed in newer versions of the kernel,
> but who knows how many yet-undiscovered (by white hats) holes exist?
> This shows that this approach to dealing with Spectre is not a good
> long-term solution.
>
>>So wouldn't it just be a matter of replacing certain kernel value
>>validation IF statements with IF_NO_SPECULATE?
>
> It's a little bit different, but the major issue here is which
> "certain kernel value validation IF statements" should be hardened.
> You can, e.g., apply ultimate speculative load hardening across the
> whole kernel, and the kernel will slow down by a factor of about 2.5;
> and that would fix just Spectre v1 and maybe a few others, but not all
> Spectre-type vulnerabilities.
>
>>I have difficulty believing that the branch predictor values from some
>>thread in one process would be anything but a *negative* impact on a
>>random different thread in a different process.
>
> This sounds very similar to the problem of aliasing of two different
> branches in the branch predictor.  The branch predictor researchers
> have looked into that, and found that it does not pay off to tag
> predictions with the branches they are for.  The aliased branch is at
> least as likely to benefit from the prediction as it is to suffer from
> interference; as a further measure agree predictors [sprangle+97] were
> proposed; I don't know if they ever made it into practical
> application.
>
> As for the idea of erasing the branch predictor on process switch:
>
> Consider the case where your CPU-bound process has to make way for a
> short time slice of an I/O-bound process, and once that has submitted
> its next synchronous I/O request, your CPU-bound process gets control
> again.  The I/O bound process tramples only over a small part of
> branch predictor state, but if you erase on process switch, all the
> branch preductor state will be gone when the CPU-bound process gets
> the CPU core again.  That's the reason why we do not erase
> microarchitectural state on context switch; we do it neither for
> caches nor for branch predictors.
>
> Moreover, another process will likely use some of the same libraries
> the earlier process used, and will benefit from having the branches in
> the library predicted (unless ASLR prevents them from using the same
> entries in the branch predictor).
>
> @InProceedings{sprangle+97,
>   author = 	 {Eric Sprangle and Robert S. Chappell and Mitch Alsup
>                   and Yale N. Patt},

Hey, that's me !

>   title = 	 {The Agree Predictor: A Mechanism for Reducing
>                   Negative Branch History Interference},
>   crossref =	 {isca97},
>   pages =	 {284--291},
>   annote =	 {Reduces the number of conflict mispredictions by
>                   having the predictor entries predict whether or not
>                   some other predictor (say, a static predictor) is
>                   correct. This increases the chance that the
>                   predicted direction is correct in case of a
>                   conflict.}
> }
>
> @Proceedings{isca97,
>   title = 	 "$24^\textit{th}$ Annual International Symposium on Computer
> Architecture",
>   booktitle = 	 "$24^\textit{th}$ Annual International Symposium on
> Computer Architecture",
>   year = 	 "1997",
>   key =		 "ISCA 24",
> }
>
>>Because if you retain
>>the predictor values then the new thread has to unlearn what it learned,
>>before it starts to learn values for the new thread. Whereas if the
>>predictor is flushed it can immediately learn its own values.
>
> Unlearn?  The only thing I can think about in that direction is that a
> two-bit counter (for some history and maybe branch address) happens to
> be in a state where two instead of one misprediction is necessary
> before the prediction changes.  Anyway, branch prediction research has
> looked into the issue a long time ago and found that erasing on
> context switch is a net loss.
>
> - anton