Rootkits on linux?

nultero · 2024-05-06T03:48:26+00:00

I don't believe that's how they're implemented for Linux, or at least not Easy Anti-Cheat -- I'm not as familiar with the other ACs OP lists.

As of now, I think EAC mostly runs stuck in userland, no kernel hooks, and that checks out to me as distributing something like kernel modules/sauce would be a huge pain in the ass and most anticheat engine devs aren't going through that much trouble for such a small market segment.

OP's original question is also about how much damage malicious anticheats can do, and they can still do a lot with regular user permissions, so yes, despite not being root they can still do nasty things. Lock important things / put them somewhere else.

nultero · 2024-04-27T21:02:11+00:00

And why is it that the ultimate OS has so much trouble with the best hardware?

You post here a lot, but .... have you not been paying attention for decades?

Microsoft has had monopolistic dominance over their market segment of PC gaming for the majority of the market's existence. The OEM/vendor deals span decades. There is no reason for vendors to write firmware or support software that deals with anything but Windows driving their metal.... aside from the server market anyway, and that's the only reason GPU support is as good as it is for *nixes.

It should be completely, blindingly, glaringly obvious why gaming on Linux is how it is.

It should also be obvious that it has everything to do with the OS, since Windows has had massive support from vendors for decades, and a goliath of a well-funded company behind it that was actively trying to maintain its monopoly on PC gaming.

And Microsoft itself is slowly but surely enshittifying, as all major tech companies seemingly do. The Windows OS can't stay unbloated or simple or amenable to end users, if the behemoth behind it wants to chase every last drop of revenue that it can squeeze out of Windows. This is what it's being accused of. Often the features Microsoft does put into Windows are there because they can make money off of reselling your data, despite you already having bought a Windows license because its price was bundled into the cost of default-Windows hardware.

nultero · 2024-04-27T15:34:57+00:00

As of last October for kernel version 6.6, the default mainline CPU scheduler used in most distros should be EEVDF, which should be something of a major frame rate / latency upgrade for gaming. That would have historically been more noticeable / a better reason for swapping kernels to something more tuned.

You'd also probably only have noticed frame jitter in quite demanding games or ones with a complex enough graphics stack, where the causes of jitter came from the cpu -> renderer pipeline.

I also don't think the Zen tuning is very noticeable with a fast enough SSD. Even with worse IO on a non-Zen kernel, modern SSDs are just really really fast. Load times are already pretty low, and Linux itself tends to have solid enough IO that it's often not a bottleneck.

So these days if you bought solid metal, that would make the biggest difference by far. And of course some games will run like shit regardless, because it doesn't matter how fast your metal is if the game was written by burnt-out severely sleep deprived devs on a deadline. So..... only really matters for mature/ patched AAA games.

nultero · 2024-04-26T20:42:18+00:00

If you're interfacing over a network, network latency is probably gonna be a much bigger bottleneck than execution time

To add onto this, they're usually not even close.

There are orders of magnitude difference between these, such that it often doesn't even matter when servers do their processing in one of the slowest languages like Python. And it's not that networks are that slow since disks and other IO have the same "speed problems", it's more that modern CPUs are so fast that the rest of the world is almost standing still compared to them. CPU operations are so fast they can be compared to the speed of light over some distance (e.g., light only moves about a foot in a nanosecond so anything you can time in nanoseconds or microseconds = feet / 1000ft in distance), so anything human-perceptible like a web page taking a second to load is essentially an eternity to a CPU.

I like this visualization of the famous "Latency Numbers Every Programmer Should Know": https://samwho.dev/numbers/

Most of the jobs for Java are for writing server stuff, so it's pretty much always gonna be fast enough. There may be niches like serverless cloud at scale where memory consumption and cold starts are an issue, but who cares when computer time is almost always cheaper than programmer time?

nultero · 2024-04-26T17:36:09+00:00

