kernel-hardening - Re: Conversion from atomic_t to refcount

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 1 Dec 2016 16:31:16 -0500
From: David Windsor <dwindsor@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Reshetova, Elena" <elena.reshetova@...el.com>, 
	"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Greg KH <gregkh@...uxfoundation.org>, 
	Kees Cook <keescook@...omium.org>, "will.deacon@....com" <will.deacon@....com>, 
	Boqun Feng <boqun.feng@...il.com>, Hans Liljestrand <ishkamiel@...il.com>, 
	"aik@...abs.ru" <aik@...abs.ru>, "david@...son.dropbear.id.au" <david@...son.dropbear.id.au>
Subject: Re: Conversion from atomic_t to refcount_t: summary of issues

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@...radead.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?
>

Content of type "text/html" skipped

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.