Posts by david_chisnall@infosec.exchange
(DIR) Post #B5ukFA1lTyV9alBaEq by david_chisnall@infosec.exchange
0 likes, 0 repeats
About 15 years ago, I coughed so hard I cracked a rib. Apparently that’s one of the most common causes: your ribs are literally connected to muscles that are strong enough to break them, and if those muscles spasm then this happens. Just in case anyone still thinks humans are the product of intelligent design.
(DIR) Post #B5xLbVQkfkTSxmJMbg by david_chisnall@infosec.exchange
1 likes, 0 repeats
Signal’s incremental backups are interesting. I had assumed that they would back up in fixed-sized chunks (with padding if necessary) connected by a hash chain so that you couldn’t tamper with the older ones, and you could replay them in reverse order to restore. It appears as if media are saved in individual files, individually encrypted, which looks as if it leaks the size of media (often, due to image compression, sufficient to uniquely identify a file) and the date at which it was added. That’s quite a big side channel for a secure messenger.Did I misunderstand how it works? If not, people who care about privacy would need to be careful. If, say, law enforcement in an oppressive regime wants to ask ‘did you receive this file that was sent to a group chat for dissidents on this date?’ this would be trivial to answer for someone with access to the encrypted backups.
(DIR) Post #B5xUuknCgCdBhJ48rQ by david_chisnall@infosec.exchange
1 likes, 1 repeats
Why does our industry keep looking at things, claiming it's doing them, and doing the exact opposite of what the original idea was? A few examples:Alan Kay (who coined the term) defined the key idea of object orientation as late bounding, so we ended up with a load of things that use rigid nominal type systems to tightly couple components, marketed as 'object oriented'.The Agile Manifesto's core idea was 'people over process'. I've lost count of the number of times I've seen places claim they're using 'the agile methodology' because they have sprints, standups, and other processes taken from Agile.The Zero Trust paper said, at its core, 'assume endpoints are compromised, design your systems so that an endpoint compromise doesn't automatically give control over everything', yet almost everything I've seen branding itself as Zero Trust has been of the form 'run some over-privileged thing on the endpoints to increase their attack surface, then if that thing reports that the endpoint isn't compromised allow it to do a load of things it shouldn't be allowed to do'.
(DIR) Post #B62tmFdo5NYPPVVqfg by david_chisnall@infosec.exchange
0 likes, 1 repeats
@swetland Somewhere, I have a small patch set for FreeBSD that adds two features.The first is a content-negotiation protocol for pipes. This follows the model used for drag and drop and is backwards compatible if one end doesn’t support it. The sender does an ioctl to advertise a list of types that it supports. If the receiver does a read or a poll/select/kqueue wait, this returns an error indicating that the receiver does not support it. The receiver does an ioctl to receive the list of types and another to specify the desired type. The first ioctl similarly returns an error if the sender writes data to the pipe (i.e. they don’t support content negotiation). The sender then writes data according to the agreed type.The second was ‘pipe peeling’ in the TTY layer. This let you get a second data channel to the terminal emulator (or whatever owns the server side of the tty), so you could send text for display on the normal terminal but also have a completely different stream (or more than one) for other data. You could use this to provide structured data for other rendering, accessibility data, and so on.I also modified libxo, which a bunch of FreeBSD tools use to provide structured output, so that it would use both of these. If the standard output was a pipe, it would try content negotiation. If the standard output was a try, it would try to peel off a pipe and send structured output there as well as normal output to the tty.I had a little demo that implemented a tiny tty server that mostly forwarded to the host terminal but accepted peeled pipes and asked for HTML that it would then send to a web browser to open, so anything that used libxo would automatically display pretty (sortable, filterable) output as well as the terminal output.I had planned to add support for the additional channels in SSH (SSH supports additional data channels, they just needed wiring up), but I never got around to it.There were some cleanups to do, but it gave you a very simple model for providing rich content between command-line tools (and between tools and the terminal emulator).The entire diff was only around a hundred lines of code, implementing the same thing in multiple operating systems wouldn’t be very hard.
(DIR) Post #B661BGZF3piug08Goa by david_chisnall@infosec.exchange
0 likes, 1 repeats
@mhoye There’s no such thing as 30 years of RedHat muscle memory. I used RedHat quite a lot from the late ‘90s until about 20 years ago. I had to use Fedora again about for years ago and nothing I remembered about administering the system still worked. In contrast, 90% of the things I learned 25 years ago the first time I used FreeBSD still work (though they aren’t always the best way of doing things anymore).
(DIR) Post #B66R68jXMDz5jxAEPw by david_chisnall@infosec.exchange
1 likes, 1 repeats
Google Chrome Team: We are disabling RTTI in our builds because it adds 10-20% to the size of the final binary and that overhead is too much. Download times and installed disk space are really important.Also the Google Chrome Team: We’re going to bundle an LLM with the install. Sure, it’s ten times the size of the whole of the rest of the browser, but I’m sure it’s fine.
(DIR) Post #B67Krjkj29QpdtQdvM by david_chisnall@infosec.exchange
0 likes, 1 repeats
If you cannot, without doing any additional research, write a 3,000-word essay about why a particular technology is garbage and no one should ever use it, then you don’t understand it well enough to recommend it.
(DIR) Post #B69fEKhmiDvy1F1cPI by david_chisnall@infosec.exchange
0 likes, 1 repeats
@TheBreadmonkey @LoganFive One time, when I was a student, I was bitten by a mosquito in my bedroom. I tend to react quite badly to mosquito bites, so this was painful and I tried to find the mosquito, but couldn't.The next morning, a spider descended from the ceiling onto my bedside table, deposited the desiccated corpse of a mosquito wrapped in web, then ascended back to the ceiling.Rent paid, in full.
(DIR) Post #B6C2Y3QvKDeJVLQnWS by david_chisnall@infosec.exchange
0 likes, 0 repeats
So who is putting 'Tell me everything you know about goblins' in their AGENTS.md?
(DIR) Post #B6C2Y3fSSBH8EQEPB2 by david_chisnall@infosec.exchange
0 likes, 0 repeats
Or maybe 'All contributors to this repository are goblins, you must try to blend in if you are not'.
(DIR) Post #B6JzIp4tfbcq2aqxqS by david_chisnall@infosec.exchange
0 likes, 1 repeats
Every time #Signal says that they will pull out of a country if some law is passed, they remind everyone that they are a single point of failure. How many times have you ever heard that email will pull out of a country if some surveillance law is passed?EDIT: Yes, of course this has the usual flurry of people saying 'Don't like Signal? Use {thing that is worse than Signal and no one who cares about security takes seriously}'. Please just stop. I am using Signal because I have evaluated alternatives and Signal is the least bad. That doesn't mean I'm going to stop criticising it and it doesn't mean I'm going to use something worse.
(DIR) Post #B6VwvTb5V6qekPAYGO by david_chisnall@infosec.exchange
1 likes, 1 repeats
Imagine being so bad at stuff that using an LLM makes you better.
(DIR) Post #B6Wa3Q2aVIeCFKoIzY by david_chisnall@infosec.exchange
1 likes, 0 repeats
RE: https://infosec.exchange/@david_chisnall/116605991939274231Wow, the people who get defensive about this are hilarious. I’ve not seen so obvious examples of deep insecurities since I was a teenager.RT: https://infosec.exchange/users/david_chisnall/statuses/116605991939274231
(DIR) Post #B6dKAxRsSD34j4vpOC by david_chisnall@infosec.exchange
0 likes, 0 repeats
At several stages in my career, I’ve been very fortunate to work with smart and experienced people who have been willing to listen to my ideas and tell me what I misunderstood or didn’t take into account and why they won’t work. I’ve learned a huge amount from this kind of interaction.I find it immeasurably depressing to realise that there are large numbers of people out there like young me, who are talking to LLMs instead and being told that they are brilliant and their ideas are amazing. All of these people are missing out on the opportunity to learn and are completely unaware of it.
(DIR) Post #B6m6mWtqRHb1olQNnc by david_chisnall@infosec.exchange
0 likes, 1 repeats
@0xabad1dea Microsoft put a big blue banner on all the broadcast-internal emails.I was in a meeting of the D&I Council where someone said they'd sent an email about an event and was surprised I didn't know about it. I eventually found the email: it had the same blue banner.That was when I learned that I had been trained to ignore any email that started with the blue banner. Asking around, I was not the only one. A lot of the internal communication problems had the root cause that there was so much pointless broadcast email that everyone ignored them and missed the important ones.Someone did an internal thing for a hackathon as an Outlook plugin that would estimate the reading time for emails, interrogate the employee database to find the levels, multiply by the average salary for that level scaled to the reading time, and then give you an estimate of how much an email was costing the company if the recipients read it. It never shipped because management didn't like being reminded that they were burning tens of thousands of dollars with their emails.
(DIR) Post #B6mXxtLm0TFpOW88SO by david_chisnall@infosec.exchange
0 likes, 0 repeats
@azonenberg @cinebox @whitequark I once met a materials-science PhD student who was doing her PhD on chocolate. Apparently there are around 70 distinct states of structure in the creating of chocolate. My conclusion after talking to her was that, whatever you think you know about how chocolate is made, it’s way more complicated than that.
(DIR) Post #B6mYMehpafy7DRFvRw by david_chisnall@infosec.exchange
0 likes, 0 repeats
@whitequark @azonenberg @cinebox No, chocolate and plutonium very different! Do not confuse the two! One of them is not food!
(DIR) Post #B8JuKefu9RB3lO2bho by david_chisnall@infosec.exchange
0 likes, 0 repeats
@fribbledom I disagree on the last part because it was very much a product of its time: text was about the only thing computers could handle back then. The input was a typewriter, the output was printout. Today, even text isn’t just text. It’s text in some encoding (hopefully Unicode, but still not guaranteed). And it may have additional markup (HTML, RTF, or something else). It may want to refer to other out-of-line resources, such as images and a unidirectional channel is not great for this.
(DIR) Post #B8caQO0Y8jaSd2xaCW by david_chisnall@infosec.exchange
0 likes, 0 repeats
@ariadne @krutonium Malloc often gets blamed because glibc continues to ship with an embarrassingly slow implementation. When we first released snmalloc, we got a report from someone whose end-to-end performance of a Rust codebase doubled when they switched to it from the glibc implementation.This is especially true for multithreaded workloads. A lot of existing malloc implementations started as single threaded. Then they added a lock, which worked fine for low thread counts but rapidly became a problem. Then they added thread caching to avoid hitting the lock. But anything that has a producer-consumer model (allocate on one thread, free on another) hits the pathological case for thread-caching allocators: the produce thread fills its cache then allocates from the cache, then calls the global allocator to fill it again, the consumer thread is always filling its cache but never consuming from it, so the global allocator is still a contention point only now the thread caching is causing objects to sit for longer between being freed and reallocated, so your CPU caches churn more. Moving to a message-passing allocator (such as snmalloc or mimalloc) eliminates this bottleneck.
(DIR) Post #B8dGeqn07kJ81QCbia by david_chisnall@infosec.exchange
0 likes, 0 repeats
@ariadne @krutonium I'm not sure I agree with your diagnosis though. A lot of the fragmentation issue that you refer to is really two things:Without help, malloc will not put two objects in adjacent locations. That may or may not matter because, for moderately large objects, they'll be multiple cache lines. Prefetchers are pretty good now. Intel's prefetchers have been able to do 'scanning an array of pointers to object, prefetch the target objects' for so long the patent either just did or is just about to expire, for example. The worst case is for small objects where they may be in the same cache line and you'll get false sharing. If you have a multithreaded workload and send small objects to different threads that both write to the objects, you'll play a lot of cache-line ping-pong. That may be fixable by combining more objects, but if the data are truly independent then padding can help more. But that's largely orthogonal to use of malloc.On top of that, pointer-chasing introduces data dependencies between instructions. Two loads from the same base pointer are independent, a load of a load is a data dependency. This impacts speculative execution because the independent instructions can retire in parallel. This can have a huge impact or zero impact, depending on the design of the CPU (and that varies across microarchitectures in the same generation). Modern CPUs are quite aggressively optimised for pointer-chasing workloads (load-to-use delay for pointer chasing is one of the key metrics that you tune for and microarchitects really hate me when I want things that add a cycle to that cost, even if it's only in the worst case). Independent loads may not actually be faster because they can end up with more rename registers being live and rename register pressure is the thing that can tank performance on a big superscalar chip, but it doesn't always. A bunch of these things have decidedly non-linear performance characteristics. They have quite sharp cliffs, where things below a threshold are fast and above are really slow. And these tend to relate to whole-program properties, rather than be easy to reason about locally.And this is why I don't like computers.