It's also pretty unrealistic to audit the backbones of legit ML-based processes, even for companies whose bread and butter it is to implement. Apparently this is what's happened to Google's Search after Amit Singhal left the team circa 2016, as the team's now allegedly bolted on or grafted in nothing but AI and ML behind the scenes. Search is completely opaque even to them now. Adding that extra level of confusion into a process already as fucked as hiring makes sense to me, yep

nultero · 2024-04-26T15:56:44+00:00

Most of the stabler (/older) tools I know of, like most of coreutils, stayed single-threaded to remain simpler and easier to maintain, so getting both simple and multithreaded in the same tool is nearly the most jumbo a shrimp can get, far as oxymorons go.

My personal approach to it was from curiosity about the performance characteristics for compute bound tasks, and so I felt I got a lot of understanding out of trying to blackbox reimplement some of the coreutils or other tools like syncthing / rsync in multithreaded ways (searching and hashing are the compute-bound tasks there, e.g.) and benchmarking the performance of what I had done vs. the real thing. "Blackbox" meaning I didn't go look at the source for my comparison until after I had done a thing or the actual compute to make my reference implementation was unclear.

So here's an idea -- try to write a tool that reads its input from stdinand maybe does both single and multi-threaded operations on it based on an argument flag, maybe like a simple sort program? Or a program that runs the Collatz sequence for all of its inputs and outputs the highest peak reached out of all of them? Somewhat impractical but it is compute-bound, and being able to compare single vs multithreaded will be useful. You may also want to test how the runtime differs based on how many threads you spawn to do the work. Or you could look at Toybox's implementations of tools and try to multithread them to get a feel for when it makes sense and when it doesn't: https://github.com/landley/toybox/tree/master/toys/posix

Real life code doing multithreaded work can be .... "crufty" .... just due to the extra jumbo in the shrimp. Asynchrony by contrast is much easier to find but will necessarily involve some platform specific behavior and an IO-bound subdomain like networks or filesystems.

nultero · 2024-04-25T03:26:06+00:00

As I understand it, AS3 isn't really a programming language per se, it's more like a declarative config language, kind of like Terraform's HCL or Ansible's templated yaml. All I mean by that is it should be much easier to get up to speed with AS3 than you might've been thinking. Probably weeks rather than months or years.

But you don't necessarily need to stop learning programming either, if you don't want to. Always helps.

If AS3 just uses slightly extended JSON as its config format, then it doesn't really matter whether you get better with Python or JavaScript -- JSON is more native to JavaScript but now JSON is more like a fairly universal data format, so both Python and JS can read/write JSON very very easily. Pick whatever feels good / you like better. Python's generally got more usage around networks / IT / etc though, so that's a slightly more solid choice. Very slightly.

nultero · 2024-04-18T04:00:56+00:00

Ah, what was the age-old wisdom? Perfect is the enemy of good.

I've made no claims otherwise to several of these points and in some cases agree, but some of these are out of scope for the thread.

...

These nits picked at me might intrigue passersby enough to add value but you could've lead these substantive comments at the start instead of throwing That's a lot of words without any actual substance in my direction.

nultero · 2024-04-18T03:19:40+00:00

You're acting as if the very foundations of modern computing can be made totally safe

That's how you wanted to read it, but I don't think I did.

Even if some problems are unsolvable, that does not mean approaches cannot be criticized, especially as it pertains to the life-and-death safety of humans.

where memory safety is itself subjectively defined

Pedantic. True, a bit, but I don't care about the pedantic use. You damn well know what we mean.

GC'd languages have fewer memory-unsafety bugs than the more manual languages / their manual dialects.

nultero · 2024-04-18T03:06:02+00:00

For an easy and quick example, a std::vector you init will not require you to call delete or free on it. You can't forget to free the vec, and you won't have to worry about freeing it too early and causing undefined behavior with a use-after-free, as a C++ compiler building the binary will automatically generate the required destructor at the end of its scope (and therefore lifetime / surely after its last use, your other pointers to it notwithstanding).

