Jakob (Jack/Jackie) @jakob@mastodon.chaosfield.at

"Excuse me," said the robot.
"How can I help?" the librarian asked.
"I have just been manufactured. My training includes everything I need to work, and to navigate society."
"That's nice."
"But..."
"Yes?
"Is there more?"
"Yes!"
#MicroFiction #TootFic #SmallStories

I'm about to slay some French vampires

// #RaspberryPi codec licensing serial algo (<=RPi3)
// shoutouts to fabien perigaud/synacktiv. your beerump 2017 presentation slides started me on this journey.
// (sure you redacted the fun stuff, I just rediscovered it myself)
// also shoutouts to everyone involved in BCM2708 reversing!
// greetings to elites, fuckings to lamers (second category includes broadcom and rpi foundation)

??=include <stdint.h>
??=include <stdio.h>

typedef uint8_t u8;
typedef uint16_t u16;
typedef uint32_t u32;

u8 vce_data[] = {
0x54, 0x6f, 0x76, 0x6b, 0x94, 0xce, 0x1a, 0x57, 0x56, 0x51, 0x0c, 0xb2, 0x72, 0xc9, 0xc3, 0x12,
0x13, 0xbc, 0xe8, 0xd2, 0x5b, 0xa3, 0x2d, 0x2a, 0x5a, 0x62, 0x4d, 0xeb, 0x16, 0x40, 0x05, 0x87,
0xe0, 0x98, 0x39, 0xf7, 0xac, 0xc6, 0xab, 0x7c, 0xe9, 0xfb, 0x07, 0xaa, 0x29, 0xcd, 0x1d, 0x9b,
0xf6, 0x0e, 0x01, 0xbb, 0x5c, 0xfc, 0x15, 0xae, 0xd9, 0xfa, 0x9c, 0xef, 0xf1, 0x75, 0x8e, 0x70,
0x46, 0x8b, 0xb0, 0x89, 0x50, 0xaf, 0x6e, 0x67, 0x18, 0xda, 0xee, 0xd4, 0x32, 0xbe, 0x4e, 0x58,
0x5d, 0x1f, 0x4b, 0x73, 0x88, 0xc0, 0x79, 0x02, 0xde, 0x47, 0xa0, 0x43, 0x9a, 0xdb, 0xc8, 0x35,
0x95, 0x3c, 0xcc, 0x8d, 0x64, 0x2f, 0x14, 0x68, 0x00, 0x71, 0x03, 0xb9, 0xed, 0x0b, 0xf3, 0x24,
0x60, 0xb1, 0x17, 0x63, 0xdf, 0x48, 0x41, 0xa4, 0x28, 0x5e, 0x2b, 0xd8, 0xb4, 0x90, 0xba, 0x83,
0xe4, 0x08, 0xd0, 0xe2, 0xb8, 0x6a, 0x10, 0x74, 0x9f, 0x7b, 0x19, 0x38, 0x8f, 0x91, 0xd6, 0xa8,
0x27, 0x06, 0x30, 0x33, 0x61, 0x34, 0x25, 0x21, 0x53, 0xc7, 0x66, 0x23, 0xff, 0xc5, 0x80, 0x85,
0xf4, 0xd7, 0x97, 0x99, 0x55, 0xf2, 0x8c, 0x04, 0x6c, 0x4f, 0xa1, 0x36, 0x20, 0x0a, 0xe1, 0x44,
0x59, 0xcf, 0x7d, 0xb6, 0xf9, 0x0f, 0x6d, 0x11, 0x78, 0x93, 0xe5, 0x3f, 0xf0, 0x9e, 0x84, 0xd3,
0x7e, 0xbd, 0xd1, 0xf5, 0xa5, 0x81, 0x22, 0x37, 0xf8, 0x52, 0xe3, 0x5f, 0xa9, 0xca, 0xfd, 0x42,
0x7f, 0x09, 0xa2, 0x9d, 0x8a, 0xb7, 0x4a, 0xe6, 0xa6, 0x77, 0x3d, 0x1c, 0x2e, 0xcb, 0x1b, 0x69,
0xb3, 0x1e, 0xc1, 0x7a, 0x82, 0xdd, 0x2c, 0xdc, 0x49, 0xea, 0x3a, 0xe7, 0x31, 0x4c, 0xad, 0xbf,
0x0d, 0xc2, 0xc4, 0x96, 0x65, 0x26, 0xfe, 0x92, 0x86, 0x3b, 0x3e, 0xec, 0xd5, 0xb5, 0xa7, 0x45
};

??=define INLINE static inline __attribute__ ((optimize (3))) __attribute__((always_inline))

INLINE u32 GET(u32 var, u8 bits) {
return vce_data[(var >> bits) & 0xff] << bits;
}

// should probably use bitwise OR, but this is what the vce code does
INLINE u32 GET32(u32 var) {
return GET(var,24) ^ GET(var,16) ^ GET(var,8) ^ GET(var,0);
}

// vce has no rotate instructions, so it does it the long way as in C
INLINE u32 ROR(u32 var, u32 right) {
return (var >> right) ^ (var << (32 - right));
}

u32 codec_license_hash(u32 board_serial /* r1 */,u32 codec /* r2 */) {

??=define CODEC_XOR_BOARD_ROR(bits) codec ^= ROR(board_serial,bits)
??=define BOARD_XOR_CODEC_ROR(bits) board_serial ^= ROR(codec,bits)

for (u32 i = 0; i < 17; i++) {
CODEC_XOR_BOARD_ROR(1);
BOARD_XOR_CODEC_ROR(6);
CODEC_XOR_BOARD_ROR(13);
BOARD_XOR_CODEC_ROR(17);
CODEC_XOR_BOARD_ROR(21);
BOARD_XOR_CODEC_ROR(29);

board_serial = GET32(board_serial);
codec = GET32(codec);
}

??=undef CODEC_XOR_SHIFTS_BOARD
??=undef BOARD_XOR_SHIFTS_CODEC

return codec;
}

// This board serial taken from hxxps://web.archive.org/web/20221208160705/forums.raspberrypi.com/viewtopic.php?t=38901
// The person who owns the SoC with this serial burned in fuses did a nice thing and provided their own WVC1 + MPG2 keys, we can use that to verify this implementation is correct:
// decode_MPG2=0x6fd66307
// decode_WVC1=0x01a512b0
??=define BOARD_SERIAL 0x9d3e8cb1

void main() {
printf("??= VC1 key\ndecode_WVC1=0x%08x\n\n", codec_license_hash(BOARD_SERIAL, 0xf00bad34 ^ 0x57564331 /* 'WVC1' */));
printf("??= MPEG-2 key\ndecode_MPG2=0x%08x\n\n", codec_license_hash(BOARD_SERIAL, 0xf00bad34 ^ 0x4D504732 /* 'MPG2 */));
printf("??= Super-secret key ;)\n??=\n"
"??= start.elf, before booting ARM, reads bootsig key from efuses, then compares against 1/2 of 5 hardcoded keys.\n"
"??= If not equal, then this key is checked, if not correct then infinite loop + LED flash\n"
"??= (same as if 3rdsig -- ARM kernel binary HMAC signature -- verification fails)\n"
"??= As to *why* this is done, I have no idea. Bootsig key is also 128-bit HMAC key and this reduces the available\n"
"??= possible entropy for unique bootsig key (necessary for boot-time security I would think!) down to either\n"
"??= 51, 52, or 77 bits depending on what key was burned into your Pi's efuses...\n"
"decode_0001=0x%08x\n\n", codec_license_hash(BOARD_SERIAL, 0xf00bad34 ^ 0x30303031 /* '0001' */));
}

Shared by my Daughter
"I need privacy, not because my actions are questionable, but because your judgement and intentions are"

In response to "if you have nothing to hide you have nothing to fear"

Weihnachten im kleinen Kreis

Christmas in a small circle

#Covid

rust programmers be like "pretty slow, nearly a microsecond"

Hitachi HDD: Z7K320-250 / 250GB / SATA 3.0Gb/s.
Data erasure method: 50lb Longbow, two arrows at 15 yards.

i wish all "header that reappears when scrolling up" web designers a very happy i am behind you, make peace with your gods

Bye bye, Birdie! #kaengurucomics

So Phoronix put out an article saying Asahi Linux got slower over the past few months, but I tried a few tests that supposedly regressed and I cannot reproduce it.

For example, on ALS movie lens, his results are 7581 and 12132. I got 7615 on my M2 Air (less is better). On zstd comp L3 long, he got 265 -> 245, I got 278 (more is better). L3 short, 3620 -> 3420, I got 3567 (more is better). GIMP unsharp-mask, 14.97 -> 18.97, I got 14.93 (less is better).

I'm not sure where the variance comes from, but I don't have a whole lot of confidence in his results. If you identify a specific regression traceable to e.g. specific kernel versions, please let us know - but otherwise take Phoronix' results with a grain of salt.

I did notice that a lot of the tests I was running (that supposedly regressed) were ostensibly CPU tests and were spawning >8 threads but then not able to use all 8 CPUs fully (sometimes only 50% or less), which is unexpected for a well-designed CPU-bound test. That tells me there are synchronization issues or other problems that prevent the tests from fully utilizing the hardware. This is even more important on big.LITTLE platforms, since you can end up with the OS scheduling critical threads on the efficiency cores that end up blocking the performance cores (the OS has no way of knowing which threads will take more time or are the critical ones, to put them on the faster cores). When you have stuff like that going on, it can add a lot of uncertainty and noise to your measurements.

Also remember that the M2 Air is a fanless machine and therefore affected by ambient temperature, surface, and surrounding airflow, since it can throttle when fully utilized.

Edit: I could repro the cryptsetup PBKDF2-sha512 post-regression results. That one uses system cryptsetup, so it's likely a code/compiler change that legitimately regressed performance of that binary in Arch Linux ARM, nothing to do with our kernels or anything Asahi-specific.

Things we didn't do:
- Start the fire
- Shoot the deputy
- Steal the cookies from the cookie jar

Things we did:
- Tried to fight it
- Shot the sheriff
- Put the sham in the shama-lama-ding-dong

Things we will do:
- Survive
- Rock you
- Walk 500 miles
- Walk 500 more

Things we won't do:
- Get fooled again
- Back down
- That

Things we will never do:
- Give you up
- Let you down
- Run around
- Desert you

(Oops:
- I did it again)

Okay, so let me tell you about my doorbell, from a #networking perspective.

When you push the button by the door, it sends a message over the #zigbee wireless mesh network in my house. It probably goes through a few hops, getting relayed along the way by the various Zigbee light switches and "smart outlets" I have.

Once it makes it to my utility closet, it's received by a Zigbee-to-USB dongle, through a USB hub (a simple tree network) plugged into an SFF PC. From there, it gets fed into zigbee2mqtt, which, as the name implies, publishes it to my local #mqtt broker.

The mqtt broker is in the small #kubernetes cluster of #raspberrypi nodes I run in my utility closet. To get in (via a couple of #ethernet switch hops), it goes through #metallb, which is basically a proxy-ARP type service that advertises the IP address for the mqtt endpoint to the rest of my network, then passes the traffic to the appropriate container via a #linux veth device.

I have #HomeAssistant, running in the same Kubernetes cluster, subscribed to these events. Within Kubernetes, the message goes through the CNI plugin that I use, #flannel. If the message has to pass between hosts, Flannel encapsulates it in VXLAN, so that it can be directed to the correct veth on the destination host.

Because I like #NodeRed for automation tasks more than HomeAssistant, your press of the doorbell takes another hop within the Kubernetes cluster (via a REST call) so that NodeRed can decide whether it's within the time of day I want the doorbell to ring, etc. If we're all good, NodeRed publishes an mqtt message (more VXLANs, veths, etc.)

(Oh and it also sends a notification to my phone, which means another trip through the HomeAssistant container, and leaving my home network involves another soup of acronyms including VLANs, PoE, QoS, PPPoE, NAT or IPv6, DoH, and GPON. And maybe it goes over 5G depending on where my phone is.)

Of course something's got to actually make the "ding dong" sound, and that's another Raspberry Pi that sits on top of my grandmother clock. So to get *there* the message hops through a couple Ethernet switches and my home WiFi, where it gets received by a little custom daemon I wrote that plays the sound via an attached #HiFiBerry board. Oh but wait! We're not quite done with networking, because the sound gets played through PulseAudio, which is done through a UNIX domain socket.

