Fix implicit_provenance_casts warnings on Xous

[bjorn3]

No description provided.

[rustbot]

r? @clarfonthey

rustbot has assigned @clarfonthey.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 13 candidates
• Random selection from Darksonn, JohnTitor, Mark-Simulacrum, clarfonthey, jhpratt

[bjorn3]

cc @xobs

[xobs]

Thank you for addressing these.

[RalfJung]

The point of these warnings is to actually audit whether exposing is necessary or whether strict provenance could be used instead. Did you actually check this or just replace is everywhere?

[bjorn3]

For lend_mut_impl and lend_impl the kernel will read through the passed in pointer. It might be possible to directly pass the pointer to the as block instead. For map_memory the kernel will replace the memory allocation at the given address if there was one. And unmap_memory will deallocate the allocation. And finally create_thread will invoke the function pointer and use the passed in stack for the new thread.

In Thread::new, guard_page_pre and data are both read/deallocated by the thread_start. And tls_table_slow also need the pointer to be exposed for TLS accesses to be allowed.

[xobs]

The documentation isn't very clear. It seems that for strict provenance, you use .with_addr(), but to do that you already need to have a pointer.

The problem is that these addresses come from the kernel via a syscall, so they're just a bare usize when the functions return. What's the correct way to go from a syscall return value to a pointer without using .exposed_provenance()?

[RalfJung]

@xobs there is no exposed_provenance. There is expose_provenance which goes from a pointer to an integer, which is the opposite direction of what you are talking about. So I can't quite follow your question.

It seems that @bjorn3 is saying that the kernel APIs here are all designed such that they take integers when they actually should take pointers (i.e. this is about inputs to syscalls, not return values)? Yeah if APIs don't use pointer types properly then expose_provenance is what one has to do. Might be worth a few comments.

[clarfonthey]

There's with_exposed_provenance, but based upon what the docs say, it's not possible to start from exposed provenance, only return to it. But maybe this is the right choice for this kind of API.

I know that the provenance of external addresses is something that has been discussed a lot and not really resolved. From a libs perspective, the code looks okay (r=me), but I'm going to defer to opsem for review since it feels more important that this is semantically correct rather than just passing a lint.

r? RalfJung since you've already taken a look, but feel free to reroll if you'd rather not review.

[rustbot]

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

[RalfJung]

There's with_exposed_provenance, but based upon what the docs say, it's not possible to start from exposed provenance, only return to it. But maybe this is the right choice for this kind of API.

As long as they have been exposed "on the other side" of the FFI (which we can generally assume for cases like this), that's fine.

But this PR doesn't even call with_exposed_provenance.

[RalfJung]

@rustbot author
for more comments

[bjorn3]

I've removed all exposed_provenance calls in favor of passing raw pointers to the inline asm blocks. I think this is fine.

[RalfJung]

That makes a lot of sense to me conceptually, thanks!
However, I can't review changes of this sort...
@rustbot reroll
And @xobs if you could take another look at the latest version that'd be great.

[xobs]

This looks fine to me. It's neat how you can use asm to generate pointers like that -- I didn't realize that would work.

View changes since this review

[Darksonn]

Overall looks fine, but some comments.

@rustbot author

View changes since this review