[release/5.0] Fix usage of process_vm_readv in createdump

[hoyosjs]

Description

This PR tries to use process_vm_readv and falls back to using pread on /proc/mem if the first fails with EPERM. This is needed as docker 19.03 on kernels newer than 4.8 allows to use ptrace as long as yama settings don't restrict it, but it does not allow usage of process_vm_* syscalls. These were added very recently to the allow-list but we need a mechanism to allow customers to collect dumps in their containerized environments.

Customer Impact

Customers are forced to use CAP_SYS_PTRACE to be able to collect dumps in their linux containers running on docker (both per request and crash dumps). This is not recommended as an arbitrary process from the same user context could be inspected. A couple of internal and external customers have already voiced their interest in this change.

Regression

Yes, customers were able to collect dumps in containers without needing PTRACE for most scenarios without needing to add the capability to the containers. This changed as the syscall used was changed in the 5.0 timeframe.

Testing

Manual testing performed to validate fallback with the syscall enabled and disabled as well as with and without CAP_SYS_PTRACE to ensure all code paths were used.

Risk

Minimal, dump time only with the old behavior being preserved as the first option.

Fixes dotnet/diagnostics#2098 on release/5.0
PR for main: #50477

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

This PR tries to use process_vm_readv and falls back to using pread on /proc/mem if the first fails with EPERM. This is needed as docker 19.03 on kernels newer than 4.8 allows to use ptrace as long as yama settings don't restrict it, but it does not allow usage of process_vm_* syscalls. These were added very recently to the allow-list but we need a mechanism to allow customers to collect dumps in their containerized environments.

Customer Impact

Customers are forced to use CAP_SYS_PTRACE to be able to collect dumps in their linux containers running on docker (both per request and crash dumps). This is not recommended as an arbitrary process from the same user context could be inspected.

Regression

Yes, customers were able to collect dumps in containers without needing PTRACE for most scenarios without needing to add the capability to the containers. This changed as the syscall used was changed in the 5.0 timeframe.

Testing

Manual testing performed to validate fallback with the syscall enabled and disabled as well as with and without CAP_SYS_PTRACE to ensure all code paths were used.

Risk

Minimal, dump time only with the old behavior being preserved as the first option.

Fixes dotnet/diagnostics#2098 on release/5.0

Author:	hoyosjs
Assignees:	hoyosjs
Labels:	area-Diagnostics-coreclr
Milestone:	5.0.x

[jeffschwMSFT]

Approved. We will take for consideration in 5.0.x