svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensola...

Konstantin Belousov kostikbel at gmail.com
Thu Jan 2 13:13:15 UTC 2014


On Thu, Jan 02, 2014 at 11:49:04AM +0100, Pawel Jakub Dawidek wrote:
> On Thu, Jan 02, 2014 at 02:28:57AM -0800, Alfred Perlstein wrote:
> > On 1/2/14 1:33 AM, Pawel Jakub Dawidek wrote:
> > > On Wed, Jan 01, 2014 at 11:16:22PM -0800, Stanislav Sedov wrote:
> > >> On Sep 4, 2013, at 5:09 PM, Pawel Jakub Dawidek <pjd at FreeBSD.org> wrote:
> > >>
> > >>>   This commit also breaks compatibility with some existing Capsicum system calls,
> > >>>   but I see no other way to do that. This should be fine as Capsicum is still
> > >>>   experimental and this change is not going to 9.x.
> > >> Hi!
> > >>
> > >> This change also increases the size of kinfo_file structure, which won???t allow
> > >> programs not compiled against HEAD and working with kern.info.filedesc sysctl
> > >> to run properly on HEAD (e.g. 8.x, 9.x and 10.x jails won???t run properly on HEAD,
> > >> and it also broke valgrind).  Is there absolutely no way to avoid extending the size
> > >> of this struct?
> > > Well, I made this change to have space for future cap_rights_t
> > > expension. I did that change for a major branch, so we don't have to do
> > > it in the middle of 10.x or to not block the work until 11.0.
> > >
> > > Note that the structure changed size not only because of _kf_cap_spare[3]
> > > field, but also because cap_rights_t is not uint64_t anymore, it is now
> > > struct that contains two uint64_t (1424 - 1392 = 4 * 8).
> > >
> > > I'm afraid it is too late to change it for 10.0 at this point anyway.
> > > Not sure if you are aware this was merged to 10, because you write about
> > > 10.x jails not working properly on HEAD. 10.x jails will work properly
> > > on HEAD.
> > >
> > > BTW. I'd love if we stop using such structures for a running kernel.
> > > We should really move to using libnv to export data like that.
> > 
> > Aren't there enough bits in         int _kf_ispare[4];          /* Space 
> > for more stuff. */
> > to make this work for the time being until you can provide an alternate 
> > way to fetch the cap stuff from the kernel.
> 
> I don't plan to provide alternative way to fetch the cap stuff. Well, I
> implemented libnv, which can be used to reimplement how we fetch all
> data like kinfo_file in a ABI friendly way, but I don't plan to modify
> this specific code myself.
I.e. you break something and decline to fix it, putting the burden on
somebody else.

> 
> > Afaik you could just remove the "spare" and steal 2 or 4 entries from 
> > _kf_ispare until it is sorted.
> 
> Yes, this would work for current cap_rights_t structure, at least for
> i386 and amd64, but would only allow to expand the structure by one
> uint64_t in the future (which might or might not be enough). The
> cap_rights_t structure is designed to be expanded to 5 uint64_ts without
> breaking ABI. I don't want to stuck with current cap_rights_t that is
> designed to expand, but cannot be, because kinfo_file wasn't modified at
> the start of a major branch.
The ABI stability is not limited to the single branch.  It must be
preserved across whole project lifetime.

> 
> > Can you please make use of that and discuss merge to 10 with re@?
> 
> I'm Bccing re@, but I'm pretty sure it is too late for such a change,
> especially that it breaks ABI with all 10-RCs. I'm also not changing my
> mind. I'd like to structure to stay as-is.
This is just awful breakage of _ABI_.  We cannot leave it as is,
unless we also claim that project gave up on ABI stability at all.

> 
> > It really sounds like breaking top/etc under jails is something that 
> > should and can be avoided.
> 
> I agree. Maybe it should be done every 10 major releases (I'm still fine
> with that rule), but we cannot just stuck with it forever.
> 
> My suggestions would be:
> 1. Move to libnv.
> 2. Detect that the given binary was compiled against some older version
>    of this structure and copy old structure to userland. Not sure if we
>    can do that now or not, but I'd expect we can detect that.
The only way to fix this is either to stop passing caps in kinfo_file,
reverting it to the pre-commit state, or follow Alfred suggestion
by consuming spares.

My own opinion is that the kinfo change must be removed, and the bug
is so critical that another RC must be issued.

> 
> > >>>   #if defined(__amd64__) || defined(__i386__)
> > >>> -#define        KINFO_FILE_SIZE 1392
> > >>> +#define        KINFO_FILE_SIZE 1424
> > >>>   #endif
> > >>>   
> > >>>   struct kinfo_file {
> > >>> @@ -389,6 +390,7 @@
> > >>>          uint16_t        kf_pad1;                /* Round to 32 bit alignment. */
> > >>>          int             _kf_ispare0;            /* Space for more stuff. */
> > >>>          cap_rights_t    kf_cap_rights;          /* Capability rights. */
> > >>> +       uint64_t        _kf_cap_spare[3];       /* Space for future cap_rights_t. */
> > >>>          int             _kf_ispare[4];          /* Space for more stuff. */
> > >>>          /* Truncated before copyout in sysctl */
> > >>>          char            kf_path[PATH_MAX];      /* Path to file, if any. */
> 
> -- 
> Pawel Jakub Dawidek                       http://www.wheelsystems.com
> FreeBSD committer                         http://www.FreeBSD.org
> Am I Evil? Yes, I Am!                     http://mobter.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20140102/de927a0a/attachment.sig>


More information about the svn-src-all mailing list