[kernel-hardening] Re: Conversion from atomic_t to refcount_t: summary of issues

[David Windsor <dwindsor@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

Also, I'd like to point out that while identifying stats_t instances, I
have found a similar distribution of non-standard functions (as agreed upon
for the stats_t API).

First, usage of atomic_long_wrap_t (there currently isn't a stats_long_t
planned for implementation):

(Use
https://github.com/ereshetova/linux-stable/blob/hardened_atomic_next_stats
to view these snippets in context.  Line numbers are accurate to within a
few lines).

include/linux/mm.h:2360:
    extern atomic_long_wrap_t num_poisoned_pages;

include/linux/mmzone.h:695
    atomic_long_wrap_t      vm_stat[NR_VM_NODE_STAT_ITEMS];

mm/memory-failure.c:64:
    atomic_long_wrap_t num_poisoned_pages __read_mostly =
ATOMIC_LONG_INIT(0);

... and several others.  Note, these are only from stats_t conversions for
the mm subsystem.

Next, API calls outside of the proposed stats_t API:

kernel/auditsc.c:2029:
   if (uid_valid(loginuid))
        sessionid = (unsigned int)atomic_inc_return_wrap(&session_id);

kernel/padata.c:58:
    seq_nr = atomic_inc_return_wrap(&pd->seq_nr);

kernel/rcu/tree_trace.c:192:
    s0 += atomic_long_read_wrap(&rdp->exp_workdone0);

kernel/trace/trace_mmiotrace.c:123
    atomic_xchg_wrap(&dropped_count, 0);

... and several others.  Note, these are only from stats_t conversions in
the kernel/ directory.

I haven't yet completed my audit of the entire kernel source tree in my
atomic_t-to-stats_t conversion efforts, so I don't yet have an exhaustive
list of non-supported functions, but will at some point soon.

Thanks,
David

On Thu, Dec 1, 2016 at 2:15 PM, Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Nov 29, 2016 at 03:35:15PM +0000, Reshetova, Elena wrote:
> > but Hans will be finishing processing
>
> > > > The following functions are also needed quite commonly:
> > >
> > > > refcount_inc_return()
> > > > refcount_dec_return()
> > >
> > > What for? They don't typicaly make sense for refcounting? Other than
> the
> > > trivial pattern of dec_return() == 0, which is already well covered.
>
> Hans, could you point me to a few users of {inc,dec}_return() that I can
> audit for (in)sanity?
>

[-- Attachment #2: Type: text/html, Size: 2826 bytes --]