dmcq (dmcq.delete@this.fano.co.uk) on July 15, 2022 4:54 am wrote:
> anon2 (anon.delete@this.anon.com) on July 14, 2022 6:40 pm wrote:
> > anon2 (anon.delete@this.anon.com) on July 14, 2022 5:37 pm wrote:
> > > Anon4 (No.delete@this.example.com) on July 14, 2022 5:05 pm wrote:
> > > > anon2 (anon.delete@this.anon.com) on July 14, 2022 4:29 pm wrote:
> > > > > No it wasn't, it was BTB poisoning to influence indirect branches.
> > > > > Branch direction forwards or backwads is not relevant.
> > > >
> > > > I've had my head to much on CFI recently.... forward edge, obviously branch direction is not relevant.
> > >
> > > There seems to be nothing about "forward edge" in spectre vulnerability. It is about indirect
> > > branches which use the BTB, return branches can be such indirect branches on these CPUs.
> > >
> > > >
> > > > > Some CPUs use BTB for return branches in some situations. This is not somehow new nor was unknown at the
> > > > > time. It was explicitly called out in a public discussion about the fix several years ago, actually.
> > > >
> > > > And was thought not to be exploitable, some people thought it was exploitable
> > >
> > > That's what I said. Nothing new from hardware standpoint, the only problem is incomplete mitigation
> > > for spectre v2. Or if you really want to quibble about semantics, the fact remains that the exact problem
> > > was known about and called out when the fix was being discussed. No new hardware vulnerability discovery,
> > > this is exploitation of known hole in known incomplete software fix for spectre v2.
> > >
> > > > however they could not come up with a practical attack at the time.
> > > >
> > > > Given the mitigation cost no one was going to roll out an expensive speculative (sic) mitigation against
> > > > an attack which was not thought to be practical at the time. That 'expensive' is in money, performance
> > > > losses cost real money for the hyperscalers and major ones can make a service economically unviable.
> > >
> > > Aside, many such security issues that are fixed have *actual* practical attacks
> >
> > Correction: Do NOT have actual practical attacks demonstrated.
> >
> > They may jump through very careful hoops to make it appear as though they have demonstrated
> > a practical attack, for example implementing a PoC that gets around some particular data
> > protection mechanism and do it in Javascript and have it work in laboratory conditions,
> > and then draw insinuations or imply (or allow the "tech" press to draw the line) that therefore
> > if you click on a web page it can steal your credit card number and bitcoins.
> >
> > Of course this is all great business for "security researcher" job security so they do it deliberately
> > and very few have any intention to even try to develop objective metrics, publish retrospectives
> > showing how much these security issues are exploited, or give reasonable advice such as don't
> > use hardware shared with untrusted user if you are paranoid and don't trust that we found all
> > problems and didn't make multi-year mistakes on issues such as this one.
> >
> > /end rant
> >
> > > demonstrated. Most of this security patching and mitigation has no objective
> > > measurement or even metrics that can inform the benefit of fixes.
>
>
> Not sure what that rant was in aid of. Shooting the messanger?

No, shooting the security-researcher-industrial-complex.