Add /dev/dolphin ioctl to change disc

[leo60228]

The intended usecase is for custom channels to change the current disc using only a Wii Remote. Example code:

char disc_path[] = "/home/user/game.iso";
ioctlv change_disc[] = {
  {
    disc_path,
    sizeof(disc_path)
  }
};

s32 fd = IOS_Open("/dev/dolphin", 2);
if (fd != -1) {
  IOS_Ioctlv(fd, 0x06, 1, 0, change_disc);
  IOS_Close(fd);
}

[JosJuice]

This would let emulated software read any data on the user's computer that the user has access to... as long as the file has the right magic value in it, which to be fair isn't likely for files that aren't actually GC/Wii ISOs. Not sure how I feel about that.

[leo60228]

This would let emulated software read any data on the user's computer that the user has access to... as long as the file has the right magic value in it, which to be fair isn't likely for files that aren't actually GC/Wii ISOs. Not sure how I feel about that.

I feel like a user running a malicious homebrew is pretty unlikely. And even then, the file wouldn't just have to have the right magic, it'd have to be at a known path because there's no way to get a directory listing.

[leo60228]

And are there any formats where the only restriction on their data is a magic, and it doesn't have to have valid/sensible metadata?

[leo60228]

The Wii format is much more complicated, but the GameCube format would allow reading the full contents of any file with 0xC2339F3D at 0x1C. That does seem like a strict enough requirement that exploitation would be infeasible.

[AdmiralCurtiss]

What's your intended use case for this?

[leo60228]

A homebrew could be written to select a game to play from the system menu without using a mouse.

[AdmiralCurtiss]

...Without a way to query the list of available games? I'm not sure you thought this fully through.

Here's an idea, why not instead add an IOCTL to query the list of games Dolphin knows about, basically the list of games as you see in the main Dolphin window, and then another IOCTL to switch disc to one of them based on some kind of ID. That would solve the security concerns quite nicely and at the same time make it easier to do that kind of homebrew.

[leoetlino]

The current implementation also has the problem of being platform specific since host paths are used directly. And since there is no way to query for games, I don't see how this can be used in practice (other than hardcoding paths for one particular setup...)

[spycrab]

In addition to the points mentioned above, I think there definitely should be some kind of config option to turn this off entirely. It can probably be enabled by default.

[AdmiralCurtiss]

From what I remember, the /dev/dolphin device is already fully disabled in determinism mode, though a separate option wouldn't hurt if it doesn't exist yet. Probably out of scope of this PR though.

[spycrab]

@AdmiralCurtiss Yeah, you're right. Not sure what I was thinking. Updated my comment.

[JosJuice]

This will call the GameFileCache constructor that uses the default cache path, which works for DolphinQt but not for Android. For Android, you need to provide a specific path as an argument:

dolphin/Source/Android/app/src/main/java/org/dolphinemu/dolphinemu/services/GameFileCacheService.java

Line 144 in 9ef526c

GameFileCache temp = new GameFileCache(getCacheDir() + File.separator + "gamelist.cache");

[leo60228]

Is there a way to do it for both DolphinQt and Android?

[JosJuice]

I can't think of any solution to the problem that doesn't involve Android-specific code.

[leo60228]

Also, getCacheDir() is a Java API. Is there an equivalent for C++? I'd rather not use the UI's GameFileCache to prevent race conditions where a new game is added as the user is selecting a game.

[JosJuice]

Also, getCacheDir() is a Java API. Is there an equivalent for C++?

No, there is no C++ equivalent. You would need to call the Java function using JNI, or write a JNI function that can be used to pass the cache path from Java to C++.

I'd rather not use the UI's GameFileCache to prevent race conditions where a new game is added as the user is selecting a game.

I agree, that doesn't sound like the way to go. It also wouldn't solve the Android problem, since you then would need separate code for accessing DolphinQt's GameFileCache and Android's GameFileCache.

[leo60228]

I don't really know anything about Android, and I don't have a toolchain for building the apk. Would it be okay if I just disabled this on Android for now?

[leo60228]

I'm going to try and fix Android, but this is an example for the new API:

        s32 fd = IOS_Open("/dev/dolphin", 2);
        s32 ret = 0;

        if (fd != -1) {
                s32 size = 0;
                ioctlv get_size[] = {{&size, sizeof(size)}};
                ret = IOS_Ioctlv(fd, 0x06, 0, 1, get_size);
                ioctlv* get_names = malloc(size * sizeof(ioctlv));
                for (s32 i = 0; i < size; ++i) {
                        char* buf = malloc(256);
                        get_names[i] = (ioctlv){buf, 256};
                }
                ret = IOS_Ioctlv(fd, 0x07, 0, size, get_names);
                for (s32 i = 0; i < size; ++i) {
                        printf("%.256s\n", (char*) get_names[i].data);
                        free(get_names[i].data);
                }
                s32 disc = 2;
                ioctlv change_disc[] = {{&disc, sizeof(disc)}};
                ret = IOS_Ioctlv(fd, 0x08, 1, 0, change_disc);
                IOS_Close(fd);
        }

I wasn't sure how to cleanly fit getting the lengths into the new API, but you can just allocate a larger buffer if it's not null-terminated (and I'm guessing there's a hard limit for names somewhere).

[leo60228]

very low quality video https://www.youtube.com/watch?v=-C4mJmEHx3Y&feature=youtu.be

[leo60228]

app at https://github.com/leo60228/change-disc/releases/tag/v0.1, it will almost definitely break in horrible ways if your games don't fit perfectly on the screen

[Leseratte10]

Is there a reason the IOCTL_DOLPHIN_GET_GAME_LIST_NAMES requires one output parameter for each game? Isn't there a limit for how many output parameters these calls can have? In my opinion it would be a better idea to just accept one output parameter, a pointer to a place in memory where Dolphin can store all the game IDs right after another.
EDIT: Or is this call supposed to return the actual game name and not the ID6?

[leo60228]

It returns the actual game name, yes. If there is a limit, it's pretty high, I didn't hit it while testing with ~50 games. I initially considered placing them sequentially but I didn't want O(n) indexing.

[mbc07]

I think it's wise to test the current implementation with a huge library before merging. I would ask @JMC47 to check this...