CanaryLayout

TL;DR: force them to learn not just systemd, ld, but also all of pthreads and the go runtime itself

IBM could sell the future of the on premises z/xxx boxes as "datacenter in one rack"

Running x86 in z/VM has been a discussion for 25 years. Just fucking do it. Let people run whatever they want.

Just as people are excited about ARM for low-watt computing, make s390x just as exciting for people who want insane vertical resources but using the same dev tools that are used now for easy x86/ARM crossover.

But IBM culture has always been about overcharging a small and rich audience and now they are sitting around hocking their services cohosted thru AWS and everyone who has COBOL and 360ASM running are doing retirements with no plans to use the boxes after its all unloaded.

And no, the paywalled IBM Cloud LPARs are a joke.

The mainframe is not a special thing anymore, hasn't been since the late 90s. It's just a server box.

I work at a shop with a z/14. I would love it if we finished the last COBOL retirements and go back to the mainframe but this time to run container farms, fresh Go code, and use thr power to run way deeper matrices of tests that take days to run locally and cannot afford to run on AWS.

If IBM weren't hostile to the Hercules project and allowed local licensing to run z/OS, CICS, IMS and DB2 on it, perhaps more hobbyists would want to careerpath themselves on to the s390 architecture.

I do love the s390 arch and the massive IO hardware over there, but IBM has paywalled down entry so hard that there is no audience.

They even went to the trouble of making Go binaries transportable for direct execution under z/OS. But if you want new people to write code on the platform you need to make access to the platform a thing.

Oh God why.

even easier is to STOP HOSTING SSHD ON IPV4 ON CLEARNET

at minimum, ipv6 only if you absolutely must do it (it absolutely cuts the scans way down)

better is to only host it on vpn

even better is to only activate it with a portknocker, over vpn

