Notices by david_chisnall (david_chisnall@infosec.exchange)

@ryanc I used to have (before it was stolen) a Dark Sun expansion that had a character path that let you become a dragon!

@fluffgar @limebar Mining is an incredibly misleading term.

Proof of work schemes rely on a problem where it's easy to determine whether an answer is correct, but hard to find the right answer. Each node in the network can guess an answer and then see if they got the right one. Whoever guesses right 'wins'. With a faster processor (especially a GPU or custom hardware), you can make a lost more guesses, so you have a higher probability of winning.

Whoever wins can use their solution to add a new block to the blockchain. Roughly speaking, this means that they can process one transaction. This also lets them charge a small transaction-processing fee, so 'mining' generates new coins because you're paid for processing transactions.

I haven't looked for a while, but last time I checked the entire Bitcoin network was processing around 7 transactions per second, with a power consumption of a modest country. To put this in perspective, a single Raspberry Pi running PostgreSQL can easily handle a couple of orders of magnitude more with a power consumption of a few Watts. If you have three of them, you can set up a replicated cluster and still easily handle a thousand transactions per second (probably more). Visa handles over 20,000 transactions per second, including running a load of fraud detection things.

They aren't doing anything useful, they're just burning energy to play a gambling game where tickets are paid for in electricity and compute power.

@mcc I always thought of Oracle as the lawful evil tech company. At least prior to the Sun acquisition, their evil was directed almost exclusively at people who had signed a contract with them, whereas most other big tech companies manage to do a lot more collateral damage.

It's easy to dislike Oracle and never have to touch their products. The same is somewhat true of Apple. It's far less true of the likes of Google, Microsoft, and Facebook.

@collectifission @bughuntercat Os we didn’t have C, Pascal derivatives would have taken the same place and, I suspect, the world would be a marginally better place. Later Pascal dialects fixed a lot of things that Kernighan complained about in Why Pascal is not my Favourite Language and a lot of additional things that were not fixed in C.

The original Mac operating system was written in Pascal, not C, and Win16 was designed to support both C and Pascal as first-class languages. The Burroughs Large Systems machines used (garbage collected!) Algol to write the OS.

UNIX was influential, but it’s not always been for positive reasons. A lot of the things that made modern systems so insecure would have been impossible on MULTICS, but UNIX threw the, away and they were not reintroduced even when UNIX derivatives were running on machines orders of magnitude more powerful than those for which MULTICS was designed.

Imagine you’re in a casino. Someone walks up to the roulette table, puts $1000 on 14. They win! They now have $50,000. Now they move to another table, and put $500 on red. They lost, so they put $1,000 on red. They lose again. They put $2,000 on red. They win! Now they have $50,500! They’re such a winner!

You didn’t see that they put $1,000 on 14 every day for the past twenty days. They only won because they are able to afford to lose $20,000. They’re actually only $30,500 up, but that’s still a big win. You also didn’t see the ten other people who tried the same strategy, but never landed on a table that came up with their number.

This is the kind of person that Silicon Valley idolises.

@encthenet In the south of Wales, road signs are written in English and then Welsh. After living there for a few years, I was surprised that slightly further North, the signs were Welsh only. It took me going past a couple of the, to realise that they weren’t. They were written in Welsh then English and my brain filtered out the alternate lines.

@feld I wanted to build a DNS resolver with CCF (distributed key-value store that ran in SGX enclaves and other TEEs). The clients would be able to get a remote attestation that they were connected to a server that ran a specific version of the server code. The network would be able to send queries to authoritative servers from any node, maintain an internal cache, and do spurious lookups to make it hard to attack with traffic analysis.

I think this would meet the requirements for DNS encryption.

Why are are people wanting their time with Rust when the B5500 showed that the best language for systems programming is garbage-collected Algol?

Lots of people seem to be confused. There are three very separable problems:

• Sending billionaires to Mars.
• Making it possible for humans to survive the trip to Mars.
• Making it possible for humans to survive on Mars.

The second two are in no way a prerequisite for the first.

@revng What's your baseline allocator if jemalloc is a 30% speedup? FreeBSD has shipped jemalloc as the default malloc in libc, and I see a fairly consistent performance improvement replacing it with snmalloc.

It’s amazing how many LinkedIn posts say some variant of ‘remote work is bad because remote teams can’t do {thing remote teams have been doing successfully since IRC was the state of the art in communication for remote workers}’. And what they mean is ‘I don’t know how to manage remote teams’. It takes a special kind of arrogance to believe that just because you can’t do something that other people have been doing for decades, that thing is impossible.

Don’t settle for an alpha male, wait for at least the release candidate.

@SecurityWriter

What I do fear is that for those that do heavily invest, they’ll be required by the likes of Microsoft to begin to speak in ways that Copilot can parse and ‘understand’.

We have those things, they’re called programming languages and they have well-specified syntax (and, often, semantics). Unfortunately, the shape of what an LLM can parse depends on its architecture and training data, and fairly small changes to either can have a big impact. Copilot seems to be a roll in release thing, where the underlying models can be changed at will. Just because you have created a shape that Copilot can parse today does not mean that it will work tomorrow.

We are going to see many organisations rediscovering ontology drift. My favourite thing about ontology drift is that it’s recursive: everyone who rediscovers it comes up with incompatible terminology for it and cannot share their findings in a useful way.

@ryanc A school my mother worked at had a filter that would block porn and one of the heuristics it used was the number of Xs in a page. Anything about XFree86 or Linux tended to be blocked.

