Is rustc guaranteed to reject code which "turns a pointer into raw bytes" in const code?

[joshlf]

In google/zerocopy#171 (comment), we're adding the ability to safely convert between byte slices/arrays and raw pointers. Currently, we have a test that is successfully failing if we try to perform this operation in a const context. What I want to know is: Is it guaranteed that code that performs any such conversion in a const context will always be rejected, or is this a best-effort analysis? If it's the former, then we can soundly emit the trait impls proposed in that PR, but if not, those impls would be unsound.

[Lokathor]

I have been cautioned before about treating pointers as "just funny integers", because actual integers don't carry provenance. I have been told that the most likely path for Rust will eventually involve any plain transmutation of integer data to pointer data will end up producing an invalid pointer.

I don't want to overstate things, I don't think this is a settled matter, but I suspect these impls would be ill advised to add right now, even if they're only used at runtime.

[thomcc]

I think you've misinterpreted the question (or at least I don't see the connection). They're asking if they can rely on a const-eval failure here, which I believe the answer from the const_ub RFC is no, that we don't guarantee const evaluation to fail for UB. It's possible that this case could be strengthened though, but it might require lang decision.

[digama0]

The docs on these types didn't make it clear whether they are expected to be round-tripping, maybe it was assumed that this is the case? As far as I know, both FromBytes and AsBytes are (separately) legal for pointers, in the sense that you can safely convert a pointer to a byte sequence (which I guess means [u8; N]?) and you can safely convert any byte sequence to a pointer value. However, the roundtrip is not lossless, and the resulting pointers cannot be dereferenced unless you have previously exposed the affected pointers beforehand.

@thomcc I think this is relevant not for the question that was asked but the claim that "If it's the former, then we can soundly emit the trait impls proposed in that PR, but if not, those impls would be unsound", because I'm not sure whether it would be sound even in the former case. Or at least, the impls are sound but foot-gunny, since most code that would use the impls is not sound (although one would have to write additional downstream unsafe to use the pointers).

[joshlf]

Yeah so my question is roughly: "As we all know, it is sound to convert [u8; N] to a raw pointer and vice-versa at runtime. We also know that it is unsound to do either at const eval time, and that sometimes, if you try doing such a conversion at const eval time, the compiler will catch it and emit an error. Is it guaranteed that the compiler will always catch such a conversion?"

IIUC, @Lokathor is questioning the premise of the question and pointing out that it may not even be sound to do a pointer-to-bytes or bytes-to-pointer conversion at runtime, let alone at const eval time.

IIUC, @thomcc is saying that there is no guarantee that the compiler will catch this mistake at const eval time.

IIUC, @digama0 is saying that while it might be sound to do a pointer-to bytes or bytes-to-pointer conversion at runtime in the general case, it would only be sound to actually dereference such a pointer under certain cases. As a result, even if the trait impls I'm proposing are technically sound, they likely constitute a footgun.

Do I understand everyone's points correctly?

[digama0]

At const eval time, I don't think there is any danger of immediate UB, although there is certainly the danger of a compile failure. The compiler is allowed to evaluate ptr-to-int conversions, it just can't in most cases. In particular, if the pointer is a ptr::invalid(N), you may well be able to evaluate a ptr-to-int conversion to get N back.

[joshlf]

At const eval time, I don't think there is any danger of immediate UB, although there is certainly the danger of a compile failure. The compiler is allowed to evaluate ptr-to-int conversions, it just can't in most cases. In particular, if the pointer is a ptr::invalid(N), you may well be able to evaluate a ptr-to-int conversion to get N back.

Okay so if I'm reading this correctly, then we could be in one of two possible situations. Is that right?

Situation 1: Any pointer-to-int or int-to-pointer conversion is valid (although of course dereferencing such a pointer might be invalid). If this is the case, then any such conversion at const eval time is either unsupported (const eval will fail) or is a sound operation at const eval time. There's no possibility to introduce UB at const eval time just by enabling such a conversion.