even better-better is to set up a private ipv6 peer-to-peer cloud and socat/relay to the private ipv6 network (yggdrasil comes to mind, but there's other solutions to darknet)

your sshd you need for server maintenance/scp/git/rsync should never be hosted on ipv4 clearnet where a chinese bot will find it 3 secs after the route is established after boot.

This does not matter either. The attack came in by loading into systemd via liblzma. It put on a hook and then sits around waiting for sshd to load in so it can learn the symbols then proceeds to swap in the jumps.

sshd is a sitting duck. Bifurcating sshd into a multimodule scheme won't work because some part of it still has to be loaded by systemd.

This is a web of trust issue. In the .NET world where refection attacks happen to commercial software that features dynload assemblies, the only solution they could come up with is to sign all the things, then box up anything that doesn't have a signing mechanism and then sign that, even signing plain old zip files.

Some day we will all have to have keys, and to keep the anon people from leaving they can get an anon key, but anons with keys will never get on the chain where the big distros would ever trust their commits until someone who forked over their passport and photos got a trustable key to sign off on the commits, so that the distro builders can then greenlight pulling it in.

Then I guess to keep the anons hopeful that they are still in the SDLC somewhere their commits can go into the completely untrusted-unstable-crazytown release that no instutution in their right mind would ever lay down in production.

any one of us if we sat on the OSSH team would flip the middle finger. What code is the project supposed to write when nothing on main dyn loaded liblzma. It was brought in from a patch they don't have realistic control over.

This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.

Exactly. The attack came in by hitching a ride on to systemd.

sshd is not the problem. the ldd/monolith architecture surrounding systemd is.

What if I duplicated this attack but instead targeted dbus or any other thing that systemd is managing?

Yeah Goroutines are great. Then add something like WebRTC to your project that realistically tops out at 10000 listeners, and people wonder why Twitter Spaces is so buggy...

Yeah... RISCV routine was put in, then some binary test files were added later that are probably now suspect.

don't miss out on the quality code, like the line that has: i += 4 - 2;

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=50255feeaab...

From what I read on masto, the original maint had personal life breakdown, etc. Their interest in staying as primary maint is gone.

This is a very strong argument for FOSS to pick up the good habit of ditching/un-mainlining projects where they are sitting around for state actors to volunteer injecting commits to, and dep-stripping active projects from this cruft.

Who wants to maintain on a shitty compression format? Someone who is dephunting, it turns out.

Okay so your pirate-torrent person needs liblzma.so Offer it in the scary/oldware section of the package library that you need to hunt down the instructions to turn on. Let the users see that it's marked as obsolete, enterprises will see that it should go on the banlist.

Well isn't this an interesting commit. He finished his inject macro to compose the payload at build, so now he can start clearing up the repo so none of that shit gets seen when cruising through it.

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=4323bc3e0c1...

Some links (and more alt keyboard layout propaganda)

*Discord Servers* Alt Keyboard Layouts- <https://discord.gg/2qq8qmDtFf> Same but on matrix - <https://matrix.to/#/!iZdsjIZXWPXnohYGdD:matrix.org> Dvorak - <https://discord.gg/yHydf7FWTp> Colemak - <https://discord.gg/3VsHDG86hM> Monkeytype - <https://discord.gg/FcjrA7pBpG> Rus Keyboard Layouts - <https://discord.gg/QmAbR3tGpz> Babymak (not a joke) - <https://discord.gg/frtQHGrNwm>

Oldie but a goodie. More people should check out Ben Vallack, who takes working ergonomics hacking to an extreme degree. He inspires lots of modifications that I make to my own work+keyboarding habits.

The extended vacation periods that people tend to take at the end of the year (and the start of New Years Resolutions) is a good reminder as any that you can take advantage of this time to improve your personal productivity by switching away from QWERTY to a new keyboard layout, as well as changing your keyboard switch type and physical board.

Is it time to learn how to use layers (and put those programming symbols under your faster fingers)? QMK/ZMK firmware perhaps? What about programming your keyboard for combos+macros to speed up your work?

A big reward in doing all this is, of course why else: comfort and the promotion of lazyness. Maybe a combo to pop up a terminal and reattach to a tmux sesh, or a digital dashboard or to tail -f a log that you have to stare at often?

Switching layouts to better ones that lower your hand stress allow you to type for far longer before feeling tension. There's also many more layouts than just Dvorak and Colemak. Canary is a very good high-rolling layout that feels butter-smooth and flowy when typing at high speeds.

Guess by the time it starts it will just be the jihadi VCs...

https://twitter.com/garrytan/status/1713937044798603313

Mostly to pretty it back up into the original shape (so it matches what was already in git)

Over a week ago news got out that cheap cloud hoster Cloudzy is really a front for an Iranian company abrNOC. The full rundown of the research is here: https://20688644.fs1.hubspotusercontent-na1.net/hubfs/206886...

I feel really duped. Let's just go directly into the politics of it: Iran is embargoed because it heavily funds terror groups. Hezbollah, when it's not busy trying to meddle in Israel, has ruined Lebanon for the last 43 years.

For the little money I spent to run a rprox there, even if was just a few cents of that, funneled though abrNOC, to the Tehranian government in taxes or transfer fees--it makes me absolutely ill.

And Cloudzy is still out there, duping people that it is a legitimate ISP.

Two weeks ago I noticed my now-terminated VPS with them had its internet access slowed down considerably. When I ran speedtest-cli to see what was going on, I noticed packet drops. To Amazon. Cloud-to-cloud packet drops?

Then after the publication of Cloudzy as a rat's nest of state-sponsored CNC bots, suddenly none of my DNS resolves to the VPS worked anymore.

It took me a few hours to realize that Cloudzy switched my VPS over to a completely different netblock. I went through my email. Cloudzy did not send any warning that the static IP the VPS I had was a "just kidding; it's not static" IP. It was this sudden relo of the IP that caused me to look and 20 minutes later, to my horror, I discover that my cash is going to a rando dude in Tehran.

I ran speedtest-cli after the network change, and then the closest responding server showed up to be QuadraNET (where I already rent physical). Cloudzy also claimed my VPS was in Dallas, but going from the ping time it was way more likely relocated to Los Angeles in the unannounced net change.

At this point, I didn't care to dig any further.

I just finished moving my bits off Cloudzy and shut it off. The US State Department and FBI will eventually come for their DNS. I feel bad for any of the legits who are on there who still don't know how much risk their bits are in.

I think you're asking this question because you're wondering if a container that uses environment variables for its configs would show up in this and I think the answer would be no because it's an operating system service that supplies the answers for the values, but every developer on Earth copies the values into variables where there is going to be a pointer put on a register at some point which then would make it vulnerable

This is terrifying.

You could hijack a user that has SAPGUI open, then push code updates to SE38 that spread everywhere.

Yes. And Linode. And Quadra. And OVH.

A lot of people on YC are enterprisey-brained and only think there are 3 possible clouds, and then there is the rest of the planet who can't afford to park their cash at AWS and set it on fire.

If you throw in the same vulnerability that AMD has with the list from Intel I think it pretty much covers every server available for rent at Quadra.

This concern I also share and it's probably worth converting into layman's terms so that all computer users understand what it is. Basically the job scheduler Behavior in the OS needs to surface to the user with understandable language they can read so they can make the trade-off decision.

Think of all the cloud resellers that are out there who really aren't segregating their tenants out or it's just a web shop with proxmox who recombined their own customers onto a core even though the cloud provider specifically segregated it

They have workarounds. If you prevent multi-tenant from sharing their threads on the same core, that eliminates the most desirable goal of an attacker.

However it does not eliminate the vulnerability within a single tenants own threads.

You also have to think about all the web shops that are out there that are just running proxmox or a cloud reseller who reintroduces the vulnerability in their multicore VPS setup

The OS job scheduler informs the CPU when it's ideal to swap jobs. But the OS is not doing the work of moving the register and stack pointers, the microcode is. These timing attacks take advantage of shared information in the cache (where it's likely the context of the thread you are not supposed to be able to read is).

