Messages in this thread | | | Date | Thu, 4 Jan 2018 01:41:00 +0000 | From | Alan Cox <> | Subject | Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier |
| |
On Thu, 4 Jan 2018 02:27:54 +0100 (CET) Jiri Kosina <jikos@kernel.org> wrote:
> On Thu, 4 Jan 2018, Alan Cox wrote: > > > There are people trying to tune coverity and other tool rules to identify > > cases, > > Yeah, but that (and *especially* Coverity) is so inconvenient to be > applied to each and every patch ... that this is not the way to go.
Agreed enitely - and coverity is non-free which is even worse as a dependancy. Right now we are in the 'what could be done quickly by a few people' space. The papers are now published, so the world can work on better solutions and extending more convenient tooling.
> If the CPU speculation can cause these kinds of side-effects, it just must > not happen, full stop.
At which point your performance will resemble that of a 2012 atom processor at best.
> OS trying to work it around is just a whack-a-mole > (which we can apply for old silicon, sure ... but not something that > becomes a new standard) that's never going to lead to any ultimate > solution.
In the ideal world it becomes possible for future processors to resolve such markings down to no-ops. Will that be possible or will we get more explicit ways to tell the processor what is unsafe - I don't personally know but I do know that turning off speculation is not the answer.
Clearly if the CPU must be told then C is going to have to grow some syntax for it and some other languages are going to see 'taint' moving from a purely software construct to a real processor one.
Alan
| |