Page MenuHomeFreeBSD

libnv: Fix strict-aliasing violation with cookie
ClosedPublic

Authored by jilles on Oct 22 2017, 8:23 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 15, 7:53 PM
Unknown Object (File)
Wed, Oct 15, 7:53 PM
Unknown Object (File)
Wed, Oct 15, 7:53 PM
Unknown Object (File)
Wed, Oct 15, 12:47 PM
Unknown Object (File)
Wed, Oct 15, 9:35 AM
Unknown Object (File)
Wed, Oct 15, 5:57 AM
Unknown Object (File)
Wed, Oct 15, 5:55 AM
Unknown Object (File)
Fri, Oct 3, 11:23 PM
Subscribers

Details

Summary

In rS323851, some casts were adjusted in calls to nvlist_next() and
nvlist_get_pararr() in order to make scan-build happy. I think these changes
just confused scan-build into not reporting the strict-aliasing violation.

For example, nvlist_xdescriptors() is causing nvlist_next() to write to its
local variable nvp of type nvpair_t * using the lvalue *cookiep of type
void *, which is not allowed. Given the APIs of nvlist_next(),
nvlist_get_parent() and nvlist_get_pararr(), one possible fix is to create a
local void *cookie in nvlist_xdescriptors() and other places, and to convert
the value to nvpair_t * when necessary. This patch implements that fix.

An rg '\(void\s*\*\*\)\s*&' finds many cases in the kernel where an
address of something is cast to void **, but only few in userland. This
matches that the kernel configures the compiler for a dialect of C without
type based aliasing restrictions (i.e., -fno-strict-aliasing), but userland
does not.

Test Plan

Install world and kernel in a VM and run lib/libnv and lib/libcasper tests.
All tests passed except the cap_dns ones which failed the same way as
unpatched (because my VM does not have a direct network connection).

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Oct 25 2017, 7:24 PM
This revision was automatically updated to reflect the committed changes.