Hírolvasó

A cégvezetés szerint a vállalat technológiai képességeivel kapcsolatban továbbra is sok a kétely, de úrrá lesz a menedzsment a helyzeten.

Március 20-án új Domainregisztrációs Szabályzat lép hatályba, amit megelőz egy kis leállás.

A Vera Rubin több mint kétszer gyorsabb lehet a Blackwellnél, az egységnél a cég már saját CPU dizájnt használ.

ROTFL @ Balfasz RTL <del>Híradó</del> FakeNewsda trey 2025. 03. 19., sze – 09:00

Almost two years ago, Twitter launched encrypted direct messages. I wrote about their technical implementation at the time, and to the best of my knowledge nothing has changed. The short story is that the actual encryption primitives used are entirely normal and fine - messages are encrypted using AES, and the AES keys are exchanged via NIST P-256 elliptic curve asymmetric keys. The asymmetric keys are each associated with a specific device or browser owned by a user, so when you send a message to someone you encrypt the AES key with all of their asymmetric keys and then each device or browser can decrypt the message again. As long as the keys are managed appropriately, this is infeasible to break.

But how do you know what a user's keys are? I also wrote about this last year - key distribution is a hard problem. In the Twitter DM case, you ask Twitter's server, and if Twitter wants to intercept your messages they replace your key. The documentation for the feature basically admits this - if people with guns showed up there, they could very much compromise the protection in such a way that all future messages you sent were readable. It's also impossible to prove that they're not already doing this without every user verifying that the public keys Twitter hands out to other users correspond to the private keys they hold, something that Twitter provides no mechanism to do.

This isn't the only weakness in the implementation. Twitter may not be able read the messages, but every encrypted DM is sent through exactly the same infrastructure as the unencrypted ones, so Twitter can see the time a message was sent, who it was sent to, and roughly how big it was. And because pictures and other attachments in Twitter DMs aren't sent in-line but are instead replaced with links, the implementation would encrypt the links but not the attachments - this is "solved" by simply blocking attachments in encrypted DMs. There's no forward secrecy - if a key is compromised it allows access to not only all new messages created with that key, but also all previous messages. If you log out of Twitter the keys are still stored by the browser, so if you can potentially be extracted and used to decrypt your communications. And there's no group chat support at all, which is more a functional restriction than a conceptual one.

To be fair, these are hard problems to solve! Signal solves all of them, but Signal is the product of a large number of highly skilled experts in cryptography, and even so it's taken years to achieve all of this. When Elon announced the launch of encrypted DMs he indicated that new features would be developed quickly - he's since publicly mentioned the feature a grand total of once, in which he mentioned further feature development that just didn't happen. None of the limitations mentioned in the documentation have been addressed in the 22 months since the feature was launched.

Why? Well, it turns out that the feature was developed by a total of two engineers, neither of whom is still employed at Twitter. The tech lead for the feature was Christopher Stanley, who was actually a SpaceX employee at the time. Since then he's ended up at DOGE, where he apparently set off alarms when attempting to install Starlink, and who today is apparently being appointed to the board of Fannie Mae, a government-backed mortgage company.

Anyway. Use Signal.

comments

This is an esoteric topic that might be of interest to people implementing Intel hypervisors. It assumes you know the basics of the Intel virtualization architecture, see Hypervisor from scratch for a tutorial. The actual full VT architecture is described in Volume 3 of the Intel SDM

Let’s say we write an x86 hypervisor that starts in the UEFI environment and virtualizes the initialization phase of an OS. But the hypervisor wants to eventually quit itself to not cause extra overhead during OS run time.

The way the hypervisor works is that it runs in its own memory and with its own page tables which are switched atomically on every VM exit by the VT-x implementation. This way it is isolated from the main OS.

At some vm exit with the hypervisor running in its own context it decides that it is not needed anymore and wants to quit. To disable VT support the VMXOFF instruction can be used. But what we really need is an atomic VMXOFF + switch to the original OS page tables plus a jump, and all that without using any registers which need to be already restored to the original state of the OS.

One trick is to use the MOV to CR3 instruction that reloads the page table as a jump. As soon as the page table is reloaded the CPU will fetch the next instruction with the translations from the freshly loaded page table, so we can transfer execution to the guest context. However to do that the MOV CR3 needs to be located just before the page offset of the target instruction. This can be done by copying a trampoline to the right page offset (potentially overlapping into the previous page). The trampoline is located in a special transfer page table mapping that places writable code pages overlapping the target mapping.

But there are some complications. The hypervisor also needs to load the segmentation state (like GDT/LDT/IDT) of the guest. In theory they could just be loaded by mapping these guest pages into the transfer mapping and loading them before the transfer. But what happens if the GDT/LDT/IDT is on the same page as the target address? This is common in real OS’ assembler startup code which is implemented in a small assembler file without any page separation between code and data. One option would be to copy them to the transfer page too and load it there, or the hypervisor first copies them to a temporary buffer and loads it from there. In the second option the base addresses of these structures will be incorrect, but in practice you can often rely on them getting reloaded eventually anyways.

