Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150417202332.GE6817@brightrain.aerifal.cx>
Date: Fri, 17 Apr 2015 16:23:33 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] replace 'hlt' by 'ud2' in i386/x32/x86_64 a_crash
 implementations

On Fri, Apr 17, 2015 at 09:48:38PM +0300, Alexander Monakov wrote:
> > > An argument in favor of plain hlt/ud2 is that registers and memory are
> > > preserved, in case someone will be analyzing the coredump.
> > 
> > That's a good point. The above could be fixed to preserve registers
> > with some minor added push/pop (simple pusha/popa on 32-bit)
> > before/after the syscall, but then it gets bigger.
> 
> Hm, no, I wouldn't like to see that.  By the time a_crash executes, "the
> impossible happened", so stack pointer might be pointing somewhere you
> wouldn't want modified.

Given that it's used in C code and C code generally can't be running
at all without a stack, I don't think that's an issue. We're not using
it for detection of stack overflows (which are handled with guard
pages) but for detection of corrupt heap structures, etc. It's
possible that a heap overflow could cause the stack pointer to be
restored to the wrong value, but then I think you would have a really
hard time reaching the a_crash() call.

> A good reason for compilers to generate ud2 is that it also works for kernel
> code, unlike hlt -- but then OSv carries a copy of musl to run it in the
> context of, as I understand, virtualized kernel -- what happens when they
> execute a_crash?

Yes, that does seem like a good aspect.

Rich

Powered by blists - more mailing lists

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