Both read their caller's structures in place before validation, so an unreadable pointer crashed the host. Copy them in with a checked read first and return EFAULT, as FreeBSD 11.4 does.
Fixes#11370
sceKernelGettimezone wrote {0, 0} for every zone. A PS5 on firmware
13.40 set to US Eastern returned tz_minuteswest -300 and tz_dsttime 60:
the standard offset in minutes east of UTC, without the summer time in
effect on the run date, and the zone's daylight saving amount in
minutes. Both now come from the host zone, through the same HostZoneAt
and HostDaylightAmount the calendar conversions use.
guest_freebsd_clocks checks five TZ settings (UTC0, IST-5:30, BRT+3,
EST5EDT, CET-1CEST) and the null pointer.
clock_gettime threw invalid_argument when the result pointer was null,
before looking at the clock id. FreeBSD 11.4's sys_clock_gettime reads the
clock through kern_clock_gettime, which fails with EINVAL for an unknown
clock, and only then copies the result out, so a null pointer fails with
EFAULT.
Read the clock into a local value first, then fail with -1 and EFAULT when
the pointer is null. A clock that is not supported still throws before the
pointer is looked at. Test the null pointer for the supported clocks.
Written with AI assistance (Claude).
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
PS5MC (PPSA99420, Kodi 22) imports clock_settime (d7nUj1LOdDU) from
libkernel.prx, one reference, after sigwaitinfo in its import order.
Predicted stop once the imports ahead of it are covered (not a run):
FAIL: unresolved ELF import d7nUj1LOdDU from libkernel.prx
The NID is computed with tools/nid_names.py and matches aerolib.
Follows FreeBSD 11.4 sys/kern/kern_time.c sys_clock_settime and
kern_clock_settime (8c639945a44588f6cfdddfb057bb5aad88735da0) for a
root caller: EFAULT for a null time (copyin), EINVAL for any clock but
CLOCK_REALTIME and for a negative tv_sec or a tv_nsec outside 0 to
999999999. A valid CLOCK_REALTIME request throws with the requested
time named, since the host clock must not be set and no guest clock
offset is kept.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Co-authored-by: David <[email protected]>
sceKernelConvertUtcToLocaltime and sceKernelConvertLocaltimeToUtc returned
the time unchanged while libc localtime follows the host zone, so a title
that mixes them shows UTC as local time (#5067).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_017iLxaSz4qjmirfqKZdhVQk
Cover 20 clock IDs, preserved guest errno, non-null unsupported clocks and the SCE null-output fault. The regression fails against main and passes with the accompanying fix.
AI-assisted: yes
FreeBSD's gettimeofday stores the time only when tp is not null, and
clock_getres the resolution only when res is not null; both succeed
otherwise. Both threw, which aborted a title probing a clock or only
asking for the time zone. Write into a local result instead.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
clock_gettime and clock_getres served three FreeBSD clock ids with the wrong
clock or not at all:
- CLOCK_VIRTUAL (1) was the monotonic clock on Windows and threw on Linux; it
is the user CPU time of the process.
- CLOCK_PROF (2) threw on both hosts; it is the user plus system CPU time of
the process.
- CLOCK_SECOND (13) returned the coarse realtime clock with nanoseconds and a
sub-second resolution; it is the current second with tv_nsec 0 and a
resolution of one second.
Behaviour follows FreeBSD 11 clock_gettime(2) and kern_clock_gettime /
kern_clock_getres in sys/kern/kern_time.c.
Co-Authored-By: Claude Opus 5.5 <[email protected]>