bugs. It appears to be quite difficult to identify the exact Qemu version
and setup. These do not fail on the TNF's qemu/amd64 setup, which can be
taken as a reference point for expected failures.
- make sure that -v does not change the program behavior
- don't set revents in poll
- add more debugging
- only call read when we have POLLIN
- don't mix I/O from master while processing input
While a real kernel collects these signals until the connect() returns and
then delivers one signal rump delivers every signal so we get more than one.
Ok: Antti Kantee <pooka@netbsd.org>
fails, it won't trash your /root/profile. Instead, the victim will be
/usr/bin/fpr. This way it at least won't break the world.
XXX: this test should probably be testing such things in a rump namespace.
This means within the cache window, a setattr that wouldn't change the
remote file's attributes from our current view of them will not be
relayed to the server and wait for the server to answer. Thus, e.g., a
process with a periodic timer interrupt that calls open(2) in a loop
can make progress with much higher probability than without caching.
XXX The test case doesn't work, so it's currently disabled. It needs
to stop the child of sshd that is handling an sftp session, not sshd
itself, and it's not obvious how to do that.
ok pooka
as zero. Make it advertise one (no_trunc == true).
Names longer than NAME_MAX (255) will never pass namei() btw.
Fixes PR #43670 (msdosfs claims support for filenames longer than {NAME_MAX},
but fails)
- provide an exec_prot_support() routine so $ARCH can indicate whether
it supports execution protection or not, and skip test accordingly.
- have a trivial 'return_one' shellcode to copy anywhere in a page, and
call it. The decision to keep the assembly solution is mine, reasons are
twofold:
- all pure-C implementations cannot be controlled easily:
bounds detection (beginning/end) of return_one is unpredictable,
or requires the use of overkill solutions like libelf. Using
dlsym(3) was a good proposal, however I can't use it to know the
end address of the payload. It makes copying of the shellcode a bit
more difficult: using a constant may be too small (code has not been
entirely copied, and can lead to errors that can be erroneously
detected as "test passed"), or too big (depending on where it is mapped
in memory, copying past the end of the function may trigger SIGSEGV).
- I have to ensure that the resulting assembly is the most compact
possible, especially as it will be reused to test other parts of
memory (stack, data, rodata, etc.).
Only i386 and amd64 are implemented so far. Others will come in due time.
FWIW, writing the exec_prot_support() callback and the return_one payload
should be enough. Writing callback requires good knowledge of the platform,
depending on chip revision, CPU, board, MMU... the protection level may vary.
Current files are put under lib/libc/arch/* and lib/libc/common/. Feel free to
move them around the tests/ tree. Keep in mind that the common/ and arch/ code
will be used outside of libc, so please do not hide them too deep in the tree.
I checked a few architectures via build.sh cross-compile, and will keep an
eye on buildbot for potential build breakage. Feel free to contact me in
case you see any, of course.
XXX: The only thing gained from this is seeing whether -lpthread breaks
the getenv(3) family. Yet, a strict hypothesis about this would require
that the two test files are identical, which they are not.
