Stream: project-ffi-unwind

Topic: FFI "change behavior or protect the caller"


view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:38):

@centril moving the "FFI is not a sandbox" conversation here

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:39):

Here's the way I formulated the "not supposed to change behavior or protect the caller" idea in my conversation earlier:

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:40):

I agree these are still not really fully-fleshed-out opinions, let alone statements of fact.

view this post on Zulip centril (Nov 14 2019 at 22:40):

Well they are statements, but without justification ^^

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:40):

But I would say that they "sound right" to me.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:41):

Do you have specific objections to either claim, or do you just want to see a justification before deciding whether or not you agree?

view this post on Zulip centril (Nov 14 2019 at 22:43):

I think those are too coarse statements and not sufficiently nuanced

view this post on Zulip centril (Nov 14 2019 at 22:43):

splitting ABIs, adding shims, etc. is in my view perfectly legitimate in the interest of e.g. soundness, perf, etc.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:44):

So, "soundness" is covered in the second bullet point.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:44):

I'm not sure I see how shims could ever _improve_ performance.

view this post on Zulip centril (Nov 14 2019 at 22:44):

Didn't feel that way to me but ok

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:44):

But that's certainly an aspect of the question I hadn't even considered.

view this post on Zulip centril (Nov 14 2019 at 22:45):

@Kyle Strand well the nounwind assumption would, but it wouldn't ostensibly cover "the whole ABI"

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:45):

nounwind isn't really a "shim", though, is it?

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:46):

Re: soundness, could you suggest an alternate phrasing of the second bullet point that does make it clear?

view this post on Zulip centril (Nov 14 2019 at 22:46):

@Kyle Strand not sure why you are linking perf and shims

view this post on Zulip centril (Nov 14 2019 at 22:46):

(I didn't)

view this post on Zulip centril (Nov 14 2019 at 22:47):

Protecting the user from undefined behavior (e.g. via an abort shim, in case you mess up) and maintaining soundness is part of Rust's core values, and FFI is not inherently an opt-out from that protection.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:47):

"Splitting ABIs, adding shims, etc ... perf, etc"

Was the performance consideration only meant to apply to "splitting ABIs", then?

view this post on Zulip centril (Nov 14 2019 at 22:47):

sure; nounwind & friends

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:48):

Okay. My first impulse is to say that that's not really subject to the "not a sandbox" objection.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:49):

Isn't "maintaining soundness" covered by "protecting the user from undefined behavior"?

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:49):

or implied by, rather

view this post on Zulip centril (Nov 14 2019 at 22:49):

depends on whether you are talking about the safe or unsafe fragment

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:50):

I'm a bit lost. "unsafe fragment"?

view this post on Zulip centril (Nov 14 2019 at 22:50):

the abort shim protects you from UB even in unsafe code; but it also maintains soundness

view this post on Zulip centril (Nov 14 2019 at 22:51):

one could ostensibly not have that shim for unsafe code, or only for unsafe code

view this post on Zulip centril (Nov 14 2019 at 22:51):

@Kyle Strand either case, the soundness/UB point does poke a hole in "not a sandbox" pretty well

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:52):

Yeah, that's why I'm trying to reformulate the objection without using the word "sandbox"; it's far too vague.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:53):

It's a metaphor that I believe helped me understand Nick's concern, but I fully agree it's not adequate!

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:53):

But I think the first point stands:

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:54):

_If_ it is true that exceptions are a well-defined part of an ABI, then I would agree with Nick that it's not a good idea to change the semantics of functions that throw by changing their ABI strings when calling them from Rust.

view this post on Zulip centril (Nov 14 2019 at 22:54):

"in any language" makes the claim also extraordinarily strong -- maybe one of these languages can't even make full use of the ABI representable without a lot of cost

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:55):

...then it shouldn't expose that ABI.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:56):

The negative way to phrase it would be: exposing an ABI but leaving out well-defined parts of that ABI is essentially failing to expose that ABI.

view this post on Zulip centril (Nov 14 2019 at 22:56):

I don't see why "ABI with restrictions" is illegitimate

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:57):

Well, partly I would say it fails the principle of least surprise, especially if the mechanism for specifying the ABI gives no indication that the ABI isn't fully supported.

view this post on Zulip centril (Nov 14 2019 at 22:58):

that's one consideration

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 22:58):

I.e. if the ABI string were itanium, where exceptions are definitely well defined (per the spec), one would expect that ABI to support exceptions.

view this post on Zulip centril (Nov 14 2019 at 22:59):

well in this case the ABI string is different

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 23:00):

Another is the one that @gnzlbg has been expressing, i.e., there's an appropriate way to restrict behavior/effects, but doing so via "ABIs with restrictions" is in some way suboptimal. (I don't want to try to paraphrase the reasoning here.)

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 23:00):

The main ABI string we're concerned about is extern "C", though. The ABI string is not different.

view this post on Zulip centril (Nov 14 2019 at 23:01):

I'm familiar with their concerns re. effects :slight_smile:

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 23:01):

There's sort of a "strong objection" to "ABI with restrictions", which is that they shouldn't exist at all; it sounds to me like Nick (the originator of the "sandbox" quote) is in this camp.

Then, there's a "weak objection", which is that "ABI with restrictions" is valid but must be explicit.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 23:03):

I'm not sure how much my personal opinion on the issue matters, but just so you know where I stand at the moment: I definitely agree with the "weak objection" stance that FFI mechanisms shouldn't implicitly disable well-defined parts of an ABI; I am currently on the fence with regard to the "strong objection" that e.g. extern "C nounwind" is illegitimate.

view this post on Zulip centril (Nov 14 2019 at 23:04):

That much was clear ^^

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 23:05):

Anyway, the third consideration is that any well-defined part of an ABI is a means of translating program semantics into program behavior. C++ uses exceptions in this way, and somewhere between "most" and "all" ABIs consider this mechanism well-defined.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 23:07):

So, suppressing that feature of the ABI potentially changes the semantics of functions called via FFI, in a way that is both silent (e.g. you wouldn't get a warning at compile time or anything like that) and non-enforceable (i.e. the ABI exposed by C++ has no way of indicating whether or not an exception might be thrown).

view this post on Zulip centril (Nov 14 2019 at 23:09):

I'll head off to bed but please do continue your points

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 23:10):

Fair enough. I think that's all I have.

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 23:10):

So to summarize (mostly for future reference when I'm writing up a summary later), the objections to "protecting the user from well-defined parts of the ABI" are:

view this post on Zulip BatmanAoD (Kyle Strand) (Nov 14 2019 at 23:10):

Thanks for the discussion!


Last updated: Jan 26 2022 at 08:34 UTC