It’s part of the MSVC x64 ABI, not a part of the kernel ABI. The kernel and user mode (Win32) APIs all use C linkage so vtables are not relevant and the ABI is a convention of the compiler not the OS. Practically speaking though if your software runs on Windows it will probably use the MSVC ABI.
Last time I checked, software compiled with both Cygwin and MSYS2 internally uses SysV calling convention, only switching to WINAPI when calling, well, Win32 API.
It is more complicated than that. MSYS2 isn't just Cygwin. It has different environments.
MSYS environment is just Cygwin and it uses Itanium IIRC for C and C++ non-Win32 calls since it emulates POSIX. If it links with Windows C runtime they use __cdecl. Win32 API calls always use __stdcall convention / ABI.
However, Mingw environments (Mingw64, UCRT, CLANG etc.) are intended for native Windows development, hence, they use normal MSVC __cdecl ABI for C library calls and internal function calls too. Win32 calls are again __stdcall.
Unlike C, for C++ all MSYS environments use Itanium ABI since they link with GNU libstdc++ or Clang libc++. I think it is possible to use MSVC C++ ABI with Clang but it could be complicated since it requires recompilation of at least libc++.
Firmware & systems dev here, ARM still dominates in the microcontroller space. There are some niche offerings from major vendors but again they are niche. Espressif is the sole exception with their newer ESP32-C series chips, but they can get away with it due to their massive HAL. ARM Cortex is still the standard because there’s a decade or two of inertia behind it.
An apt comparison would be C vs Rust. Yes, Rust may be growing in market share, but C still dominates.
I'm a fellow embedded dev and I agree, arm is still ubiquitous in all applications I've worked on in the past 10 years. I've used the rp2350 in a commercial application recently and whether or not we'd ignore the risc-v cores wasn't even a question. As a hobbyist however I'm glad that they're there!
Just a nit-pick: risc-v isn't limited to the ESP32-C line. All of their chips are risc-v except the OG/S/S2/S3. A few years ago they've stated that the S3 would be the last xtensa chip and they seem to have held to that, the -E, -H, and -P lines released since are all risc-v.
It's not just Espressif's ESP32-C series, it's all their new offerings. The low-end ESP32-C2, C3, C5, C6 and C61, the high-end ESP32-P4, the base ESP32 replacement "all-rounder" ESP32-S21, the ESP32-H2. The last Xtensa-based MCU they released was the S3, 6 years ago.
The privacy points in general are valid, but what irritates me is using this rationale against kernel mode anti cheats specifically.
You do not need kernel access to make spyware that takes screenshots. You do not need a privileged service to read the user’s browser history.
You can do all of this, completely unprivileged on Windows. People always seem to conflate kernel access with privacy which is completely false. It would in fact be much harder to do any of these things from kernel mode.
Kernel access is related to privacy though, and its the most well documented abuse of such things. Kernel level access can help obfuscate the fact that it'a happening. However, it is also useful for significantly worse, and given track records, must be assumed to be true. The problem is kernel level AC hasnt even solved the problem, so the entire thing is risky, uneccesary and unfit for purpose making an entierly unneccesary risk to force onto unsuspecting users. The average user does not understand the risks and is not made aware of them either.
There are far better ways to detect cheating, such as calculating statistics on performance and behaviour and simply binning players with those of similar competency. This way, if cheating gives god-like behaviour, you play with other godlike folks. No banning required. Detecting the thing cheating allows is much easier than detecting ways in which people gain that thing, it creates a single point of detection that is hard to avoid and can be done entierly server side, with multiple teirs how mucb server side calculation a given player consumes. Milling around in bronze levels? Why check? If you aren't performing so well that yoh can leave low ranks, perhaps we need cheats as a handicap, unless co sistently performing well out of distribution, at which point you catch smurfing as well.
point is focusing on detecting the thing people care about rather than one of the myriad of ways people may gain that unfair edge, is going to be easier and more robust while asking for less ergregious things of users.
Counter Strike is a pretty good example that the statistical analysis alone doesn't work at all...at least not now. Valve has been collecting data since at least 2017 for their VAC Live system and it still doesn't work well enough to prevent or decrease the amount of cheating. The model only gives a cooldown of 20 hours if it flags your gameplay as irregular, and that cooldown resets over time.
It usually takes months, if not years for cheaters to get banned, but it takes a couple of dollars for a cheater to get a new account and start cheating again. Every time Valve fine tunes their models, they end up accidentally banning more innocent players in the process, so nobody has trust in that system anyways. There's too many datapoints to handle in competitive games, and there is no way to set a threshold that doesn't end up hurting innocent people in the process.
> There are far better ways to detect cheating, such as calculating statistics on performance
Ask any CS player how VAC’s statistical approach compares to Valorant’s Vanguard and you will stop asserting such foolishness
The problem with what you are saying is that cheaters are extremely determined and skilled, and so the cheating itself falls on a spectrum, as do the success of various anticheat approaches. There is absolutely no doubt that cheating still occurs with kernel level anticheats, so you’re right it didn’t “solve” the problem in the strictest sense. But as a skilled player in both games, only one of them is meaningfully playable while trusting your opponents aren’t cheating - it’s well over an order of magnitude in difference of frequency.
i searched "hacking in valorant" and found hella complaints about aimbotting and wallhacking. I can give you a simple way to make that work right now in a way that completely bypasses KLAC. Vanguard hasn't meaningfully solved the problem, and so my point stands. Something as simple as a webcam, a virtual controller, and a cnn can be used to construct a fully isolated aimbot. No memory inspecting anticheat will get that, klac or otherwise. Don't need to go that far though, since streaming means you can simply capture video output realtime, and better than realtime vision/action models exist. Its a project a skilled and motivated highschool student could easily finish in a weekend, in fact, im sure if you search something along these lines you'll find someone doing a video series on exactly this.
>This way, if cheating gives god-like behaviour, you play with other godlike folks.
Anti-cheat is not used to "protect" bronze level games. FACEIT uses a kernel level anti cheat, and FACEIT is primarily used by the top 1% of CS2 players.
A lot of the "just do something else" crowd neglects to realize that anticheat is designed to protect the integrity of the game at the highest levels of play. If the methods you described were adequate, the best players wouldn't willingly install FACEIT - they would just stick with VAC which is user-level.
I dunno man, at least give me the option? Like at least give me the option to play without klac with the exception i can join klac'd lobbies or something.
I mean, thats what Valve did. You are free to play on Valve's ranked ladder without KLAC. All the pros, semi-pros, and the people who want a cleaner ranked experience play on ESEA or FACEIT.
I doubt for other newer games the option would ever be worth it. Why host to servers and matchmaking pools for a tiny player base, who is will probably already be prone to complaining?
There is no need for irritation. I condemn all sorts of anticheating software. As far as I'm concerned, if the player wants to cheat he's just exercising his god given rights as the owner of the machine. The computer is ours, we can damn well edit any of its memory if we really want to. Attempts to stop it from happening are unacceptable affronts to our freedom as users.
Simply put, the game companies want to own our machines and tell us what we can or can't do. That's offensive. The machine is ours and we make the rules.
I single out kernel level anticheats because they are trying to defeat the very mitigations we're putting in place to deal with the exact problems you mentioned. Can't isolate games inside a fancy VFIO setup if you have kernel anticheat taking issue with your hypervisor.
> As far as I'm concerned, if the player wants to cheat he's just exercising his god given rights as the owner of the machine.
By this same logic: As far as I'm concerned, if the game developer only wants to allow players running anticheat to use their servers then they're just exercising their god given rights as the owner of the server.
This is just yet another example of the remote attestation nonsense where your computer is only "trusted" if it's corporate owned. If you own your machine, you "tampered" with it and as a result you get banned from everything. You get ostracized from digital society.
My position is this is unfair discrimination that should be punished with the same rigor as literal racism. Video games are the least of our worries here. We have vital services like banks doing this. Should be illegal.
This take sucks. The anticheat software in this context is for competitive games. No one cares about people cheating in isolation in single player games. The anticheat is to stop 1 guy from ruining it for the 9 others he's playing with online.
You can argue about the methods used for anticheat, but your comment here is trying to defend the right to cheat in online games with other people. Just no.
PvE shouldn't need it either, and yet games routinely ship with anti-cheat applied to everything (including single player).
I rather suspect that the reason for this is the current gaming economy of unlockable cosmetics that you can either grind for, or pay for. If people can cheat in single player or PvE, they can unlock the cosmetics without paying. And so...
Multiplayer PvE can still be ruined by cheating. In many such games, such as MMORPGs, you are still competing for resources such as rare spawns.
Spending hours setting up conditions for the rare spawn to appear, and then before you can get to it having someone using a tracking cheat and a speed cheat get to it first is very annoying.
That is not the solution if you want to play competitively of whenever you feel like it.
Kernel level AC is a compromise for sure and it's the gamers job to assess if the game is worth the privacy risk but I'd say it's much more their right to take that risk than the cheaters right to ruin 9 other people's time for their own selfish amusement
Cheating may not be moral but it's better to put up with it than to cede control of our computers to the corporations that want to own it.
If it kills online gaming, then so be it. I accept that sacrifice. The alternative leads to the destruction of everything the word hacker ever stood for.
I'm sorry but you are fighting a crusade you can not win by definition. If I am free to use my computer for anything I want then I am also free to lock it down to enjoy my favorite game. If I care about my freedom I will have a dedicated machine for this game that I accept I will not have control over.
You are hijacking this thread about VOLUNTARY ceasing of freedom as if the small community even willing to install these is a slippery slope to something worse. You have a point when it comes to banking apps on rooted phones and I'm with you on that but this is not the thread for it
Valve drives significant development of compatibility layers for Linux for the sake of gaming. Their customer base is anything but small. There is potential for this kernel stuff to spill into the entire Linux ecosystem. It was bad enough having to deal with nvidia. I really don't want other companies screwing up the kernel.
Realistically I don't see how Valve can avoid this. They want all those games on Steam Deck and the new console. Game devs want KAC. Therefore Valve can either provide them with some way to implement KAC - which effectively requires a "signed kernel / drivers only", same as on Windows - or tell them to go away. Why would they do the latter?
Mind you, it doesn't mean that the Linux kernel will be "infected for everyone". It means that we'll see the desktop Linux ecosystem forking into the "secure" Linux which you don't actually have full control of but which you need to run any app that demands a "secure" environment (it'll start with KAC but inevitably progress to other kinds of DRM such as video streaming etc). Or you can run Linux that you actually control, but then you're missing on all those things. Similar to the current situation with mainline Android and its user-empowering forks.
> we'll see the desktop Linux ecosystem forking into the "secure" Linux
> Or you can run Linux that you actually control, but then you're missing on all those things
We cannot allow this stuff to be normalized. We can't just sit by and allow ourselves to be discriminated against for the crime of owning our own devices. We should be able to have control and have all of those nice things.
Everything is gonna demand "secure" Linux. Banks want it because fraud. Copyright monopolists want it because copyright infringement. Messaging services want it because bots. Government wants it because encryption. At some point they might start demanding attestation to connect to the fucking internet.
If this stuff becomes normal it's over. They win. I can't be the only person who cares about this.
I wish that is an option. Nowadays many non competitives games that you play with friends you trust still use EAC (yet accept non-kernel mode operation on Linux). I suppose other than VAC you can't buy a usermode anticheat middleware now.
This is the most asinine take I've seen on the subject in a while.
You may think it's your "god-given right" to cheat in multiplayer games, but the overwhelming majority of rational people simply aren't going to play a game where every lobby is ruined by cheaters.
I don't like cheaters either. I just respect their power over their machine and wouldn't see that power usurped by corporations just to put a stop it.
The computers are supposed to be ours. What we say, goes. Cheating may not be moral but attempts to rob us of the power that enables cheating are even less so.
Actually, it is completely true. The TPM threat model has historically focused on software-based threats and physical attacks against the TPM chip itself - crucially NOT the communications between the chip and the CPU. In the over 20 year history of discrete TPMs, they are largely completely vulnerable to interposer (MITM) attacks and only within the last few years is it being addressed by vendors. Endorsement keys don’t matter because the TPM still has to trust the PCR commands sent to it by the CPU. An interposer can replace tampered PCR values with trusted values and the TPM would have no idea.
Technically yes, but it would produce an untrusted remote attestation signature (quote). This is roughly equivalent to using TLS with a self-signed certificate — it’s not trusted by anyone else. TPMs have a signing key that’s endorsed by the TPM vendor’s CA.
No, this is not true at all. Microsoft requires their system vendors (Dell, HP, etc) to allow users to enroll their own Secure Boot keys through their “Designed for Windows” certification.
Further, many distributions are already compatible with Secure Boot and work out of the box. Whether or not giving Microsoft the UEFI root of trust was a good idea is questionable, but what they DO have is a long, established history of supporting Linux secure boot. They sign a UEFI shim that allows distributions to sign their kernels with their own, distribution-controlled keys in a way that just works on 99% of PCs.
> Is it possible to un-enroll the Microslop certificates
Technically yes, with a massive fucking asterisk: Some option-ROM are signed with the MS certs and if your Motherboard doesn't support not loading those (whether needed or not) you will not be able to sometimes even POST.
With almost all modern motherboard firmware you can enter Setup mode and use KeyTool to configure the trust store however you want, starting from enrolling a user PK (Platform Key) upwards.
It’s generally a lot more secure to avoid the use of any shims (since they leave you vulnerable to what happened in this article) and just build a UEFI Kernel Image and sign that.
Some systems need third party firmware to reach the OS, and this can get a bit more complicated since those modules need to load with the new user keys, but overall what you are asking is generally possible.
I have a slow burn project where I simulate a supply chain attack on my own motherboard. You can source (now relatively old) Intel PCH chips off Aliexpress that are “unfused” and lack certain security features like Boot Guard (simplified explanation). I bought one of these chips and I intend to desolder the factory one on my motherboard and replace it with the Aliexpress one. This requires somewhat difficult BGA reflow but I have all the tools to do this.
I want to make a persistent implant/malware that survives OS reinstalls. You can also disable Intel (CS)ME and potentially use Coreboot as well, but I don’t want to deal with porting Coreboot to a new platform. I’m more interested in demonstrating how important hardware root of trust is.
I don't want Boot Guard or any of that DRM crap. I want freedom.
I want to make a persistent implant/malware that survives OS reinstalls.
Look up Absolute Computrace Persistence. It's there by default in a lot of BIOS images, but won't survive a BIOS reflash with an image that has the module stripped out (unless you have the "security" of Boot Guard, which will effectively make this malware mandatory!)
I’m more interested in demonstrating how important hardware root of trust is.
You mean more interested in toeing the line of corporate authoritarianism.
Well, this project is literally about me circumventing/removing Boot Guard so I don’t know how it’s corporate authoritarianism. I’m literally getting rid of it. In doing so I get complete control of the BIOS/firmware down to the reset vector. I can disable ME. To me, that’s ultimate freedom.
As a power user, do I want boot guard on my personal PC? Honestly, no. And we’re in luck because a huge amount of consumer motherboards have a Boot Guard profile so insecure it’s basically disabled. But do I want our laptops at work to have it, or the server I have at a colocation facility to have it? Yes I do. Because I don’t want my server to have a bootkit installed by someone with an SPI flasher. I don’t want my HR rep getting hidden, persistent malware because they ran an exe disguised as a pdf. It’s valuable in some contexts.
I want an equivalent of boot guard that I hold the keys to. Presented only with a binary choice certainly having boot guard is better than not having it if physical device security is in question. But that ought to be a false dichotomy. Regulation has failed us here.
Me managing my own (for example) secure boot keys does not inherently enable malicious actors. Obviously unauthorized access to the keys is an attack vector that whoever holds them needs to account for. Obviously it's not risk free. There's always the potential that a user could mismanage his keys.
There's absolutely no excuse for hardware vendors not to provide end users the choice.
> trust is protected by trusted companies...
The less control of and visibility into their product you have the less trustworthy they are.
Secureboot was being used as an example to illustrate the issue with your claim that a user controlling the keys must necessarily undermine security.
I'll grant that if the user is given control then compromise within the supply chain does become possible. However the same hypothetical malicious aliexpress vendor could also enroll a custom secure boot key, install "definitely totally legit windows", and unless the user inspects he might well never realize the deception. Or the supply chain could embed a keylogger. Or ...
> You mean more interested in toeing the line of corporate authoritarianism.
That’s not what I got from their post. After all, they’re putting in some effort to hardware backdoor their motherboard, physically removing BootGuard. I read it as “if your hardware is rooted then your software is, no matter what you do.”
> I want to make a persistent implant/malware that survives OS reinstalls.
You want to look into something called "Windows Platform Binary Table" [1]. Figure out a way to reflash the BIOS or the UEFI firmware for your target device ad-hoc and there you have your implant.
> You want to look into something called "Windows Platform Binary Table" [1].
Is this how various motherboard manufacturers are embedding their system control software? I was helping a family friend with some computer issues and we could not figure out where the `armoury-crate` (asus software for controlling RGB leds on motherboard :() program kept coming from
That most likely comes from Windows Update though. It now has the ability to download "drivers". It actually had said ability for a long time (back from Vista days if I remember right) but back then it was only downloading the .inf file and associated .sys files/etc, where as nowadays it actually downloads and runs the full vendor bloatware.
Have your friend grab https://github.com/seerge/g-helper which can disable armory crate. It’s also a lot lighter on your system - I was having constant gradual frame drops (games would start find and performance would slowly degrade) until I tried this and used the option to disable the AC processes.
Only works if the target is running Windows (paranoid people might be on Linux), so you'd probably want to slip in a malicious UEFI driver directly. Tools like UEFITool can be used to analyze and modify the filesystem of a UEFI firmware image.
Calling it a “kill switch” buries the lede here. What these politicians call a kill switch is technology to passively detect drunk driving. In 2021, Congress passed a law (HALT Drunk Driving Act) requiring NHTSA to eventually require auto makers to install passive drunk driver detection systems. NHTSA missed their statutory November 2024 deadline to finalize the regulations on this so it’s not like this amendment failing has a substantial impact. This technology is still many model years (maybe 2029? 2030?) away. I make no claims to the merits of this technology, I just feel the need to clarify the current situation.
This is conceptually interesting to me because I see this as almost a more generic TI Webench. I’m curious why your focus in the sized “grid” blocks (presumably for placement directly on the PCB layout) instead of doing the same but for the schematic. That way I still have the flexibility of laying out the board how I want to meet eg mechanical constraints instead of working around a 12.7mm grid.
I saw routing as equally as big of a headache as the schematic, so formalizing the layout to a grid means layout becomes a compilation problem, not a design problem.
My intent for phaestus isn't to design pcb's, it's to design entire products, and also to be friendly to non technical users who don't know what a PCB is, let alone do layout themselves.
I’ve been paying for Google Workspace for my custom domain for years basically just so I can use Gmail. For just $7 more dollars a month, I upgraded my plan to access Gemini Pro, which has guaranteed enterprise-grade privacy controls. I think this is currently the best value platform for anyone who values their privacy for LLMs. If Apple and the DoD trust Google’s internal controls, I do too.