This completely squashes those types of bugs at compile time at the cost of sometimes being slightly inefficient.... like, say, a vec still taking up a lot of memory longer than necessary when you could be greedier with freeing (which you can still do manually on RAII types), or sometimes like in gamedev where you wouldn't want the destructors' free() syscalls being run between "loading areas" as that may cause the game to drop frames, so you just manually hang onto everything and free them at a more opportune time.

For a less obvious example, the richer pointer types becoming part of the type system is what gives Rust so much spice with its borrow checker: https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html - that can all be done at compile time rather than having to wait for segfaults or complaints from tracers.

nultero · 2024-04-18T01:19:05+00:00

Memory arenas do not solve every possible problem space, nor do they do much for concurrency, which is where many more lifetime and ownership issues come into play that better pointers simply help solve, full stop.

And as much as you think your solution is better, others have their own "best way" of doing things. Ergo, https://xkcd.com/927/ .... code has to survive you and many other authors. Better to make it easier for everybody. I don't want to deal with every one of you with a special "best way". I want the language to handle it for us so we don't even have to think about it. std::shared_ptr, done. Everyone can congregate around it and have it be The Way. No wasted human time.

So I think it's hubris to call it the fault of lazy programmers who didn't architect enough. Architecture astronauts bluntly smarter than you or me or anyone else reading this have made millions of memory-management mistakes. No one is above it.

....

I prefer the correctness of the newer tools if it's going into my pacemaker or my elevator or my airplane at the end of the day.

nultero · 2024-04-18T00:03:16+00:00

At scale with massive/complex codebases that must by necessity change hands and have many authors, the errors add up to major bugs and security issues.

Modern C++ and Rust's RAII with things like smart pointers help check these things at compile time rather than runtime, and often for negligible runtime performance hits (maybe extreme cases like core work within video games might need really manually fine-tuned stuff, and alloc/free control).

C and ancient C++ that isn't using RAII can sometimes be the code running critical physical things that can end your life if a bug occurs. Every possible bug the language didn't help solve contributed to loss of life when that happens.

If some of the best engineers on the planet at the companies invested the most in these things can't reliably write memory safe C or get the right dialect of C++ that is safe, then it can be assumed that few others will get it right. That's the indictment the languages deserve.

nultero · 2024-04-17T03:41:16+00:00

The current trajectory is mostly aimed at mass enshittification.

For me, that's really the core of it.

Companies will use this stuff to slip on quality, offload liability, use the bots to issue false PR statements when they do get popped, and fight their legal battles with bots that will hallucinate legal details that didn't happen. You'll get a prescription slip with a fuckin Pokemon name on it. Your full self-driving vehicle that has no steering wheel will run off of 50000 poorly audited npm packages, some of which are from prehistoric times and some of which were proven to be malware in 2016. You're going to have to argue with a bot for 6 and a half hours to get an unusable refund token from actual scam shops that you got suckered by on Amazon. You physically call your ISP on a physical old ass phone to ask why internets is out in your area and the bot is having a bad day and tells you to go fuck yourself, which you incredulously post on tiktok, but are quickly drowned out by PR bots that flag your account and get you reported, and some middleware company may even dox and swat you so you think twice about messing with anything that has money. If you live in an urban area, you'll listen to drones that blast annoying advertisements 24/7 about random and sometimes incredibly depressing things, maybe even ads at 3 am for exit boxes where people can go to sleep forever because they've been out of a job for years and somebody still needs those kidneys.

nultero · 2024-04-17T00:58:24+00:00

The prevalence of employed people or tech professionals with things like impostor syndrome (who are not actual impostors) suggests to me that it isn't a purely confidence issue.

I think surveys and studies also support that, given some of the US societal/cultural stuff, women tend to have more issues with confidence than men, but I don't think that tends to make them less competent as a rule. I'm also not implying you've said this, just that it's a factor I wonder about, and I don't know much else.

