Oh gosh, that's interesting. I bet that complicates using using errno. Or is errno somehow copied into a local variable?
errno is in thread-local storage (TLS)
Readit NewsVogtinator commented on What is going on in Unix with errno's limited nature utcc.utoronto.ca/~cks/spa... · Posted by u/ingve
Vogtinator commented on Android phone will run Debian Linux soon (like some Pixels can) zdnet.com/article/your-an... · Posted by u/amrrs
Nonsense - Android's userland does not use GNU, at all; or Linux display servers; or the POSIX standard; or anything but the kernel. Apps on Android have no access, or ability, to directly call kernel functions. Android is deliberately designed so the kernel could, hypothetically, even be replaced one day without breaking anything.
Forcing apps into an abstraction layer from the kernel is good design, preventing kernel quirks from being permanent features. Not using GNU is another design choice which can be debated, but it's completely valid, there's no requirement (moral or otherwise) to use the GNU userland with the Linux kernel. Most embedded devices also eschew the GNU userland by instead using Busybox.
> Apps on Android have no access, or ability, to directly call kernel functions.
That is nonsense.
Vogtinator commented on Bypassing disk encryption on systems with automatic TPM2 unlock oddlama.org/blog/bypassin... · Posted by u/arjvik
It's ridiculous that there's no software implementation to do this, it's a huge problem.
Auto update should be able to include the kernel, initrd and grub cmdline from the running system I have no idea what's holding this back since evidently code already exists somewhere to do exactly that.
That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).
Vogtinator commented on Bypassing disk encryption on systems with automatic TPM2 unlock oddlama.org/blog/bypassin... · Posted by u/arjvik
You can mitigate this by including PCRs that sign the kernel and initrd, however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros.
Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.
> You can mitigate this by including PCRs that sign the kernel and initrd.
No, that's not an effective mitigation. The signed kernel+initrd would still boot into the impersonated root.
> however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros. > Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.
With some logic to update the values on kernel updates and re-seal the secret this can be handled transparently. That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).
Vogtinator commented on /bin/sh: the biggest Unix security loophole (1984) [pdf] tuhs.org/Archive/Document... · Posted by u/vitplister
We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root. Users aren't sandboxed, so they can see what others are doing. These were just off the top of my head.
For multiple users on the same server it was IMO well designed. Everyone had their ~ and could place whatever libraries/binaries/etc. in there and do whatever they wanted.
Package managers are way more modern than that and their design does by itself not require root (see pip). You can in fact run most package managers without root, you just won't be able to modify system files. You can use them to install a chroot as regular user, e.g. `zypper --installroot ~/tw install bash`.
FUSE doesn't really relate to single vs. multi-user AFAICT.
Users are perfectly sandboxed if you configure the system that way. Depending on the distribution that's even the default.
Vogtinator commented on Execution units are often pipelined blog.xoria.org/pipelining... · Posted by u/ingve
For x86 cores this is visible in Agner Fog's instruction performance tables: https://agner.org/optimize/#manuals
The latency shows after how many cycles the result of an instruction can be consumed by another, while the throughput shows how many such instructions can be pipelined per cycle, i.e. in parallel.
Box64 does the x64 to ARM translation (while keeping performance as high as possible by calling native ARM library code wherever possible). Throw Wine in there to implement the Windows APIs and you can run amd64 PE binaries on aarch64 with decent performance.
You can't run amd64 without something like Box64 because Wine is not an emulator, so it doesn't interpret or rewrite the instructions to aarch64.
You can use Box64 on other ISAs if you implement the necessary translation code. I believe this is what's being done to run games on RISC-V, but I'm not 100% sure. Good ol' qemu-static would also do the job if Box64 isn't compatible (yet), but that's running the entire application in a foreign architecture so the overhead would be a lot more significant.
Can wine do ARM64X resp. ARM64EC to mix native aarch64 code with emulated x86(-64) code in the same process for better efficiency?
Lua 5.2 is 15000 lines of portable ANSI C. On amd64 the Debian default configuration of the interpreter compiles to a 950KiB executable that strips to 224K. I think reduced configurations can go below 100K. It doesn't start extra threads, demand a thread of its own, or have tricky memory management demands. What JS interpreter would you recommend for cases where that's a good fit? Something that's less than a megabyte and can be compiled to run on weird architectures.
https://duktape.org is in a similar ballpark.
kill -9 is sending a SIGKILL signal which, well, kills the program immediately.