Stream: t-lang/wg-unsafe-code-guidelines

Topic: VaList


dlrobertson (Jan 22 2019 at 15:26, on Zulip):

I'm working on implementing C variadics in Rust (RFC 2137) which are SUPER unsafe (CWE-134 and CWE-234). Is there anything I should do related to this WG? Are C variadics and VaList worth a active discussion topic?

dlrobertson (Jan 22 2019 at 15:27, on Zulip):

I kind of get the feeling that va_list in Rust will kind of be a niche thing, so I'm a little uncertain that it is worth the energy

dlrobertson (Jan 22 2019 at 15:29, on Zulip):

But I'd also really hate for the unsafety of it to go undocumented

dlrobertson (Jan 22 2019 at 15:32, on Zulip):

If it is something worth discussing, just ping me. I'd be happy to dump my current research/thoughts in an issue/PR

RalfJ (Jan 22 2019 at 15:32, on Zulip):

the goal of UCG is not to document all unsafety, libraries can and will continue to add their own

RalfJ (Jan 22 2019 at 15:33, on Zulip):

but in general interaction with platform-specific "stuff" is in scope here

RalfJ (Jan 22 2019 at 15:34, on Zulip):

for VaList I guess the main question is whether there are far-reaching consequences or whether it's "just" a lot of local complexity when actually writing a vaarg fn

RalfJ (Jan 22 2019 at 15:36, on Zulip):

feel free to open an issue at https://github.com/rust-rfcs/unsafe-code-guidelines/issues -- this does sound like something that people will be asking about eventually^^

dlrobertson (Jan 22 2019 at 15:38, on Zulip):

The gist of the unsafty is that there is no guarantee that the caller has input the same type or number of args as the callee expects, so depending on how it is used there can be far reaching consequences a la string formatter vulns

dlrobertson (Jan 22 2019 at 15:41, on Zulip):

:+1: I'll try to collect some stuff and post it. If after reading it, it seems to be outside fo the scope of this WG feel free to close it

dlrobertson (Jan 22 2019 at 15:42, on Zulip):

IMO there are probably more important areas to focus on first e.g. unions

RalfJ (Jan 22 2019 at 15:50, on Zulip):

The gist of the unsafty is that there is no guarantee that the caller has input the same type or number of args as the callee expects, so depending on how it is used there can be far reaching consequences a la string formatter vulns

that's not what I meant by far-reaching. I meant things like memory-mapped I/O, which might have consequences in general discussions about references -- things with a "global effect". of course any local unsafety can "become" global if something goes wrong when forwarding the safety obligations.

RalfJ (Jan 22 2019 at 15:51, on Zulip):

string format vulns arise because printf is NOT a safe API, it would be an unsafe function in Rust with some obligations for the callers. that's still "local" in the sense that only the two sides of this unsafe contract have to care -- if one of them screws up, all is lost, but that's a separate issue (and trued pretty much all the time)

dlrobertson (Jan 22 2019 at 15:53, on Zulip):

that's not what I meant by far-reaching

Ah, sorry about that

RalfJ (Jan 22 2019 at 15:54, on Zulip):

no need to be sorry, I am probably making up my own vocabulary here ;)

dlrobertson (Jan 22 2019 at 15:55, on Zulip):

I think I see what you're getting at

RalfJ (Jan 22 2019 at 15:57, on Zulip):

setjmp/longjmp is also awfully far-reaching, to give another example

dlrobertson (Jan 22 2019 at 15:59, on Zulip):

Under that definition of local I don't see global consequences... AFAIK most the va_list vulns arise out of one side not adhering to the contract

dlrobertson (Jan 22 2019 at 16:01, on Zulip):

So the guidelines for va_list may be just "set clear rules and adhere to them"

RalfJ (Jan 22 2019 at 16:08, on Zulip):

yes

RalfJ (Jan 22 2019 at 16:08, on Zulip):

except "just" might be a misnomer here ;)

dlrobertson (Jan 22 2019 at 16:15, on Zulip):

Ha! true

gnzlbg (Jan 23 2019 at 09:16, on Zulip):

@dlrobertson feel free to open an issue but:

The gist of the unsafty is that there is no guarantee that the caller has input the same type or number of args as the callee expects

I don't see much difference between this, and writing an extern { } function that has a different signature from the C code (e.g. C expects a pointer and the Rust signature has a e.g. f32 ).

gnzlbg (Jan 23 2019 at 09:18, on Zulip):

Basically code that writes unsafe { extern_fn(....) } is claiming that the extern_fn signature is ok. When it comes to va_args it would just claim that the number and types of the arguments passed is also ok. If it isn't, then that code is at fault.

We have a lot of tools for verifying that claim.

Last update: Nov 19 2019 at 18:50UTC