On Tue, 24 Oct 2006, Maxim Sobolev wrote:
>> On Tue, 24 Oct 2006, Maxim Sobolev wrote:
>>> OK, in this particular case I am trying to run su(8) binary compiled for
>>> FreeBSD/ia32 on FreeBSD/amd64 system (FreeBSD 6.2 but this doesn't really
>>> make any difference since the code is the same).
>>> Since all audit syscalls in freebsd32 emulation layer are redirected to
>>> nosys() any attempt to invoke such syscall results in both ENOSYS errno
>>> *and* SIGSYS signal delivered to the process in question. The latter kills
>>> the process without giving it any chance to handle ENOSYS.
>> So the actual bug here is that there's no compat32 definitions for the
>> audit system calls. I have a suspicion that we may need compat32 wrappers
>> in some cases, but you could start by simply exposing the audit system
>> calls in compat32 by changing UNIMPL to STD (or MSTD in RELENG_6)?
> Shouldn't unimplemented syscall have the same semantics in binary
> compatibility mode and in native mode (i.e. ENOSYS, but not SIGSYS)? That's
> my biggest confusion. Why do we get just ENOSYS in native mode when audit is
> not in, while ENOSYS+SIGSYS in compatibility mode?
The method by which the distinction between ENOSYS+SIGSYS and plain ENOSYS is
determined is in the implementation of the system call. If a system call is
flagged as unimplemented (i.e., you never hit the function implementing it),
you get SIGSYS+ENOSYS. If you enter the stub, you get ENOSYS. So the problem
is that the compat code doesn't enter the stub, so never gets to the ENOSYS
path. A casual glance at the system call arguments for audit suggest that
wrappers aren't needed (no pointers embedded in structure arguments), so
simply marking them as implemented will likely work.
Robert N M Watson
University of Cambridge