> From: "Theo de Raadt" <dera...@openbsd.org>
> Date: Tue, 07 Sep 2021 07:08:19 -0600
>
> Claudio Jeker <cje...@diehard.n-r-g.com> wrote:
>
> > > @@ -443,7 +443,7 @@ struct kinfo_proc {
> > >
> > > int32_t p_vm_rssize; /* SEGSZ_T: current resident set size
> > > in pages */
> > > int32_t p_vm_tsize; /* SEGSZ_T: text size (pages) */
> > > - int32_t p_vm_dsize; /* SEGSZ_T: data size (pages) */
> > > + u_int64_t p_vm_dsize; /* VSIZE_T: data size (pages) */
> > > int32_t p_vm_ssize; /* SEGSZ_T: stack size (pages) */
> > >
> > > int64_t p_uvalid; /* CHAR: following p_u* members from
> > > struct user are valid */
> >
> > From my understanding this is not how struct kinfo_proc should be modified.
> > Instead the code should add the u_int64_t version at the end and leave the
> > old in place. This way old userland still works with new kernel.
>
> If this is done as a size-change inline as Greg suggested, then it is a
> large sysctl ABI bump, with temporary breakage until binaries catch up.
>
> If the 32-bit value is kept as-is, and a 64-bit one is appended, this is
> still a small sysctl ABI bump depending on what uses the field. Existing
> binaries will use the 32-bit field for a time. Such as ps(1).
>
> Obviously we cannot add a new 64-bit field at the end, and mark the
> 32-bit field "unused", it breaks many utilities in a similar fashion.
> A truncated value must be put into the 32-bit field, or it is just as
> akward as a large sysctl ABI bump.
>
> Or we could coordinate the Greg approach as a sysctl ABI change near a
> libc major bump. On the other side of such a bump, all kernel + base +
> packages are updated to use the new storage ABI. We get orderly .h
> files without a confusing glitch, and kern_sysctl.c doesn't need to
> store the value into two fields (32bit and 64bit) for the forseeable
> future.
>
> Over the years I've arrived at the conclusion that maintaining binary
> compatibility at all costs collects too much confusing damage. Instead,
> we've built an software ecosystem where ABI changes are expected and
> carry minimal consequence.
I'm not convinced the original diff is right:
* We have several places in the kernel where we store numbers of pages
in a (32-bit) int. Changing just one of these places is dangerous.
* Changing the type of just vm_dsize makes no sense. We should change
them all (but see the point above).
* Does ASAN really need to reserve that much VA space?
