Skip to content
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

Implement KRF_SAFE_WRITE for FreeBSD #24

Open
woodruffw opened this issue Jun 17, 2019 · 5 comments
Open

Implement KRF_SAFE_WRITE for FreeBSD #24

woodruffw opened this issue Jun 17, 2019 · 5 comments
Assignees

Comments

@woodruffw
Copy link
Member

KRF_SAFE_WRITE is currently a no-op on FreeBSD:

#define KRF_SAFE_WRITE(x) x // ???

We should check whether FreeBSD provides cr0 manipulation functions/macros. If it doesn't, then we should add our own like the ones used in this blog post (under "Disabling CPU write protection").

ccing @roachspray as a source of expertise about write protection/safe locking in FreeBSD.

@hmwildermuth
Copy link
Contributor

Do we need cr0 manipulation at all? The writes to the sysent table are succeeding without complaint as of now.

@woodruffw
Copy link
Member Author

Yeah, I'm not actually certain why it's succeeding.

cpu_setregs should be setting WP on CPU init:

https://github.com/freebsd/freebsd/blob/fd1567d78195bddf8e366a191198eabd11bd7563/sys/amd64/amd64/machdep.c#L655

In any case, it doesn't actually hurt us to add it. But let's deprioritize it for now.

@woodruffw
Copy link
Member Author

This might be related to securelevel:

sysctl -n kern.securelevel
-1

We should find out what other values are supported and whether any of them prevent modification of kernel memory. The page linked above says that at least one level blocks /dev/kmem, but it doesn't say anything about direct access.

@hmwildermuth
Copy link
Contributor

I attempted running the module with kern.securelevel=1, and there were no issues with writing to the sysent table. Functionality was completely normal, no errors came up in dmesg and the program successfully faulted a target.
I doubt that higher values of securelevel would behave differently because according to FreeBSD documentation they add very specific checks and balances.

@woodruffw
Copy link
Member Author

Yeah, makes sense. We can table this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants