Jann Horn

I wonder how many tech workers who speak English as a second language actually dogfood their company's stuff in their native language. I have most stuff on my devices configured to have english UI (except stuff like public transport apps which are probably primarily developed with german UI)

@madcoder@infosec.exchange agreed, there is a big set of system call errors that should be sending a fatal signal or such instead of returning an error code...

@madcoder@infosec.exchange Linux implements dup() as "first look up the file object from the file descriptor, then install the file object into a new file descriptor" as two separate steps with no locks held in between: SYSCALL_DEFINE1(dup, unsigned int, fildes) { int ret = -EBADF; struct file *file = fget_raw(fildes); if (file) { ret = get_unused_fd_flags(0); if (ret >= 0) fd_install(ret, file); else fput(file); } return ret; } And unlike what IIRC XNU does, Linux generally does not prevent you from closing a file descriptor while another syscall is operating on a file object that was looked up from that descriptor. So you could, for example, start a blocking read() on a pipe on one thread, and then let another thread close() the pipe's FD while the read() is still pending. I think Linux takes the position that if userspace decides to close() a file descriptor while another thread is operating on that file descriptor, userspace is being silly and shouldn't expect anything good to happen.

The Linux kernel "every subsystem has its own git tree" thing is so annoying. Especially when one file is plausibly associated with multiple subsystems and patches get routed through more than one. I guess it probably works reasonably well for people who only ever touch stuff in the one subsystem they specialize in, but for anything else...

@alexanderkjall@mastodon.social I mean... it is normal that, as a security researcher, when you find a security bug, you contact the upstream vendor, and can expect that to result in the issue being handled appropriately (for example, because the project notifies their downstreams about the issue, or because downstreams generally pick up all patches fast, or because propagation of fixes is ensured through a mechanism like CVEs). To my knowledge, there is no such mechanism between Linux and most distros, unless the distro just always ships the latest stable kernel; I think that is a process issue, not the security researcher's fault. When I report Linux kernel security bugs, I, too, just send the bug report to security@kernel.org and the maintainers, not to the third-party linux-distros list.

@ljrk@todon.eu Yeah, stack overflows in particular feel to me like the programmer isn't really making a particular mistake that can be called a security bug, it just randomly happens in legitimate code... and the only thing that can reliably stop it is the compiler. So it kinda feels wrong to me to call it a hardening flag, it feels more like a... correctness flag?

@brauner@mastodon.social the trigger for me writing this post was that I wrote a cleanup patch on top of a subsystem's -next tree, sent it, then was informed that a similar patch has already been sitting in another subsystem tree for weeks...

@ljs i think that already exists: keybase?

@Codeberg@social.anoxinon.de what are they hitting that's so kernel-intensive, is this filesystem stuff or process executions or something?

@ljs@mastodonapp.uk or in other words, if you're building large software on a beefy workstation, GNU LD is the wrong tool. this is what a typical kernel build on a workstation looks like with GNU LD:

@madcoder@infosec.exchange On Linux, file descriptors directly refer to file objects, without the fileproc indirection that XNU has from what I remember; so ensuring that a reference is held on the file object is enough for almost everything to work fine. (There are just some small weird corners of the kernel where that causes complications, in particular one of the flavors of advisory file locks, where file locks are normally cleared when file descriptor table entries are removed but you can end up with file locks being created after no more file descriptor table entries for the file exist...)

there is a recipe website with a "baking mode" toggle that uses the Screen Wake Lock API so the screen doesn't turn off while you have dough all over your hands and that just feels like such a nice little detail

Fun Linux fact: On a Linux system where /tmp/ is tmpfs, if you create the following directories: /tmp/pathwalktest/tmp/pathwalktest/a/tmp/pathwalktest/a/b/tmp/pathwalktest/c and call rename("/tmp/pathwalktest/a/b", "/tmp/pathwalktest/b") then a concurrent open("/tmp/pathwalktest/a/b/../c", O_RDONLY) normally won't end up opening /tmp/pathwalktest/c. But a concurrent open("/proc/self/root/tmp/pathwalktest/a/b/../c", O_RDONLY) can end up doing that with a simple ABA race ordering. (This is all working as intended, this is just a difference between rcu-walk and ref-walk; going through procfs magiclinks forces ref-walk mode.)

