In yesterday's entry, I talked about our giant (Linux) loginserver and how we limit each person to only a small portion of thatserver's CPUs and RAM . Theselimits sometimes expose issues in how programs attempt to work outhow many CPUs they have available so that they can automaticallyparallelize themselves, or parallelize their build process. Thiscrops up even in areas where you might not expect it; for example,both the Go and Rust compilers attempt to parallelize various partsof compilation using multiple threads

One of the moderately peculiar aspects of our environment is that we stillhave general Unix multiuser systems that people with accounts can log in to and do stuff on. As partof this we have some general purpose login servers, and in particularwe have one that's always been the most popular, partly because itwas what you got when you did 'ssh cs.toronto.edu'. For years andyears we had a succession of load and usage issues on this server,where someone would log in and

The (more) secure way to do a home wireless network (or networks)is relatively clear. Your wireless network (or networks) shouldexist on its own network segment, generally cut off from any wirednetworking you have and definitely cut off from direct access toyour means of Internet connectivity. To get out of the network itshould always have to go through a secure gateway that firewallsyour home infrastructure from the random wireless devices you haveto give wifi access to and their random traffic. One of the things

One of the ways that security is people, not math is that as part of security being ultimately about people, part ofthe work of computer security is convincing people that your securitymeasures actually work. I don't mean this in a narrow technicalsense of specific technical features working as designed; I meanthis in the broader sense that they achieve the general goals ofsecurity, which is really about safety . People want to know thattheir data and what they do on the computer is safe, in the full

Recently, we had a puzzling incident where the OOM killer wastriggered for a cgroup, listed some processes, and then reportedthat it couldn't kill anything:

acctg_prof invoked oom-killer: gfp_mask=0x1100cca (GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=-1000[...]memory: usage 16777224kB, limit 1677721

When I noted that brute force attackers seem to go away rapidlyif you block them , one reactionwas to suggest that SSH shouldn't be exposed to the Internet. Whilethis is viable in some places and arguably broadly sensible (sinceSSH has a large attack surface, as we've seen recently inCVE-2024-6387 ),it's not possible for us . Hereat a university, SSH has become our universal external accessprotocol.

One of the peculiarities of