Am Dienstag, 8. Dezember 2020, 10:58:13 CET schrieb Michal Kubecek:
On Tue, Dec 08, 2020 at 10:20:42AM +0100, Hans-Peter
> 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
> 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
Unfortunately, it is playing games with set_fs(KERNEL_DS):
Somebody provided fixes for 5.10, that doesn't make sense in my uneducated
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.