New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

research process_vm_readv/process_vm_writev viability #476

Open
eteran opened this Issue Nov 23, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@eteran
Owner

eteran commented Nov 23, 2016

Since linux 3.2, there is a system call to read/write memory in a remote process directly. This may be a viable replacement for the file based and ptrace_peek/poke methods we are currently using. But I don't know if they would prove to be any better in practice.

Either way, this is something probably worth looking into.

@eteran eteran added the enhancement label Nov 23, 2016

@10110111

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Nov 23, 2016

Contributor

This is a third way to support, until we're ready to ditch support for Linux<3.2. Looks like an opportunity for lots of bugs.

Contributor

10110111 commented Nov 23, 2016

This is a third way to support, until we're ready to ditch support for Linux<3.2. Looks like an opportunity for lots of bugs.

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Nov 23, 2016

Owner

Agreed. I've had this API on my radar for a while, but when it was first introduced, it was downright broken on my machine. So I long abandoned it. Though recent tests look promising on my 4.8.10 kernel :-).

This issue is more of a "bookkeeping" thing, I didn't want to forget about it in case we want to consider it in the future.

Owner

eteran commented Nov 23, 2016

Agreed. I've had this API on my radar for a while, but when it was first introduced, it was downright broken on my machine. So I long abandoned it. Though recent tests look promising on my 4.8.10 kernel :-).

This issue is more of a "bookkeeping" thing, I didn't want to forget about it in case we want to consider it in the future.

@AaronOpfer

This comment has been minimized.

Show comment
Hide comment
@AaronOpfer

AaronOpfer Nov 23, 2016

Contributor

I suppose the "best" way to handle all of these memory read/write methods would be to have one class for each method, and then have a manager that handles chaining them together in order of preference/availability. That should make it relatively easy to test and verify correctness since you can stub out each part. It would also let us quickly add more methods later (LD_PRELOAD, kernel module, dirtyc0w exploit, etc. 😏).

Contributor

AaronOpfer commented Nov 23, 2016

I suppose the "best" way to handle all of these memory read/write methods would be to have one class for each method, and then have a manager that handles chaining them together in order of preference/availability. That should make it relatively easy to test and verify correctness since you can stub out each part. It would also let us quickly add more methods later (LD_PRELOAD, kernel module, dirtyc0w exploit, etc. 😏).

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Dec 1, 2016

Owner

Just wanted to have this here for future reference. The following code appears to "work correctly" and is probably similar to what we would want if we decided to use this API in the future:

struct iovec local[1];
struct iovec remote[1];

local[0].iov_base  = buf;
local[0].iov_len   = len;
remote[0].iov_base = reinterpret_cast<void*>(address.toUint());
remote[0].iov_len  = len;

ssize_t nread = process_vm_readv(pid_, local, 1, remote, 1, 0);
if(nread == len) {
	return 1;
}
Owner

eteran commented Dec 1, 2016

Just wanted to have this here for future reference. The following code appears to "work correctly" and is probably similar to what we would want if we decided to use this API in the future:

struct iovec local[1];
struct iovec remote[1];

local[0].iov_base  = buf;
local[0].iov_len   = len;
remote[0].iov_base = reinterpret_cast<void*>(address.toUint());
remote[0].iov_len  = len;

ssize_t nread = process_vm_readv(pid_, local, 1, remote, 1, 0);
if(nread == len) {
	return 1;
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment