Logbook

Amdahl's Law and the limits of high core count systems

Amdahl's Law (1967) notes that a parallel process always has some serial component to it, and the speedup by parallelization is limited by the serial path. It's the argument to be made for getting processors that have faster cores rather than more cores, because you get more incremental results by having fast cores than having a vast array of slow cores.

You can see the results of Amdahl's Law on a multicore processor running something complex (like a big software build) by using htop. The usual experience is that the system buzzes along for a long time with all the cores busy and then suddenly comes to a screeching halt when the serial part of some effort (e.g. a serial linker) has its turn to run. Your fancy 128-core system grinds away with only one or two cores running through that serial part of the process.

I found this "Cornell Virtual Workshop" https://cvw.cac.cornell.edu/parallel/intro/index on parallel computing in my search for a good writeup on Amdahl's Law. It also introduces "Gustafson's Law" (1988) https://cvw.cac.cornell.edu/parallel/efficiency/amdahls-law which suggests that as researchers get access to more cores, they focus not on making their runtimes go faster with the added processing power, but in doing more work within an acceptable amount of time. So if you decide that it's good enough to run a test suite in 10 minutes, and your system gets faster by adding more cores, instead of pushing to reduce the time to something smaller you'll be inclined to run more tests within that 10 minute time window.

See http://www.johngustafson.net/pubs/pub13/amdahl.htm for Gustafson's formulation of this, "One does not take a fixed-size problem and run it on various numbers of processors except when doing academic research; in practice, the problem size scales with the number of processors."

using "just" and a justfile to simplify common operations

"just is a handy way to save and run project-specific commands."

https://just.systems

If you are used to make and Makefiles, just fits right in. It doesn't have the complexity of dependency checking so it's not suitable as a full-scale replacement for a complicated build system, but what it does have is an easy configuration syntax and a straightforward way to save and then reuse shell commands associated with a project.

Use it for example to save complicated and rarely used command line invocations and alias them to something simpler.

It's a lot more compact than having a ~/bin file full of project-specific tooling, and when you invoke it with just -l it lists out everything that's been configured. All in all good things to help reduce the amount of human memory needed to keep complex systems running.

Ultralytics Github Actions plugin compromised by git branch name shell injection attack

Some notes on this novel attack, which injected a crypto miner into affected systems.

https://github.com/ultralytics/ultralytics/issues/18027

Code in the published wheel 8.3.41 is not what's in GitHub and appears to invoke mining. Users of ultralytics who install 8.3.41 will unknowingly execute an xmrig miner.

A related security advisory spells out the attack vector, which embeds shell code in the name of a branch. The branch variable is expanded in Github Actions and used to do its nefarious deeds.

https://github.com/advisories/GHSA-8v8w-v8xg-79rf

The tj-actions/branch-names GitHub Actions references the github.event.pull_request.head.ref and github.head_ref context variables within a GitHub Actions run step. The head ref variable is the branch name and can be used to execute arbitrary code using a specially crafted branch name.

An earlier security advisory for this same package is similar

https://github.com/advisories/GHSA-7x29-qqmq-v6qc

Any workflow that uses the action and runs on pull_request_target is vulnerable to arbitrary code execution within the context of the base branch. An attacker can use this to abuse the GITHUB_TOKEN or steal secrets from the workflow.

Github warns against this and other related attacks that leverage unsanitized and untrusted inputs, and gives examples of how to mitigate this risk:

https://securitylab.github.com/resources/github-actions-untrusted-input/

The best practice to avoid code and command injection vulnerabilities in GitHub workflows is to set the untrusted input value of the expression to an intermediate environment variable.