Situation 2: Some pointer-to-int or int-to-pointer conversions are unsound/instant UB. If this is the case, then performing such a conversion is UB at both runtime and const eval time.

My take-away from this is that either we're in Situation 1, and zerocopy can support these conversions without worrying about it having different soundness at runtime vs const eval time, or we're in Sitaution 2, and it would be unsound for zerocopy to support these conversions at all, even at runtime.

[digama0]

AFAIK we have not gone through the relevant stabilization process to determine what the situation is, but I would put a good probability on situation 1. I don't know any in flight proposals that would require making ptr-to-int or int-to-ptr conversions immediate UB (except for some early versions of the strict provenance model).

[saethlin]

Unless I have misunderstood the motivating context of this question, I think this has become sidetracked into a question about UB and the validity or semantics of pointer-integer conversions. I don't see any question about UB in the original question, and all I see in motivation is a concern about people using these APIs to I guess smuggle a pointer through a usize. I don't understand why specifically const eval detecting this is a great help... But anyway.

I am not sure this is a Rust semantics question or a question about UB detection in const eval.

All that being said, I also do not think that we guarantee this const evaluation error. I would certainly not rely on it for soundness. But in the current interpreter implementation, I would not classify this detection as "best-effort". For sure the UB detection is best-effort, but this is not the same.

[saethlin]

Also cc @oli-obk (since this is an interpreter question and by asking a question on this repo you have already summoned the rest of the Miri team)

[joshlf]

I think that the implicit (and maybe wrong) assumption in my original question has to do with this error that was encountered while testing the PR:

error[E0080]: evaluation of constant value failed
  --> tests/ui/transmute-illegal.rs:10:1
   |
10 | const POINTER_VALUE: usize = zerocopy::transmute!(&0usize as *const usize);
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^ unable to turn pointer into raw bytes
   |
   = help: this code performed an operation that depends on the underlying bytes representing a pointer
   = help: the absolute address of a pointer is not known at compile-time, so such operations are not supported

I assumed that this error represented the compiler complaining about UB, and so if the compiler were to fail to generate an error for this case or a similar one, it would mean UB slipping by. From the discussion, however, it seems like maybe the error doesn't represent UB, but just represents the compiler saying "hey, I can't do that at const eval time", and if the error were to go away, it would just mean that the compiler can now do a new thing, so all is fine.

If it's the former case, then it would be unsound for zerocopy to produce an API (namely the FromBytes and AsBytes traits) that allow users to safely perform an operation that could introduce UB during const eval. If it's the latter case, then there's no issue.

[saethlin]

Yeah, thanks for substantiating my guess.

At const eval time, a pointer is not an address. It is an allocation ID and an offset into the allocation. Allocations don't have a base address, memory is just a HashMap<AllocId, Allocation>. I think the implementation currently insists on not giving allocations a base address (as opposed to Miri which bolts on extra runtime state to invent base addresses for allocations) in order to prevent implementation details of how the addresses would be selected from leaking into the const value. But the other interpreter experts would have to check me on that.

[bjorn3]

For const eval we can't expose any addresses as those won't be known until the dynamic linker has loaded the program. Instead we have to keep pointers symbolic values whose real value gets filled in by the dynamic linker through relocations. These relocations can only represent a very limited set of values, so we currently don't allow any operations on the address of pointers other than pointer offsets to ensure they stay representable.

[oli-obk]

There could be a theoretical const evaluator implementation that preserves provenance in ptr2int casts, and thus makes your program compile and allow round tripping with int2ptr at compile and run-time.

If (and that's a very unlikely if) we get that, then yes, it will be sound to use. So either you get this error due to an architectural limitation of the current implementation, or your code suddenly starts compiling correctly after a rustc update.

I would recommend not making your conversion function const. I'm assuming you can't use https://doc.rust-lang.org/std/primitive.pointer.html#method.expose_addr anywhere due to the zero copy nature of the thing? Could you use MaybeUninit<u8> or a similar union of your own definition instead of u8?