Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1684154

Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t

Show all headers | View raw

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

>> "Reshetova, Elena" <elena.reshetova@intel.com> writes:
>> 
>> 2>> Elena Reshetova <elena.reshetova@intel.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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/3]  v2 ipc subsystem refcount coversions Elena Reshetova <elena.reshetova@intel.com> - 2017-07-07 11:10 +0200
  [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-07-07 11:10 +0200
    Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t ebiederm@xmission.com (Eric W. Biederman) - 2017-07-10 00:10 +0200
      RE: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to  refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-07-10 08:50 +0200
        Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t ebiederm@xmission.com (Eric W. Biederman) - 2017-07-10 10:50 +0200
          Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t Alexey Dobriyan <adobriyan@gmail.com> - 2017-07-10 11:40 +0200
            Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t ebiederm@xmission.com (Eric W. Biederman) - 2017-07-10 13:30 +0200
          RE: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to  refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-07-10 12:00 +0200
            Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t ebiederm@xmission.com (Eric W. Biederman) - 2017-07-10 13:40 +0200
              RE: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to  refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-07-10 14:20 +0200
                Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t ebiederm@xmission.com (Eric W. Biederman) - 2017-07-10 22:50 +0200
                RE: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to  refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-07-12 11:30 +0200
  [PATCH 2/3] ipc: convert sem_undo_list.refcnt from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-07-07 11:10 +0200
  [PATCH 3/3] ipc: convert kern_ipc_perm.refcount from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-07-07 11:10 +0200

csiph-web