@AndresFreundTec@mastodon.social avatar

AndresFreundTec

@AndresFreundTec@mastodon.social

Long time postgres developer, working at Microsoft.

Account about tech, not politics. For the latter look to https://mastodon.social/@AndresFreundPol

This profile is from a federated server and may be incomplete. Browse more on the original instance.

AndresFreundTec, to random
@AndresFreundTec@mastodon.social avatar

Any chance a few folks could run the following fio command on various SSDs and tell me the latency, drive model and filesystem?

fio --directory /srv/dev/fio/ --runtime 3 --time_based --output-format json --overwrite 1 --size=8MB --buffered 0 --bs=4096 --rw=write --name write-dsync --wait_for_previous --sync=dsync --name write-fdatasync --wait_for_previous --fdatasync=1 --name write-nondurable --wait_for_previous | jq '.jobs[] | [.jobname, .write.iops]'

--directory needs to be adjusted.

AndresFreundTec, to random
@AndresFreundTec@mastodon.social avatar

The "new" Linux CVE approach seems ... unhelpful at best. I know from experience that dealing with security reports is a pain and I assume that's way worse for Linux than for Postgres. But this just seems to purely be aimed at annoying everyone.

AndresFreundTec, to random
@AndresFreundTec@mastodon.social avatar

I did not think that finding a security vulnerability would lead to tabloids digging around my life. Including "analyzing" (aka making things up) the one personal-ish picture I've ever shared on social media. FFS.

Oddly enough, they weren't interested in lots of kinda pretty graphs.

GossiTheDog, to random
@GossiTheDog@cyberplace.social avatar

deleted_by_author

    •
    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    @GossiTheDog FWIW, I hadn't been on twitter in months, and this made me go back - at least earlier on there was distinct information, particularly around reverse engineering efforts.

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    @feld @GossiTheDog I don't think that's quite right. There could e.g. have been a part of the payload that phones home on its own, if it finds the system its running on to be interesting.

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    @feld @GossiTheDog Or acquired persistence on the system using another way. Or it could have searched the system for package-building infrastructure, modify that to inject payload elsewhere. Etc.

    Those would have required fairly different incident responses.

    AndresFreundTec, to random
    @AndresFreundTec@mastodon.social avatar

    I am a bit concerned by all the focus on small-ish projects with overwhelmed maintainers. There indeed are a lot of problems in that area.

    But I am certain that lots of experienced OSS devs can think of a few large and crucial projects where they fairly easily could have hidden something small in a larger change. Without a lot of prior contributions to the project.

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    @GossiTheDog I think there are a few people looking into that.

    If I were the team behind "jia", I'd have looked at getting into dissimilar projects, not the same project multiple times, not multiple compression libs. But of course there are other actors...

    The scariest areas I can think of are, in that order, compilers / binutils, buildsystems, "build executors" like make/ninja.

    bcantrill, to random
    @bcantrill@mastodon.social avatar

    Recently, the software world was rocked by the discovery of a backdoor in XZ Utils. The backdoor represents many stories, but behind all of them is the story of a single Postgres developer, vexed by a relatable problem: "why is it taking so long to login?!"

    On the next Oxide and Friends, @ahl and I are thrilled to be joined by that developer, @AndresFreundTec, the discoverer of the XZ backdoor. Join us on April 8th at 5p Pacific to hear this extraordinary story!

    https://discord.gg/SAsE6G6W?event=1224880997762338856

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    @bcantrill @ahl Now we just need to avoid derailing into a heated debate about solaris/illumos being good/bad...

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    @bcantrill @ahl There might be more agreement on that :)

    mattblaze, to random
    @mattblaze@federate.social avatar

    An interesting thing about the XZ sabotage is that, while it was very cleverly obfuscated (congratulations to Andres Freund for finding it!), once found, it is very clear that it's a deliberate backdoor. It can't be explained away as an ordinary bug that introduced a vulnerability.

    Says something about the tradeoff space the attacker was working in.

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    @mattblaze Even if you don't care about collateral harm, with something like a backdoor in ssh, it just seem too likely you'd otherwise accidentally make yourself vulnerable too, somewhere in your org.

    AndresFreundTec, to random
    @AndresFreundTec@mastodon.social avatar

    It seems analysis is getting somewhere: https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b

    AndresFreundTec, to random
    @AndresFreundTec@mastodon.social avatar

    I wholeheartedly agree with what Russ wrote here:

    "Also if there's anything the community can do for Lasse personally, please pass that along."

    "Anyone can be the victim of social engineering."

    "I suspect many of us here have had nightmares about being in Lasse's
    position, and probably will have more of them in the future."

    Indeed.

    https://www.openwall.com/lists/oss-security/2024/03/30/25

    AndresFreundTec, to random
    @AndresFreundTec@mastodon.social avatar

    I accidentally found a security issue while benchmarking postgres changes.

    If you run debian testing, unstable or some other more "bleeding edge" distribution, I strongly recommend upgrading ASAP.

    https://www.openwall.com/lists/oss-security/2024/03/29/4

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates.

    Really required a lot of coincidences.

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    One more aspect that I think emphasizes the number of coincidences that had to come together to find this:

    I run a number "buildfarm" instances for automatic testing of postgres. Among them with valgrind. For some other test instance I had used -fno-omit-frame-pointer for some reason I do not remember. A year or so ago I moved all the test instances to a common base configuration, instead of duplicate configurations. I chose to make all of them use -fno-omit-frame-pointer.

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    Afaict valgrind would not have complained about the payload without -fno-omit-frame-pointer. It was because _get_cpuid() expected the stack frame to look a certain way.

    Additionally, I chose to use debian unstable to find possible portability problems earlier. Without that valgrind would have had nothing to complain.

    Without having seen the odd complaints in valgrind, I don't think I would have looked deeply enough when seeing the high cpu in sshd below _get_cpuid().

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    There are more coincidences that are even less interesting. But even the above should make it clear how unlikely it was that I found this thing.

    AndresFreundTec,
    @AndresFreundTec@mastodon.social avatar

    Just to be clear: I didn't mean that I didn't do good - I did. I mean that we got unreasonably lucky here, and that we can't just bank on that going forward.

    AndresFreundTec, to random
    @AndresFreundTec@mastodon.social avatar

    My colleague / fellow postgres hacker David Rowley wrote about postgres planner improvements in PG 16. Worth reading:
    https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/what-s-new-in-the-postgres-16-query-planner-optimizer/ba-p/4051828

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • everett
  • magazineikmin
  • khanakhh
  • InstantRegret
  • rosin
  • Youngstown
  • ngwrru68w68
  • mdbf
  • slotface
  • normalnudes
  • Durango
  • kavyap
  • DreamBathrooms
  • megavids
  • GTA5RPClips
  • tacticalgear
  • osvaldo12
  • thenastyranch
  • tester
  • Leos
  • modclub
  • ethstaker
  • cubers
  • cisconetworking
  • provamag3
  • anitta
  • lostlight
  • All magazines
    •