Re: Retbleed, another speculative execution attack

>> FreeBSD should keep a wiki table of all these
>> HW attacks with at least three columns...
>> - The exploit
>> - Were mitigations published [by hw vendors or sw communities]
>> - Were those or other [mitigations] applied [to freebsd]

On 7/13/22, John Gray <johngray.au@gmail.com> wrote:
> Like this one?
> https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities

Cool, yes, more or less. Though that one may be missing
some number of hardware (HW) vulnerabilities.

They are a distinct space imposed on OS's by upstream HW makers
(as opposed to self-imposed SW kernel, user, app, compiler, etc bugs),
ambitious wiki'ers could track them all the way back to F00F, etc.
Though only those HW bugs with actual or suspected potential for
an exploitable security vector would need listed, not simple lockups,
reboots, incorrect return status or data, as in the typical HW errata sheets.

Maybe some organizing updates...

Background and other generic upstream literature could
by now be replaced with a few overall wikipedia links.
Try one bug per row by its canonical links and name (usually CVE)
to show BSD saw and signed off in what ways on each (whichever
among ticket, review, commit, mail thread).
Only the per bug list of 'fixes/mitigs available' and 'fixes/mitigs applied'
matters to users. 'Vulnerable' or 'not vulnerable' is meta curation that
really only matters to legacy hardware shoppers and critiquers of
HW makers, and is already available in the offsite literature.
The HEAD signoff is more important to track for long term reference
than maintaining list of EOL major.minor's when that info already
flows from and within links to the head work anyway.
In the interest of importance on first glance "seen and signed off,
didn't totally miss a CVE somewhere" aspect.
From there, whatever level of work-from flow matrix and detail
can then follow.


Someone failed to post their reply to the list...

"
FreeBSD doesn't have a fix for that one, but it also doesn't have
fixes for Spectre V1, Spectre-BHB, or MMIO Stale Data.
FreeBSD is still a sitting duck for these CPU vulns, so adding yet
another one on top doesn't really matter.
"


And please quit top-posting... replies belong below
what you are replying to so people can linearly
follow entire context like a book top to bottom,
and don't have to labor to fix the disorderly mess
you created when they reply to it.