Another problem is the register state of the target. MOV to CR3 needs a register as the source of the reload, and it needs to be the last instruction of the trampoline. So it is impossible to restore the register it uses. But remember the hypervisor is doing this as the result of a VM exit. If we chose an exit for a condition that already clobbers a register we can use the same register for the reload and the next instruction executed in the original target (and which caused the exit originally) will just overwrite it again.

A very convenient instruction for this is CPUID. It is executed multiple times in OS startup and overwrites multiple registers. In fact VMX always intercepts CPUID so it has to handle these exits in any case. So the trick to quit an hypervisor is to wait for the next CPUID exit and then use one of the registers clobbered by CPUID for the final CR3 reload. This will have inconsistent register state for one instruction in the target, but unless the original OS is currently running a debugger it will never notice. In principle any exit as a result of an instruction that clobbers a register can be used for this.

There is another potential complication if the target address of the OS conflicts with where the hypervisor is running before entering the transfer mapping. The transfer mapping needs to map the original code so that it can be jumped to. This could be solved with a third auxiliary mapping that is used before jumping to the transfer trampoline. In practice it doesn’t seem to be a problem because x86 OS typically run in a 1:1 mapping for startup, and that cannot conflict with the 1:1 mapping used by UEFI programs as our hypervisor.

Happy hypervisor hacking!

If all goes according to plan, the Ubuntu project will soon be replacing many of the traditional GNU utilities with implementations written in Rust, such as those created by the uutils project, which we covered in February. Wholesale replacement of core utilities at the heart of a Linux distribution is no small matter, which is why Canonical's VP of engineering, Jon Seager, has released oxidizr. It is a command-line utility that helps users easily enable or disable the Rust-based utilities to test their suitability. Seager is calling for help with testing and for users to provide feedback with their experiences ahead of a possible switch for Ubuntu 25.10, an interim release scheduled for October 2025. So far, responses from the Ubuntu community seem positive if slightly skeptical of such a major change.

Megszavazták a "tilos az olyan gyűlés megtartása, amely a gyermekek védelméről szóló törvényben meghatározott tilalmat sért" javaslatot trey 2025. 03. 18., k – 15:11

Az európai szabályok miatt nem merné kockáztatni az Apple, hogy dobja az USB-C portot.

Security updates have been issued by Debian (freetype and rails), Fedora (mosquitto and python-django4.2), Mageia (libarchive, libreoffice, php, and quictls), Red Hat (webkit2gtk3), SUSE (erlang, nethack, python312, and wpa_supplicant), and Ubuntu (freetype and plantuml).

Az év végéig szinte teljesen a pálya szélére szorítja a Google az Assistant alkalmazást, hogy helyébe a Gemini lépjen.

A GIMP 3.0 után az ígéretek szerint azért kicsit felgyorsul majd a tempó.

A magyarok jórészt tartaléknak tartják meg a régi mobilokat, közben a használt, felújított példányok vásárlása fokozatosan egyre népszerűbb.

Magyarországon is használható az Apple mobilokon a Tap to Pay fizetési megoldás.

A tavalyi visszautasítás után ismét tárgyalóasztalhoz ültek a felek.

A cég kizárólag saját szerverparkjába szánt AI-processzorának gyártója továbbra is a TSMC marad.

A drót című sorozatról trey 2025. 03. 18., k – 07:22

The long-awaited GIMP 3.0 release is now available. Major changes in 3.0 include non‑destructive editing for most commonly‑used filters, improved text creation, better color space management, and an update to GTK 3.

This is the end result of seven years of hard work by volunteer developers, designers, artists, and community members (for reference, GIMP 2.10 was first published in 2018 and the initial development version of GIMP 3.0 was released in 2020).

See the release notes and NEWS file for more details about this release. LWN covered a near-final release of GIMP 3.0 in November last year.

Version 12.00 of the SystemRescue live Linux system has been released. SystemRescue is an Arch Linux based bootable toolkit for repairing systems in the event of a crash. Notable changes in this release include an update to Linux 6.12.19, support for bcachefs, and a number of updated disk utilities. See the package list for a complete list of software included in this release.

One of the many important tasks that the kernel's memory-management subsystem must handle is keeping track of how pages of memory are mapped into the address spaces of the processes running on the system. As long as mappings to a given page exist, that page must be kept in place. As it turns out, tracking these mappings is harder than it seems it should be, and the move to folios within the memory-management subsystem is adding some complexities of its own. As a follow-up to the "mapcount madness" session that he ran at the 2024 Linux Storage, Filesystem, Memory-Management, and BPF summit, David Hildenbrand has posted a patch series intended to improve the handling of mapping counts for folios — but exact accounting remains elusive in some situations.