You do have the option to open up Discord voice chats on PS5. Amazing what Discord could do when forced to actually write something efficient.
Youtube also exists as an app, and maybe you can trick the heavily gimped built in browser to go there as well, although last I checked it wasn't trivial.
> after booting my VM KDE just flashed because my external GPU was gone but everything went back working without a need for relogin.
What GPU are you using and how did you configure this, if you don't mind me asking? On my end I just can't unload the driver for it if I let KDE start with the external GPU available.
A Sapphire Radeon 9070 as the external GPU and a Ryzen 7 7600 as the integrated GPU. But I don't recommend this particular model for the 9070 if you want to do VFIO, it has the infamous reset bug so after booting the VM once I can't use the external GPU anymore unless I restart the machine. Also I never got the VFIO completely working, I could pass the GPU to the VM but the VM could not find the GPU (e.g., the AMD drivers said "no GPU found" while running the installer).
Actually, now that I think about this could be that my system is set to autologin (I am using Jovian-NixOS to get a almost SteamOS experience), so maybe this is not KDE being smart and could just be that it crashed and the system automatically login again. So yes, maybe this doesn't work.
Good post on troubleshooting the failure to boot, but from the title I was kind of hoping for something like decryption and analysis of the blobs' contents, rather than just metadata. Very "cool" that 3 megabytes of unauditable malware (the public blobs) are still not enough to even boot the platform...
+1 for go-away. It's a bit more involved to configure, but worth the effort imo. It can be considerably more transparent to the user, triggering the nuclear PoW check less often, while being just as effective, in my experience.
With the ramping up of 18+ verification in Australia and now Europe (and South Korea and China already having such a programme for many years, including game time locks for young people), yeah.
It doesn't seem that big a leap to connect the dots from device attestation > web browser integrity > identity verification > verified web access
There is actually a relatively old game series of the 2000s called Bluesky Hacker Replay that has this as the core element of its worldbuilding. Governments and corporations became tired of the internet being overrun with spam, viruses, porn and cyberterrorism and decide to create an internet 2.0, tightly controlled by corporate interests. Hackers persist on the old 1.0 internet called the SwitchNet.
And really, when you think about it.. if you composed an internet solely from the big name social media, entertainment, work, food, news and knowledge services, running atop Cloudflare who verifies everyone via government ID, how many would really complain? 99% of their internet time is already spent inside that bubble.
Oh joy. So when this sort of stuff comes to mobile phones, at least when the McDonalds app refuses to start on your pocket general purpose computer (because it's not running software that Google considers 'trustworthy') you'll be able to confidently say that the RTL for the part of the chip that is ultimately responsible for betraying your interests is open source. Surely consolation enough for missing out on your burger discount.
I like to bring up McDonalds as an example because IIRC it requires the highest, 'strong integrity' verdict from SafetyNet/Play Integrity/nom-du-jour. Maybe they should rename it to something with Open in the name when OpenTitan comes to Chromebooks.
BAR resizing (which is all that Smart Access Memory means, as far as I can tell) is just done by the kernel writing some value to the right field in PCI configuration space, why would it require firmware support (and if so, why would CSM preclude that support)?
Typically the system firmware sets up the PCI address assignments.
An OS can reassign addresses, but the firmware is expected to know things about the memory (and i/o) map in the system. If there's some device hard wired to specific memory or i/o addresses, the firmware (should) know not to give that address to any pci devices, but the OS might not know. Or if the system skipped some address pins, again similar thing.
That doesn't really preclude CSM support, but mapping devices outside of 32-bit space is sometimes tied to CSM and a large BAR probably won't fit in 32-bit space. Neither of theae things really need to be tied to CSM, but I guess the assumption is an OS that can use 64-bit device addresses would have an uefi loader.
Just to be clear, it is not the Base Address Register (BAR) itself that gets resized, it is the mapped region of video memory which is pointed to by the BAR.
When I think of the BAR, I think of how the OS uses it. Read the address (32 or 64 bits as the case may be), write the flag so the card is not active, write all 1s to the BAR, read the address which tells you how big the mapped region is (the adress will be 0s for bits that are within the mapped region), write back the original address, and finally re-enable the card.
Resizable bar doesn't change the bar from a 32-bit bar to a 64-bit bar, it just changes the number of bits used in the mapped region.
But if the os firmware mapped the gpu somewhere where there's no room to expand the bar, the OS shouldn't expand it.
As I mentioned in my first reply, the firmware is expected to have complete knowledge of the address mapping of the system, and the OS isn't.
There are lots of ways for the firmware to convey information about the address map to the OS, but it may not always be complete. Mapping two devices to the same address is a recipe for trouble.
That's not to say an OS can't change these things. PCI/PCIe hotplug rely on the OS to set the BAR address for newly connected devices. And that may require rearranging existing device mappings so that things fit. And so, OSes that are capable of hotplug can often do address reallocation for all the devices, but firmware would need to have allocated the devices used to boot the OS already, and you may as well use those if they're there, right?
There are a lot of features that Intel has decided are "supposed" to be enabled by firmware and Windows just goes along with that. AMD copies Intel for compatibility of course.
You can't possibly know that by the mere lack of these DLLs from the import directory.