bsdgrep(1): Add some --mmap tests for basic sanity and previous breakage

[kevans]

Summary

Add some basic sanity checks for --mmap to cover general match/not match
correctness and to test breakage discovered in PRs 165471, 219402 and ultimately
fixed in rS318565.

Test Plan

Run kyua tests to ensure no regression, rewind and make sure the new tests
fail properly prior to rS313948 and then rS318565. Behavior before the former commit
results in a hang in the mmap_eof_not_eol test case, then up to the latter fails
terribly due to buffer overflows.

[kevans]

• Correct path for test; input file is not generated in /tmp, leftover from local testing

[kevans]

• Remove -x -- further review showed it not needed

[ngie]

contrib/netbsd-tests/usr.bin/grep/t_grep.sh

587 ↗

(On Diff #28595)

What does it do?

605 ↗

(On Diff #28595)

What does it do?

609–611 ↗

(On Diff #28595)

jot -b ' ' 4096 | tr -d '\n', please.

617 ↗

(On Diff #28595)

Hmmmm... is there another way to do this (it makes it a bit harder to upstream to NetBSD)?

[kevans]

• Clarify gnu grep from port failure
• use jot(1) more effectively in a way portable to both NetBSD and FreeBSD

[kevans]

contrib/netbsd-tests/usr.bin/grep/t_grep.sh

609–611 ↗

(On Diff #28595)

I compromise, went with jot -b " " -s "" 4096 since -s seems to also be available on NetBSD. Apologies- I had a case of 'not paying attention to the man page'

617 ↗

(On Diff #28595)

It's possible, but I've not thought of it yet. The alternative methods that I've conceived of for reproduction are unreliable. From the heap-allocated line buffer, you have to manage to either:

1.) Smash the stack
2.) Write into a write-protected region

Alternatively, you could try to exhaust address space, but #1 would be an easier target than that. I'm not sure how to set this up any other way, unfortunately, to guarantee detecting the overflow. The original test case was grep --mmap -r -e '^Feb' /usr/share/*', which is also technicaly unreliable.

[emaste]

@ngie are you happy with the final update?

[ngie]

In D10827#226061, @emaste wrote:

@ngie are you happy with the final update?

It's good enough for now -- we'll have to iterate on jemalloc for NetBSD later.