SO ANYWAY, that's why my doorbell rarely works and why you've been standing outside in the snow for five minutes.

I came up with this cursed thing while half-awake one early morning.

I feel like @NanoRaptor would approve.

Surely this can't be true... #AdventOfCode as a virus scanner?

https://www.reddit.com/r/adventofcode/comments/zb98pn/2022_day_3_something_weird_with_copypasting/

IBM ThinkBoy

The Floofverse™️

For anyone interested in the future of ActivityPub (the protocol which underpins the Fediverse), I posted a message to the (recently revived) W3C SocialCG mailing list with my thoughts on protocol evolution topics that I think are essential for us to work collaboratively on in some form (whether within the SocialCG, within a freshly chartered ActivityPub WG, or something else) in order to ensure the propsperity and health of this platform

You can find the post in the archives, though I've reproduced it below. The SocialCG can be found here

--

Eight (!) years ago, I kicked off what became AcitvityPub with an e-mail to the SocialWG mailing lists linking to a draft of a protocol I named ActivityPump; I hoped but never imagined it would end up being quite so influential.

It's been nearly four years since the ActivityPub specification was published, and never has it felt felt more urgent that we find a way to revisit aspects of the standard together. None of what follows is in any way gospel, these are just my thoughts; but I feel one big thing we've been lacking is direction and this is an attempt to give that

--

The challenge, as I see it, with developing anything involved in the social web, has always been that everyone's developing their own thing. That's really exciting, and it makes the ecosystem incredibly vibrant, but it's also quite troublesome, because you end up with 15 people working on 15 different things, rather than working towards a cohesive whole. The ecosystem and the network have suffered from this; I feel like one of the reasons things never really got off of the ground here after the SocialWG closed is that there was no obvious direction.

So I would like to suggest that we pick themes to work on - one initially, with scope to add more as those are established. Perhaps these might eventualy feed into the charter for any future ActivityPub WG. We should, in general, try and focus on areas causing user issues or friction in the network today.

I think there's a general sentiment across the fediverse that our biggest problems are to do with inadequite tools to handle moderation and harassment. There's a mix of implementation improvements and protocol improvements that need to be made in this area, but I think it's important that we do the protocol development in particular outside the scope of any single project because it's the sort of thing which is likely to become a mandatory feature.

Some particular sub-areas of focus that I can think of:

Spam Filtering/Sockpuppet Prevention
Or: how to stop people from setting up new servers to bypass your blocks (without caving and resorting to allow-list federation)
I made a post about this yesterday
This one's a relatively complex addition, but I think it's vital.
Indirect Harrassment via Replies
Presently, threads are "backwards authenticated" via the inReplyTo field from the comment to the parent, but there's no forward authentication from parent to comment. Even if I block you, it's possible for you to reply to my posts, and while my server won't show your replies when looking at my post, other servers which saw your replies will.
I don't think allowing people to make "unapproved" replies is bad; but I do think that when looking at a post, implementations should de-prioritise such replies (think of Twitter's "more replies have been hidden" feature, which normally hides a bunch of cryptocurrency spammers)
I think this is a relatively straightforward protocol change, involving adding a way to indicate a post is in "approved replies" mode, and distributing those approvals. (I think Hubzilla has already implemented something vaguely - but not completely - along these lines)
Better tools for moderators
This is perhaps the least well defined point (and the one which, in some ways, requires the most implementer buy-in), but I really think we need to specify both the existing reporting protocol, and extend it to (a) allow withdrawing reports and (b) add coments, so server moderators can communicate with each other "in band".

I don't think this is the only topic area worthy of discussion, but I think it's by far the most vital. There are other areas I see as very important long term (e.g. codifying a way to move accounts without the cooperation of the server you're moving away from, simplifying the cross-server follow flow, and eventually supporting nomadic identities), but I think the solutions to those are less well defined, and the need is less pressing.

I'm very curious to see the group's thoughts.

(One other thing I think would be a good thing to do is to revise the AP spec and explicitly document the holes we left because we couldn't find agreement with actual practice; but that would be a task for any ActivityPub WG that is formed, which I would support)

tired: instance admins can read your DMs

wired: everybody can read your DMs

https://chaos.social/@zerforschung/109434915173065283