Expose PS2 memory to same-user tools via named shm

[Inertia-Squared]

… Linux

Description of Changes

• Keeps emulated memory object open to same-user processes for easy debugging/live-patching on native Linux builds.
• Safely discards named object on shutdown, and properly handles named object in new session if for some reason the program previously did not shut down cleanly.

Rationale behind Changes

Makes reading game memory on Linux much easier to work with, this specific patch is being done for DC1AP (Archipelago mod for Dark Cloud), but would have reaching benefits to other mods running natively on Linux, too.

Technically strips away a layer of security, but the implications are quite narrow (same-user, should only affect emulated game memory), and the new behaviour would mirror what happens on Windows with EEmem for debuggers anyway, so to my knowledge we wouldn't be crossing a previously unviolated security barrier, from a cross-platform perspective.

At the very least, I think we should add a CLI flag to keep it open, but if possible, it would be nice to just have this as default behaviour!

Suggested Testing Steps

I built and ran my changes to ensure they worked as intended, it seemed pretty good, though obviously this isn't the most scientific method of testing.

Changes are quite small, so I don't think there is anything in particular to add to test, though if you wanted to be thorough a unit test to ensure the named object is actually unlinked when re-running after a bad shutdown couldn't hurt!

Did you use AI to help find, test, or implement this issue or feature?

I'm not very familiar with this codebase (made these changes to help with compat for downstream projects), so I used AI to run a semantic search through the codebase to quickly identify the bits I wanted to interact with based on what was causing issues downstream, as well as to give me a rough architectural overview of the project itself.

All code, reasoning, and stupid mistakes are my own!

As a side-note, I had to cherry-pick b6cccd8 to get it to build since I'm on Arch with ffmpeg 9.0+, but this fix seems staged and ready to go and I don't think it's a major issue in terms of my proposed changes specifically.

[github-actions]

Thank you for submitting a contribution to PCSX2

As this is your first pull request, please be aware of the contributing guidelines.

Additionally, as per recent changes in GitHub Actions, your pull request will need to be approved by a maintainer before GitHub Actions can run against it. You can find more information about this change here.

Please be patient until this happens. In the meantime if you'd like to confirm the builds are passing, you have the option of opening a PR on your own fork, just make sure your fork's master branch is up to date!

[chaoticgd]

should only affect emulated game memory

This isn't really true since that shared memory mapping also contains VTLB's translation tables from guest pages to host pages.

Not that I'm against this.

[Inertia-Squared]

should only affect emulated game memory

This isn't really true since that shared memory mapping also contains VTLB's translation tables from guest pages to host pages.

Not that I'm against this.

Ah, that makes sense.

Would it be worth sectioning off the guest memory under its own named shm, or would that not be necessary/feasible?

[F0bes]

and the new behaviour would mirror what happens on Windows with EEmem for debuggers anyway

You can still use EEMem on Linux (and most likely macos)

I have a sample here https://github.com/F0bes/pcsx2_offsetreader

Is there something I'm missing?

[Inertia-Squared]

You can still use EEMem on Linux (and most likely macos)

I have a sample here https://github.com/F0bes/pcsx2_offsetreader

Is there something I'm missing?

There are two separate issues:

The first is symbol-based address discovery seems broken on packaged builds.

On Arch (and maybe others), pcsx2 appears to be linked without --export-dynamic, so a symbolic discovery method won't work. It works fine when I try it on a release build I build myself though, so this could be an issue with how downstream packagers are building it, but at the very least it seems to be a common problem, I don't really know enough about PCSX2's build/toolchain to give great insights there.

To show you what I mean, I ran the /linux/linux.cpp code from your repo that you linked against a v2.6.3 build of PCSX2 from the AUR, and these are the logs I get:

Without sudo, we can't even access it (though I understand this is intentional):

Finding the pid of pcsx2
pcsx2 pid: 81230
Reading symbols from pcsx2(81230)
Error: Could not find EEmem in nm output
 Are you running a proper version of pcsx2? Are you root?
 PR #5531 introduced this feature.
nm: Warning: could not locate '/proc/81230/exe'.  reason: Permission denied

And when we can, we can't find it (stripped)

sudo ./eememtest 
Finding the pid of pcsx2
pcsx2 pid: 81230
Reading symbols from pcsx2(81230)
nm: /proc/81230/exe: no symbols
Error: Could not find EEmem in nm output
 Are you running a proper version of pcsx2? Are you root?
 PR #5531 introduced this feature.

The second (and main issue I'm trying to solve here, which just also happens to work around the missing symbols) is permissions.

Once we have EEmem, it requires elevation or permission workarounds to access it, at least for certain Linux distros (not sure about others, but it seems to be a common issue).

For example, the AUR build on Arch sets some caps on the binary to fix other issues, but this simultaneously locks out other processes from accessing its memory (and I'm pretty sure is just locked out to begin with without giving the inspecting process ptrace capabilities?). There are a few other examples and causes, but keeping shm open essentially pokes a nice through-hole to guarantee a central access point that will always work regardless of the distro.

A nice benefit of keeping the memory open to same-pid users is that downstream projects no longer need to get sudo permissions from the user to hook into a game, which makes it more accessible on locked-down systems, and I personally just like the idea of keeping sudo usage to a minimum.

[Mrlinkwii]

Would using PINE be a better solution to your issue?

[TheLastRar]

You can still use EEMem on Linux (and most likely macos)
I have a sample here https://github.com/F0bes/pcsx2_offsetreader
Is there something I'm missing?

To show you what I mean, I ran the /linux/linux.cpp code from your repo that you linked against a v2.6.3 build of PCSX2 from the AUR, and these are the logs I get:

Without sudo, we can't even access it (though I understand this is intentional):

And when we can, we can't find it (stripped)

Is this also true for our AppImage and flatpak builds?

[Inertia-Squared]

Would using PINE be a better solution to your issue?

The downstream project I submitted this PR for isn't mine, but I asked the project's maintainer about it and this is what they had to say:

When i first worked on implementing it, PINE was still very young, and i tried messing around with it and got all sorts of errors and problems. I then moved from making just a PS2 memory client to refactoring for support on other emulators and games, which are not supported by PINE. The route gives me the freedom to support games like Dark Souls Remastered, emulators like Duckstation. bizhawk and Project64. PINE can work, and i tested it in a proof of concept branch of mine on Dark Cloud 2, but imo it would be limiting the library in scope and functionality to switch over

So yeah, I think it is mainly just that some use cases prefer to have the power/flexibility of directly interacting with memory.

Is this also true for our AppImage and flatpak builds?

No dice for AppImage:

sudo nm /proc/$(pgrep pcsx2)/exe
nm: /proc/147725/exe: no symbols

Flatpak preserves symbols, including EEmem:

sudo nm /proc/$(pgrep pcsx2)/exe | grep EEmem
000000000184d550 B EEmem

[F0bes]

You noted that arch compiles without exporting symbols? Now it's edited away. Was that true? If so, I will probably tell them to not do that...

Sorry, GitHub mobile decided to hide your reply. This app is awful lol. The following holds true:

But if this doesn't work out of box for appimage, I'm not against this change. Disclaimer, I haven't reviewed the code yet.