Fun Linux fact: If you race dup(5) and close(5), the kernel handles that fine, but it can lead to the unusual result that dup(5) returns 5.

The combination of Linux stable backports and not having explicitly documented and enforced API contracts is so annoying. Write a bugfix that uses an existing helper function that can return error type A. Your bugfix gets backported to an old kernel. Surprise, in the old kernel, the helper function can also return error type B. And suddenly your bugfix causes more breakage.

@axboe@fosstodon.org I've seen people wanting to use io_uring for bulk data transfer and I'm wondering - is my understanding correct that io_uring is mainly useful for usecases with concurrency, or cases where syscall batching helps? While if you're just trying to shovel a large amount of data from one FD to another FD, sendfile() should do the job?

fun Linux fact: Using epoll, you can see from userspace when the in-kernel garbage collector for unix domain sockets is cleaning up unreachable reference loops formed by SCM_RIGHTS. epoll essentially holds weak pointers on watched files (no refcounted reference, instead epoll gets a hook call when the refcount drops to 0); and /proc/self/fdinfo/{epoll fd} shows which files are currently watched by epoll, with files automatically disappearing when their refcount drops to 0.

I think it would be nice to have an OS that is centered around the idea of "everything that could possibly be a cache is a cache". Which I guess is sort of a functional programming idea? The pixels of your GUI: Cached result of running the immediate-GUI-rendering application code on the application state. The pixels of an image in the GUI: Cached result of PNG-decoding a PNG image, which is cached from an image on disk or elsewhere. Text written into a text input field: Writeback-cached. The position of a scrollbar: Writeback-cached. Podcast audio: Cached result of running the decoder on an encoded media file which is a cache backed by discardable fast on-disk cache and slow remote internet media. Stack memory: Discardable when the task is idle and waiting for events at top-of-stack. This might allow the OS to make better memory management decisions (about when and what to page in/out, and about whether data should be paged out or discarded), allow the OS to manage disk space more automatically, make it more feasible to have lots of background processes (because discarding all their caches makes them cheap), and maybe even make development iterations and updates easier (as long as an update doesn't modify persistent data structures).

@jannic@hachyderm.io that MSPLIM thing you linked to seems to be specific to Cortex-M chips, probably for when you don't have an MMU? When you have an MMU, I imagine explicit stack pointer limit checks probably cause unnecessary hardware overhead compared to relying on implicit bounding by guard pages?

@siguza@infosec.space if it takes 35s to spin up... stupid question, is the thing getting enough power? FWIW, wireshark can show USB traffic, and the wiki claims that USB capture also works on macOS if SIP is off or something like that...

@cjwatson@mastodon.ie @adamshostack@infosec.exchange it looks like the old install flow still had the delay when the new "doorhanger" install UI was added in https://github.com/mozilla-firefox/firefox/commit/0332e04351bf81bbe6e0fb5d4b528b94296adc2c , and the new UI, from the start, seems to have code that tries to use the delay config but doesn't really have an effect that I can notice... https://bugzilla.mozilla.org/show_bug.cgi?id=1139656 has discussion on the implementation of the new doorhanger UI and how it should apply a delay

@ljs@mastodonapp.uk which linker are you using (GNU LD or gold or LLVM's LLD?), and is this an incremental build or a full build with all the config options? a large part of the kernel build is "link the whole kernel, repeatedly, because kallsyms is a big hack", and if you do that with GNU LD, it's gonna be single-threaded and take a long time, so a client-style CPU will have an advantage over a workstation-style CPU...

@Codeberg@social.anoxinon.de huh, that's a pretty kernel-heavy workload, so much red

@freddy@social.security.plumbing huh. as in, there is insufficient guidance from the feature devs on the semantics of a string and so you disagree with other native german speakers on the correct translation even when seeing it in context?

@fugueish@wandering.shop I would say that seems like a step too far but I guess that's kinda how the web works...