Am Dienstag, 8. Dezember 2020, 10:58:13 CET schrieb Michal Kubecek:
On Tue, Dec 08, 2020 at 10:20:42AM +0100, Hans-Peter Jansen wrote:
Am Montag, 7. Dezember 2020, 17:07:29 CET schrieb Hans-Peter Jansen:
Any idea, how the equivalent of the "uPtrFrom >= USER_DS.seg" term should look like today?
Takashi && Michal, thanks for your help.
Based on what USER_DS used to be defined as, TASK_SIZE_MAX should be a direct replacement. But maybe you rather want something like copy_from_kernel_nofault_allowed(uPtrFrom), it's hard to say without knowledge of what the code is used for.
This function is accompanied with a comment: /** * Catches kernel_read() and kernel_write() calls and works around them. * * The file_operations::read and file_operations::write callbacks supposedly * hands us the user buffers to read into and write out of. To allow the kernel * to read and write without allocating buffers in userland, they kernel_read() * and kernel_write() increases the user space address limit before calling us * so that copyin/copyout won't reject it. Our problem is that get_user_pages() * works on the userspace address space structures and will not be fooled by an * increased addr_limit. * * This code tries to detect this situation and fake get_user_lock() for the * kernel buffer. */ Good news, the code compiles at least. Sorry to bother you even more, but I see a related issue in lime_kmp, the Linux Memory Extractor https://github.com/504ensicsLabs/LiME, that is able to produce memory dumps in a more forensically sound way then other such tools. Unfortunately, it is playing games with set_fs(KERNEL_DS): https://build.opensuse.org/package/live_build_log/home:frispete:kernel:HEAD/... Somebody provided fixes for 5.10, that doesn't make sense in my uneducated eyes: https://github.com/504ensicsLabs/LiME/pull/83/files If I understand the code correctly, it tries to trick the kernel into believing, that all calls stems from the kernel. This reveals the questions, what advantage that procedure buys us, and at what costs (risks)? Most probably, this set_fs dance can be eliminated, or replaced with something, our kernel adepts correspond to. Ideas, opinions? Pete