https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/...

https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glib...

Comments URL: https://news.ycombinator.com/item?id=47200286

Points: 6

# Comments: 1

The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire.

LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).

DRM/KMS using dumb buffers are the preferred API if you want to do software rendering and modesetting. You can find several examples of this online if you search for drm_mode_create_dumb.

[0] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds...

Sun popularized the term "virtual machine" when marketing Java instead of using "interpreter" or "P-code", both for marketing reasons (VMware had just come on the scene and was making tech headlines), but also to get away from the perception of classic interpreters being slower than native code since Java had a JIT compiler. Just-in-time compilers that compiled to the host's machine code at runtime were well-known in research domains at the time, but were much less popular than the more dominant execution models of "AST interpreter" and "bytecode interpreter".

There might be some gatekeepers that suggest that "interpreter" means AST interpreter (not true for the Python interpreter, for instance), or VM always means JIT compiled (not true for Ruby, which calls its bytecode-based MRI "RubyVM" in a few places), but you can ignore them.

https://dev.epicgames.com/documentation/en-us/unreal-engine/...

Last year it was their "Thunder" architecture being the world's fastest GPU, now it's Zeus. Neither one actually exists. https://bolt.graphics/bolt-graphics-unveils-thunder-the-worl...

All their blog posts and marketing material are just generic hype about the concept of raytracing. I don't think these guys have an actual product.

The best anyone can figure out is that it's reversing the left and right branches, which seems like it's ten lines of code, at most?

The classic usage is a single source shader which is specialized using #define's and compiled down to hundreds of shaders. This is what Christer uses in that blog post above (and Aras does as well in his ubershader blog post)

Dolphin used it to mean a single source shader that used runtime branches to cover all the bases as a fallback while a specialized shader was compiled behind the scenes.

The even more modern usage now is a single source shader that only uses runtime branches to cover all the features, without any specialization behind the scenes, and that's what Dario means here.

Driver caches mean that after everything gets "prewarmed", it won't happen again.

https://cstools.asme.org/csconnect/CommitteePages.cfm?Commit...

If that's not in your threat model, and you want encryption for another purpose, then I could understand that, but currently, protecting the endpoints against malicious attackers in the middle is the big value of TLS.

The only way to standardize ~all companies would be to have them all run the same exact ledger system, and if it was easy enough to make them do that, it would be easy enough to have them standardize a different reporting system for the same purpose.