Page MenuHomeFreeBSD

linux: make ptrace(2) return EIO when trying to peek invalid address
ClosedPublic

Authored by trasz on Apr 22 2021, 2:20 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 17 2024, 12:13 AM
Unknown Object (File)
Feb 14 2024, 4:30 AM
Unknown Object (File)
Feb 5 2024, 10:57 PM
Unknown Object (File)
Dec 23 2023, 12:26 AM
Unknown Object (File)
Dec 2 2023, 11:45 PM
Unknown Object (File)
Oct 3 2023, 12:22 PM
Unknown Object (File)
Sep 28 2023, 2:55 AM
Unknown Object (File)
Sep 21 2023, 5:30 AM

Details

Summary

Previously we've returned the error from native ptrace(2), ENOMEM.
This confused Linux strace(2).

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

trasz requested review of this revision.Apr 22 2021, 2:20 PM

Btw, the ENOMEM return is not documented in the ptrace(2) man page. I wonder what's the better way: updating the man page, or changing the return?

Indeed to me EIO seems a better error for this case than ENOMEM, although I am not sure if anything depends on the current value. @markj @jhb ?

Indeed to me EIO seems a better error for this case than ENOMEM, although I am not sure if anything depends on the current value. @markj @jhb ?

I'm not sure. At some point PT_READ_I could return either EFAULT or ENOMEM depending on how the fault failed, but I squashed that to just ENOMEM in some refactoring years ago. EFAULT would have made more sense in retrospect.

I would be inclined to leave native ptrace alone and just do the translation here. Perhaps proactively squash EFAULT to EIO as well.

I agree with Mark. I think EFAULT is perhaps the better error code for the native case.

Mmmm, yeah EFAULT seems best.

Either way, it's not EIO, so perhaps let's get this one committed, and then I'll follow up with the native stuff.

Fine with me, but I agree with @markj that making it error == ENOMEM || error == EFAULT already seems like a decent idea.

This revision is now accepted and ready to land.Apr 23 2021, 3:05 PM

TBH I'm not a fan of adding code "just in case", except for assertions; to me, it makes reasoning about the code harder.