What happened to “we don't break the userspace” idea?

Posted Mar 4, 2025 1:01 UTC (Tue) by WolfWings (subscriber, #56790)
In reply to: What happened to “we don't break the userspace” idea? by khim
Parent article: Guard pages for file-backed memory

I mean... Linux "breaks" userspace when it's acting like a virus or malware, and the way many banking apps behave is very much crossing that line up to and including coming into direct conflict with the sandboxing Android itself attempts to enforce in newer versions at times so suddenly "Please use your browser if you have an Android XYZ device or newer." pops up or the app just silently throws a browser view up instead for you.

There's quite a few that won't even load if you have Developer mode enabled on Android, doesn't matter if you're using it just to keep the screen on, or to override bluetooth versions to work with an older car radio, they just straight refuse to load.

What happened to “we don't break the userspace” idea?

Posted Mar 4, 2025 3:50 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (3 responses)

Well, it's used as well for debugging, or by applications trying to perform introspection in back traces etc.

We're still missing a portable way to attempt a safe kernel-assisted memory copy from one area to another that would simply return EFAULT when either area is not accessible. I'm using some hacks using syscalls when I need to do that but that's ugly. I suspect one could also use vmsplice() to move the data into a pipe then from it, though I have not tried.

What happened to “we don't break the userspace” idea?

Posted Mar 4, 2025 8:41 UTC (Tue) by fw (subscriber, #26023) [Link]

Ideally, there would be routines in the vDSO we could use, and the kernel would just hide the faults (like it does in kernel space). Using process_vm_readv as a memcpy replacement seems a bit over the top.

What happened to “we don't break the userspace” idea?

Posted Mar 4, 2025 9:38 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

> I'm using some hacks using syscalls when I need to do that but that's ugly.

Well… using write for read looks a fit… quaint, but works well, in practice.

> We're still missing a portable way to attempt a safe kernel-assisted memory copy from one area to another that would simply return EFAULT when either area is not accessible.

pipe, then fork with one side reading with write syscall (specify memory argument that you want to look into as buffer, pipe as target, kernel will return EFAULT if memory can not be read) and the other getting information from pipe… this trick is decades old and portable (even if I'm not sure how portable, but it certainly works fine with very old versions of Linux), but don't see why would it stop working… because of fork ?

What happened to “we don't break the userspace” idea?

Posted Mar 5, 2025 4:36 UTC (Wed) by wtarreau (subscriber, #51152) [Link]

I totally agree, that's just what I mean by "ugly". Having to use a pipe + its 2 FDs + the double-copy. We could imagine having either mprotect(PROT_CHECK|PROT_READ) that would only return whether or not PROT_READ is present on all the area, or madvise(MADV_ZEROFILL) which would indicate that if not mapped, the area behaves as /dev/zero, or for threaded environments where this would not be safe, just a single syscall to perform a memcpy().