[Drbd-dev] drbd 8.4.3: refcounter overflow on re-sync

[Lars Ellenberg]

On Thu, Sep 25, 2014 at 01:25:04AM +0200, PaX Team wrote:
> On 24 Sep 2014 at 23:50, Lars Ellenberg wrote:
> 
> > On Wed, Sep 24, 2014 at 08:07:11PM +0200, PaX Team wrote:
> > > > > perhaps it's a consequence of the reaction from the kernel on the overflow
> > > > > which is equivalent to a SIGKILL with all that it implies (files and network
> > > > > connections get closed, etc).
> > > > 
> > > > That would be the result of the _ASM_EXTABLE()?
> > > > or what causes that "reaction"?
> > > 
> > > no, the extable mechanism is only used to re-enter the kernel in a known
> > > way to be able to report back on the detected refcount overflow. the actual
> > > reaction is in pax_report_refcount_overflow
> > 
> > Which is registered in the corresponding place in the exception table.
> > So yes.
> 
> no, what is registered in the exception table is the address of the continuation
...
> it's an implementation choice only.

And that was what I wanted to know about. So yes ;-)

> > I predicted earlier that this would not be a fruitful discussion.

> you're conflating the general concept of reaction to exploits

Absolutely, yes, I do.

In this overflow case, I still don't see why it is supposed to help to
shoot the process that happens to be "current" when the overflow occurs,
respectively why it would be a valid assumption that this process would
be "the exploit", provoking the overflow on purpose...
But never mind, if you say that's so, fine.

> every major operating system vendor and cpu manufacturer have adopted protection
> techniques that were pioneered by us, i think that speaks more than a lone doubting
> Thomas on the drbd list ;).

I know. I'm not doubting. I get it.
I just don't like it (precautionary shooting in general), is all.

Though I dislike it even more that it (implementing protection
techniques) is even necessary, if you have to assume they are out to get
you.  Which is more a fact than an assumption, in more scenarios than
I'd like it to be.  So you keep preventing existing bugs elsewhere from
becoming exploitable, and I'll shut up :)

	Lars