Inaccurate clock resolution in WASI `clock_res_get`

[yagehu]

Inaccurate clock resolution in WASI `clock_res_get`

[mathetake]

Expected behavior
Expected on Linux:

clock resolution 0 sec 1 nsec

Actual on Linux:

clock resolution 0 sec 1000 nsec

No I don't think this is really expected or bug at all. The whole point of WASI is isolation and if you make this happen, then you leak the host information into the Wasm guest, which basically breaks the sandbox. Why do you want to make this flux depending on the underlying OS? Ack this is not written in the WASI spec at all.

[mathetake]

just FYI, wazero CLI is fixed to use WithSysWalltime API, and you can see what's expected there regarding resolutin:

	// WithSysWalltime uses time.Now for sys.Walltime with a resolution of 1us
	// (1000ns).
	//
	// See WithWalltime
	WithSysWalltime() ModuleConfig

[yagehu]

Just want to highlight that leaking host information is not unique to clock resolution. Wazero already leaks filesystem host information like most other Wasi runtimes (Wasmtime, WasmEdge, etc.), e.g. filestat::dev, filestat::ino. I think it's reasonable to expect a call to clock_res_get return an accurate clock resolution, especially when the current Wazero clock_time_get is passed through the Go runtime to call the corresponding OS clock_gettime.

In any case, even if complete portability is desired for clock_res_get, I propose setting it to a lowest common denominator, say 55 ms, instead of an arbitrary value.