[Drbd-dev] drbd 8.4.3: refcounter overflow on re-sync
lars.ellenberg at linbit.com
Thu Sep 25 02:07:48 CEST 2014
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 :)
More information about the drbd-dev