SMT (hyperthreading) introduces some ambiguity when the context change is going to happen, and it appears there's instructions that are callable where registers/mem can be read that were outside the calling context.

On a certain level this is like arguing that you will never see this problem in an Arduino.

I mean, sure. On many levels and planes you are correct, but not where any of the intersections matter.

AMD has the same problem (Inception). Predictive instruction pipelining makes timing and context separation harder. Even if you are on s390x or M1 it's not like you are safe either. This is a whole field of study.

In my mind the better mitigation is to put control over trusted code back to the user and to do that you have to add less-performant cores onto the die and force the operator to elevate (or not) to SMT.

Right now it's an all-or-nothing proposition for the whole board. I would like to think that you can take your untrusted code and stick it on the less-performy cores with the safer instruction pipelining scheme so an actual physical barrier exists.

If that was in the chip architecture, then it's up to OS vendors to surface it in a way that developers understand, and then down to the operator to decide upon configuration.

You are never going to get a perfect-solve from the chipmakers on this where the consumer has to do nothing.

Aren't system designers at fault for coming up with the idea of a context switch

Context switching was in the Apollo 11 guidance computer https://www.youtube.com/watch?v=xx7Lfh5SKUQ

The problem is that cycle-speed boosts left the industry cic. 2012-or-so. All the perf boost we get these days is by optimizing the instruction sequencing and multiprocessing. This is why languages like Go popped up (making the advanced programming topic of multiprogramming an entry-level accomplishment) and you now see the 'async' decorator plastered everywhere in C#, and so-on.

Keeping the security context intact and separated is a gargantuan task.

To me it makes more sense to add "lousy cores" to the die and force the operator to declare the launching threads are safe for SMT, else the job gets scheduled to the less-performing core where the pipelining is safer. It delegates responsibility to the chip-gobbler, forces them to understand the tradeoff for performance, until some elegant solution is found for side channel attacks like this.

You install App X from Vendor Y on to vSystem Z.

Vector is found to get untrusted code C to run in the user area on Z via exploit in X that Y has not acknowledged, so researchers publish a CVE with an example.

C starts trying to read memory from threads shared on same vCPU, revealing db connection string used by X, the nonce and salt for hashing.

Attacker now has the keys to the entire kingdom.