linux-kernel - Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 10 Jul 2017 06:26:06 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     "Reshetova\, Elena" <elena.reshetova@...el.com>
Cc:     "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz\@infradead.org" <peterz@...radead.org>,
        "gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
        "akpm\@linux-foundation.org" <akpm@...ux-foundation.org>,
        "mingo\@redhat.com" <mingo@...hat.com>,
        "adobriyan\@gmail.com" <adobriyan@...il.com>,
        "serge\@hallyn.com" <serge@...lyn.com>,
        "arozansk\@redhat.com" <arozansk@...hat.com>,
        "dave\@stgolabs.net" <dave@...olabs.net>,
        "keescook\@chromium.org" <keescook@...omium.org>,
        Hans Liljestrand <ishkamiel@...il.com>,
        "David Windsor" <dwindsor@...il.com>
Subject: Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t

"Reshetova, Elena" <elena.reshetova@...el.com> writes:

>> "Reshetova, Elena" <elena.reshetova@...el.com> writes:
>> 
>> 2>> Elena Reshetova <elena.reshetova@...el.com> writes:
>> >>
>> >> > refcount_t type and corresponding API should be
>> >> > used instead of atomic_t when the variable is used as
>> >> > a reference counter. This allows to avoid accidental
>> >> > refcounter overflows that might lead to use-after-free
>> >> > situations.
>> >>
>> >> In this patch you can see all of the uses of the count.
>> >> What accidental refcount overflows are possible?
>> >
>> > Even if one can guarantee and prove that in the current implementation
>> > there are no overflows possible, we can't say that for
>> > sure for any future implementation. Bugs might always happen
>> > unfortunately, but if we convert the refcounter to a safer
>> > type we can be sure that overflows are not possible.
>> >
>> > Does it make sense to you?
>> 
>> Not for code that is likely to remain unchanged for a decade no.
>
> Can we really be sure for any kernel code about this? And does it make
> sense to trust our security on a fact like this?

But refcount_t doesn't fix anything.  At best it changes a bad bug to a
less bad bug.  So now my machine OOMS instead of allows a memory
overwrite.   It still doesn't work.

Plus refcount_t does not provide any safety on the architectures where
it is a noop.

>> This looks like a large set of unautomated changes without any real
>> thought put into it. 
>
> We are soon into the end of the first year that we started to look into
> refcounter overflow/underflow problem and coming up this far was 
> not easy enough (just check all the millions of emails on kernel-hardening
> mailing list). Each refcount_t conversion candidate was first found by Coccinelle
> analysis and then manually checked and converted. The story of 
> refcount_t API and all discussions go even further. 
> So you can't really claim that there is no " thought put into it " :)

But the conversion of the instance happens without thought and manually.
Which is a good recipe for typos.  Which is what I am saying.

There have been lots of conversions like that in the kernel and
practically every one has introduced at least one typo.

So from an engineering standpoint it is a very valid question to ask
about.  And I find the apparent insistence that you don't make typos
very disturbing.

>  That almost always results in a typo somewhere
>> that breaks things.
>> 
>> So there is no benefit to the code, and a non-zero chance that there
>> will be a typo breaking the code.
>
> The code is very active on issuing WARNs when anything goes wrong. 
> Using this feature we have not only found errors in conversions, but
> sometimes errors in code itself. So, any bug would be actually much
> faster visible than using old atomic_t interface. 
>
> In addition by default refcount_t equals to atomic, which also gives a
> possibility to make a softer transition and catch all related bugs in couple
> of cycles when enabling CONFIG_REFCOUNT_FULL.

But if you make a typo and change one operation for another I don't see
how any of that applies.

And that is what it looks like I we are looking at here.

Eric