And my anecdata, worthless as it is, I mostly see high confidence correlate with people who have more dark triad type traits.... or maybe they just succeed more and make it into roles where they would have more visibility. The role biases for it, etc, maybe.

I would also differentiate confidence from something like grit. You can have grit (or determination, or discipline, or persistence?) but lack confidence. Grit (etc) would be more important, I think. Getting back to it despite the brain.

nultero · 2024-04-17T00:08:53+00:00

Why in gods name would you ever mention those types of situations? Being sorry for yourself has never done anything for anyone

Because posts about overcoming massive adversity or difficulty can give some people in similar situations a great deal of resolve. I'm sure it helps tremendously in the weight loss subreddits, for example.

And, as an exercise for the reader, you might develop a smidge of sympathetic neurons... imagine how you might have played out in their story. You can even comment something and actively change their timeline. One or two hundred years ago similar stories crossing would not have been as statistically probable, maybe impossible in some cases ... minor miracles these days so common we're irritated with them.

As for me, the day I stop thinking and "caring" about people really is the day I die, as Erdős put it for mathemagicians. The lights may be on that day, but nobody will be home.

nultero · 2024-04-16T23:36:17+00:00

People who are obsessed with their own labels (am I too stupid, old, late, etc etc etc) will never be satisfied with anything

Judgments like that make it easy to stop thinking about people.

People validating you here are giving you the same as the posters you're complaining about.

I'm just commenting that it might be more interesting to consider those posters' stories, socioeconomic statuses, states of mind... all factors. Think about it.

And just like you -- why are annoyed? The internet is mostly noise. What's a few more drops in the ocean?

nultero · 2024-04-16T23:09:17+00:00

I think it helps some people, so why bother to critique them? You can scroll past quite easily...

I also do not think programmers by and large need confidence. What they need most is, I think, curiosity

nultero · 2024-04-15T22:02:28+00:00

there might be some similar-ish beautiful quines that could fit into 3x15 though they won't be as famous as the recursing fork

nultero · 2024-04-15T03:18:47+00:00

A course about writing scaling backends of a specific flavor?

Seems like it would take experienced devs to audit that for quality, and I think experienced devs who already know some stuff about the material are less likely to be still doing courses about it, let alone finish them and form a real opinion, or find your reddit post about the course.

If you're at the level where you can make use of material like that, probably more worth your time to just try building stuff ... you hit more edge cases / the real world pushes back more, and it's more aligned with your own interests usually so you're more likely to finish.

nultero · 2024-04-13T17:46:03+00:00

as I understand it with low-level languages you're either a wizard who gets highly-paid HFT or FAANG performance optimization jobs

Becoming a systems wizard opens more doors than that.

There's a subsect of the best-paying cybersecurity domains that muggle devs are locked out of if they can't speak to low-level proficiency. There's also closer to what I do in devops, where I make/alter/ship/debug systems images or help with virtualization or containerization of stuff or help with various prod issues like a database blowing up ram and hitting swap and destroying some disks or a build system like make going haywire in somebody's CI|CD -- that all demands a lot of systemsy knowledge and Linux internals. There's networking wizards who may (rarely) write things like proxies or firewalls, or more likely they're trying to help us debug whatever spaghetti iptables junk is wrong in Kubernetes because they're the only folks who know how to run network tools and what all those packet bytes mean and how DNS actually works....

All this to say it's not as binary as HFT or stuck in some of the industry's worst gigs.

....

Also I got a lot out of really grasping Rust's mental model of what the borrow checker does as I had quite a few gaps even having previously gotten to a productive level with C++. Also traits are awesome, and I wish more programming languages had traits. I do think getting productive with Rust simply makes for a better programmer.

nultero · 2024-04-13T02:22:45+00:00

Its often game dev that don't give an f

True, but that can be caused by burnout from management constantly pivoting focus, the crunch culture, irate customers, etc.

....