It astonishes me that people expected LLMs to be good at creating summaries. LLMs are good at transforms that have the same shape as ones that appear in their training data. They're fairly good, for example, at generating comments from code because code follows common structures and naming conventions that are mirrored in the comments (with totally different shapes of text).

In contrast, summarisation is tightly coupled to meaning. Summarisation is not just about making text shorter, it's about discarding things that don't contribute to the overall point and combining related things. This is a problem that requires understanding the material, because it's all about making value judgements.

So, it's totally unsurprising that the Australian study showed that it's useless. It's no surprise that both Microsoft and Apple's email summarisation tools discard the obvious phishing markers and summarise phishing scams as '{important thing happened}, click on this link' because they don't actually understand anything in the text that they're discarding, they just mark it as low entropy and discard it.

@cr1901 @ewenmcneill @mxshift

It’s not a stupid question. You absolutely can lie about the source address for a packet. On a local network segment (with no VLANs), it will probably arrive just fine. If it needs routing, it may go through something that says ‘hmm, packets from this subnet aren’t allowed to come from over here’ and drops it on the floor.

The important question is: and then what?

The main use for the source address is to allow the destination to reply. If you send a packet with a faked source address, any reply will go to the faked source address and not to you. Sometimes that’s useful. Some NAT tunnelling things used to rely on this doing terrifying things with intermediaries taking part of a TCP handshake.

In general, most connection-oriented things (TCP, QUIC) require some handshake and so you’ll end up failing to establish the connection if you fake the source. As an attacker, you need to compromise the target network stack with the first packet (which is sometimes possible) to get anything useful from stateful protocols. You may (if you can guess the sequence number) be able to inject a packet into the middle of a TCP stream, but generally that will just show up as a decryption failure in TLS (you are using TOS for everything, right?).

The more fun attacks rely on reflection. DNS, for example, is designed to be low latency and so is (ignoring newer protocol variants) a single UDP packet request and a single UDP packet response. With things like DNSSEC signatures (or entries with a lot of round-robin IPs), the response can be much bigger than the request and so you can send a request to a DNS server with a small request and a spoofed source, and the DNS server will reply with a big packet to your victim. DNS servers and other parts of network infrastructure have mitigations for this, but it’s easy to accidentally make a new protocol that provides this kind of amplification. QUIC has a rule that the first packet must be at least as big as its response (so sometimes requires padding) to establish a connection precisely to avoid this kind of issue.

If you think that’s scary, remember that networks are everywhere. Most busses are now actuallly networks. PCIe is a network and PCIe source addresses are used by the IOMMU to determine which devices can access which bit of the host memory. Where does the PCIe source address come from? The device puts it in the PCIe packet. It’s trivial for a PCIe device (including an external one connected via Thunderbolt) to spoof the ID of a valid one and initiate DMA to and from regions exposed to the other device. IDE and TDISP should mitigate these problems when they’re actually deployed (I don’t know of any shipping hardware that implements them yet. I think IDE is sufficient but it’s been a while and I don’t remember what things are in which spec).

@cr1901 IOMMUs in most systems are designed to allow devices to be attached to VMs. The threat model is that you have attached a device to a VM and want to protect against that device initiating DMAs to or from a physical address that the VM cannot access. They are somewhat useful without virtualisation (and, increasingly for kernel-bypass things with userspace), but the threat model almost always assumes that devices are trustworthy. The PCIe spec even includes a feature called ATS that allows the device to bypass the IOMMU if it implements its own (fortunately, it’s possible to turn this off).

@cr1901 @ewenmcneill @mxshift

Re: sending a big packet to a victim, at worst won't that cause excess network traffic that'll be ignored (b/c the victim won't be listening, the kernel will discard it)?

Sure, the kernel will discard it at the far end, but the network connection to the victim Is finite. If you fill it with big packets, it doesn’t matter that the kernel discards them, it will never get to see other things. If you have a 10 Mbit connection and so does your victim, and you can get DNS servers to amplify your attack with a 10:1 ratio (response is 1000 bytes for a 100-byte request), you can deliver 100 Mb/s to the victim, which will cause a load of the packets that they want to be dropped, which will cause TCP connections to get slower, which will make their proportion of the total drop, which will make them slower, and so on.

Also I thought the whole purpose of IOMMU was "the kernel decides the memory addresses a device can write to/read from, for each xaction". Won't not knowing valid addrs guard against spoofing?

The kernel decides a mapping between device physical addresses and host physical addresses. A malicious device can choose to use a different mapping. For most of these things, this is fine in the threat model. They assume trusted devices and untrusted VMs.

@cr1901 The threat model for most IOMMUs relates to VMs. The earliest ones (at least, outside of mainframes) were actually nothing to do with security, they were there to allow cheap 32-bit NICs to DMA everywhere in a workstation with 8 GiB of RAM, but the Intel, AMD, and Arm designs are all built around virtualisation.

If you do not use virtualisation, you can still use an IOMMU to restrict which regions of the physical address space a device can write to. Regions that no device can write to are safe. Regions that a device can write to cannot be protected from a different device writing to them if the device is malicious.

If devices are not actively malicious, this is not a problem. If a kernel decides to set up different IOMMU regions for each device, a bug in a driver that sends the wrong address for DMA will be mitigated. If a system does device pass-through to a malicious VM and the VM tries to initiate DMA somewhere outside of its pseudophysical (sometimes called Guest Virtual) address space, the IOMMU will stop it.

@matt Low level things (wrapping pdfork, sockets, and so on) in Rust, most of the logic (e.g. systemd-compatible socket activation) in Lua.