linux(4): Futex address must be 32-bit aligned.

[kib]

But why is this check needed? We do not do similar checks in kern_umtx.c.

IMO MD casueword/fuword/suword interfaces must handle this case, e.g. returning EFAULT if unaligned userspace address is not acceptable (or silently do whatever is needed).

[markj]

In D31279#704348, @kib wrote:

But why is this check needed? We do not do similar checks in kern_umtx.c.

IMO MD casueword/fuword/suword interfaces must handle this case, e.g. returning EFAULT if unaligned userspace address is not acceptable (or silently do whatever is needed).

Hmm, for some reason I thought that umtx checks this. When are unaligned addresses ever acceptable? I don't see how e.g., fuword can silently handle unaligned addresses.

[kib]

In D31279#704379, @markj wrote:

In D31279#704348, @kib wrote:

But why is this check needed? We do not do similar checks in kern_umtx.c.

IMO MD casueword/fuword/suword interfaces must handle this case, e.g. returning EFAULT if unaligned userspace address is not acceptable (or silently do whatever is needed).

Hmm, for some reason I thought that umtx checks this. When are unaligned addresses ever acceptable? I don't see how e.g., fuword can silently handle unaligned addresses.

I am not sure what do you mean. If fuword causes unaligned exception on some architectures, then pcb_onfault handler can notice this and do whatever is needed to emulate the access.

[markj]

In D31279#704382, @kib wrote:

In D31279#704379, @markj wrote:

In D31279#704348, @kib wrote:

But why is this check needed? We do not do similar checks in kern_umtx.c.

IMO MD casueword/fuword/suword interfaces must handle this case, e.g. returning EFAULT if unaligned userspace address is not acceptable (or silently do whatever is needed).

Hmm, for some reason I thought that umtx checks this. When are unaligned addresses ever acceptable? I don't see how e.g., fuword can silently handle unaligned addresses.

I am not sure what do you mean. If fuword causes unaligned exception on some architectures, then pcb_onfault handler can notice this and do whatever is needed to emulate the access.

Ok, I see. So according to your suggestion, amd64 fuword should fall back to a lock-prefixed instruction if it detects that the operand is unaligned.

I note though that the futex documentation explicitly states that EINVAL is returned if the object is not 4 byte-aligned, so I suspect that this change is still preferable for compatibility reasons.

[dchagin]

In D31279#704398, @markj wrote:

In D31279#704382, @kib wrote:

In D31279#704379, @markj wrote:

In D31279#704348, @kib wrote:

But why is this check needed? We do not do similar checks in kern_umtx.c.

IMO MD casueword/fuword/suword interfaces must handle this case, e.g. returning EFAULT if unaligned userspace address is not acceptable (or silently do whatever is needed).

Hmm, for some reason I thought that umtx checks this. When are unaligned addresses ever acceptable? I don't see how e.g., fuword can silently handle unaligned addresses.

I am not sure what do you mean. If fuword causes unaligned exception on some architectures, then pcb_onfault handler can notice this and do whatever is needed to emulate the access.

Ok, I see. So according to your suggestion, amd64 fuword should fall back to a lock-prefixed instruction if it detects that the operand is unaligned.

I note though that the futex documentation explicitly states that EINVAL is returned if the object is not 4 byte-aligned, so I suspect that this change is still preferable for compatibility reasons.

yes, I understand too, and alredy did a new patch. but handle_futex_deth does not return to user space, so we need check that futex right aligned before umtx_key_get. thanks for point

[dchagin]

Linux futex documentation explicitly states that EINVAL is returned if
the futex is not 4-byte aligned. Check futex alignment as a Linux do
and return EINVAL.

[kib]

In D31279#704398, @markj wrote:

Ok, I see. So according to your suggestion, amd64 fuword should fall back to a lock-prefixed instruction if it detects that the operand is unaligned.

I do not think so. As far as kernel does not melt under unaligned access, it should be fine. The fact that fuword/suword are not atomic on perfectly unaligned addresses only breaks userspace that is already broken by requesting umtx op on such address.

For other arches, where unaligned access might need some assistance, it is fine to either return an error or to emulate it. pcb_onfault is the most obvious approach. But fuword(9) family must tolerate arbitrary representable addresses, by any means. There should be no need in pre-checks to safely use them.

[markj]

In D31279#704422, @kib wrote:

In D31279#704398, @markj wrote:

Ok, I see. So according to your suggestion, amd64 fuword should fall back to a lock-prefixed instruction if it detects that the operand is unaligned.

I do not think so. As far as kernel does not melt under unaligned access, it should be fine. The fact that fuword/suword are not atomic on perfectly unaligned addresses only breaks userspace that is already broken by requesting umtx op on such address.

For other arches, where unaligned access might need some assistance, it is fine to either return an error or to emulate it. pcb_onfault is the most obvious approach. But fuword(9) family must tolerate arbitrary representable addresses, by any means. There should be no need in pre-checks to safely use them.

I certainly agree that they must somehow tolerate unaligned addresses. I was just confused about the atomicity guarantees of the interface: https://reviews.freebsd.org/D31282