Soundness issues in crates for self-referential structs

[Shnatsel]

Most crates that allow self-referential structs are unsound. See Voultapher/self_cell#41 for a list of crates and issues.

We have advisories for Ourouboros (RUSTSEC-2023-0042) and owning-ref (https://rustsec.org/advisories/RUSTSEC-2022-0040.html), we should cover the remaining crates with advisories as well.

[tarcieri]

@Manishearth hopefully yoke isn't impacted?

[Manishearth]

AIUI no. yoke does have potential unsoundness based on some yet-to-be-figured-out opsem rules (and can be fixed with yet-to-be-figured-out APIs). I'm mostly planning on waiting that out, it's tracked in unicode-org/icu4x#2095. There is a way for us to avoid that potential unsoundness today; but that would require giving up an API that I would rather not do yet. Furthermore that potential unsoundness is only present for certain kinds of uses of Yoke.

In general yoke exposes a more limited form of self-reference and is not as susceptible to the issues found in general self-ref crates.

Personally because these rules are still in flux I do not consider "fails miri" to in and of itself be an indication of unsoundness, fwiw. I expect that when the time comes to actually start exploiting the UB surface provided by stacked borrows¹; the opsem group will have also provided sufficient APIs to do things like this in ways they can guarantee are sound.

That said, yoke does not currently trip miri anyway.

cc @CAD97

Footnotes

1. Though it's likely stacked borrows itself is going away and being replaced by tree borrows; which is an example of what I mean by these things still being in flux! ↩

[SoniEx2]

is it correct to say selfref is not affected by this?