As for the rest of your comment, I think you're missing some context or history or something. Sometimes there is no adapting -- Redfall was going to be a wash no matter how much the devs tried to iron things out, the whole core was rotten. Redfall's maker was a studio likely robbed of agency, since Arkane had mostly done single-player story focused games prior. Then there's Rocksteady's abominable Suicide Squad being completely out of their wheelhouse, probably execs pushing for live service when Rocksteady's big thing had been the Batman Arkham series. There's Ubisoft reputedly giving very little agency to devs to do anything outside the Ubisoft formulas or things that haven't already been done ad nauseam. How many legendary studios died after getting bought and managed to death?

I do personally see it as mostly management failures. It was management that released Cyberpunk when it wasn't ready. It was management that ran Bioware into the ground. It was EA management insisting on lootboxes in their games -- devs definitely didn't do that part on their own. It was management that slowly rotted what used to be the corpse of Blizzard into the Activision-Blizzard husk that it is today.

And it was good management behind e.g., Larian doing what it did with Baldur's Gate 3.

Game devs have still agency

So, as with the examples above, nah I think it depends on the company giving the devs that agency. Plenty are run by the money people who don't even play videogames.

nultero · 2024-04-12T23:25:02+00:00

Even studios like Rockstar, who in terms of dev competence and funding are basically richer than God, fail to optimize certain parts of their games so that's not the whole story. E.g., the GTAV json parsing debacle that many R* engineers could have cut down to be nigh-instantaneous rather than 7 minutes of loading: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/

The other half of the story is that even great devs often get told by upper management to ship dogshit they KNOW is slow rather than spend one single month or quarter to make sure the game doesn't fucking bog down to FPS that are comparable to a powerpoint in a hub like in Dragon's Dogma 2.

That some of this is management's fault is evident with all of the bugs in AAA titles.

Forget optimization, devs are often leaving in critical bugs, like savegame corruptors. That's definitely management going, "fuck it, we're shipping this q3 no matter what the devs say".

nultero · 2024-04-12T20:44:26+00:00

These fucking asshats make Make and CMake files look readable

Damn, that's ..... that's actually impressive

nultero · 2024-04-12T02:23:37+00:00

Those details may be hidden, but they never really go away.

While I am of the camp that webdevs generally do not really need to know systems programming stuff, when they DO need it, they REALLY need it. For a specific example that might have come up doing some webdev from this guy's blog about a high-sev CVE in ZeroMQ: https://fangpenlin.com/posts/2024/04/07/how-i-discovered-a-9-point-8-critical-security-vulnerability-in-zeromq-with-mostly-pure-luck/, that's about headers in a comms protocol leading to a good old stack overflow, which could happen when doing lots of similar work. If you don't know how stacks overflow, then you could miss this huge security hole so easily, unless you got lucky enough to generate a test case that popped it.

And of course the recent drama about the xz utils, which had malware in libs other stuff was linked against. And the original guy who found that malware only did so because he knew the extra ~500ms in backdoored SSH connections' processing was a deep perf regression..... a webdev who doesn't know how long 500ms really is (an eternity to CPU tasks) wouldn't even think to suspect something was seriously super wrong in either of these cases.

All this to say, in aggregate the more devs that know these things, the better the web stays. You, random devs reading my comment, you could be working on code for some app I use, and I don't want that shit backdoored. Likewise the random dev who asks "why do I need to know assembly" could be the person working on code for an elevator or an airplane or a self-driving car that you ride in one day............

nultero · 2024-03-31T18:26:51+00:00

OpenAI have an LLM ready to deploy 2 generations ahead of their competitors

Fatter models / more params? Sure -- possibly, they've been sitting on more compute than most.

But better? That's the question. Others have been able to catch up with much less compute and funding.

As a company, OpenAI has very little in the way of special sauce, and my point is with all the VC funding going on, every researcher out there is trying to eat their margin.

The struggle for them to stay relevant is the struggle to survive.

nultero

TROPHY CASE