Page MenuHomeFreeBSD

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

Authored by dchagin on Jul 22 2021, 2:44 PM.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

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).

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.

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.

In D31279#704382, @kib 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.

In D31279#704382, @kib 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

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.

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.

In D31279#704422, @kib 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

This revision was not accepted when it landed; it landed in state Needs Review.Jul 29 2021, 9:59 AM
This revision was automatically updated to reflect the committed changes.