search

obhq / obliteration

Experimental free and open-source PlayStation 4 kernel
https://obliteration.net
Apache License 2.0
628 stars 18 forks source link

Handle sys_open with mode != 0 #482

Open SuchAFuriousDeath opened 10 months ago

SuchAFuriousDeath commented 10 months ago

A follow-up on #473 https://github.com/obhq/obliteration/blob/332b70cf100552aba085710870a973b5a30a62b2/src/kernel/src/fs/mod.rs#L257

ultimaweapon commented 10 months ago

Normally this argument must be ignored if O_CREAT is not supplied. Need to check how PS4 handled this case.

SuchAFuriousDeath commented 10 months ago

@ultimaweapon Quite a number of games crash on this unwrap, by the way. I thought I put it in this issue, but it turns out I didn't. https://github.com/obhq/obliteration/blob/b5722ffe50df3cc3028c5c500f8efa4d722e043c/src/kernel/src/fs/mod.rs#L234

The PS4 seems to treat this as a dword pointer, ignoring the upper dword. Do we do the same?

ultimaweapon commented 10 months ago

The PS4 seems to treat this as a dword pointer, ignoring the upper dword. Do we do the same?

Where is this on the PS4?

SuchAFuriousDeath commented 10 months ago

when sys_open passes the arg to kern_openat, the is assembly mov r9d, dword ptr[ ...]

ultimaweapon commented 10 months ago

The PS4 seems to treat this as a dword pointer, ignoring the upper dword. Do we do the same?

That is not a correct place to fix this. This argument will contains a garbage if the caller did not supplied to the kernel. What we should do is checking how the PS4 use this argument in the kern_openat.

SuchAFuriousDeath commented 10 months ago

I think I understand. Thanks