On Fri, Feb 15, 2013 at 11:20:18PM -0800, Raymond Jennings wrote:
> An even bigger question might be why an execve is allowed to get into
> an unrecoverable state to begin with. Assuming that one builds the
> new mm_struct and whatnot BEFORE discarding old state, why would
> execve be in a positi
On Fri, Feb 15, 2013 at 6:20 PM, Al Viro wrote:
> Arrgh... OK, I'm a blind idiot. These places in binfmt_elf.c currently use
> force_sig(), not send_sig_info(). Currently == since 2006 when somebody
> noticed the problem. Their counterparts in binfmt_elf_fdpic.c were *not*
> noticed. Anyway,
On Sat, Feb 16, 2013 at 01:50:24AM +, Al Viro wrote:
> On Fri, Feb 15, 2013 at 04:46:43PM -0800, Shentino wrote:
> > On Fri, Feb 15, 2013 at 4:38 PM, Shentino wrote:
> > > On Fri, Feb 15, 2013 at 4:04 PM, Al Viro wrote:
> > >> How would you manage to have it masked at that point? setup_new_e
On Fri, Feb 15, 2013 at 04:46:43PM -0800, Shentino wrote:
> On Fri, Feb 15, 2013 at 4:38 PM, Shentino wrote:
> > On Fri, Feb 15, 2013 at 4:04 PM, Al Viro wrote:
> >> How would you manage to have it masked at that point? setup_new_exec()
> >> is inevitable after success of flush_old_exec() and it
On Fri, Feb 15, 2013 at 5:22 PM, Al Viro wrote:
>
> Fine by me - the variant I'd posted simply moved these calls in one
> place; I've no problem with replacing them with force_sig() (or
> force_sigsegv(SIGSEGV, current), for paranoia sake). OTOH, I'd probably
> prefer to make it a separate commit
On Fri, Feb 15, 2013 at 04:40:18PM -0800, Linus Torvalds wrote:
> On Fri, Feb 15, 2013 at 4:04 PM, Al Viro wrote:
> > On Fri, Feb 15, 2013 at 03:12:30PM -0800, Shentino wrote:
> >> > + send_sig(SIGSEGV, current, 0);
> >>
> >> This might be a stupid miscue on my part,
On Fri, Feb 15, 2013 at 4:38 PM, Shentino wrote:
> On Fri, Feb 15, 2013 at 4:04 PM, Al Viro wrote:
>> How would you manage to have it masked at that point? setup_new_exec()
>> is inevitable after success of flush_old_exec() and it will do
>> flush_signal_handlers() for us.
>
> I wouldn't know fo
On Sat, 16 Feb 2013, Al Viro wrote:
> > > + send_sig(SIGSEGV, current, 0);
> >
> > This might be a stupid miscue on my part, but shouldn't it be
> > force_sig instead of send_sig?
> >
> > I've got this crazy hunch that having SEGV masked might muck something up.
>
On Fri, Feb 15, 2013 at 4:04 PM, Al Viro wrote:
> On Fri, Feb 15, 2013 at 03:12:30PM -0800, Shentino wrote:
>> > + send_sig(SIGSEGV, current, 0);
>>
>> This might be a stupid miscue on my part, but shouldn't it be
>> force_sig instead of send_sig?
>>
>> I've got this
On Fri, Feb 15, 2013 at 4:04 PM, Al Viro wrote:
> How would you manage to have it masked at that point? setup_new_exec()
> is inevitable after success of flush_old_exec() and it will do
> flush_signal_handlers() for us.
I wouldn't know for sure but I read somewhere that even if execve
resets han
On Fri, Feb 15, 2013 at 03:12:30PM -0800, Shentino wrote:
> > + send_sig(SIGSEGV, current, 0);
>
> This might be a stupid miscue on my part, but shouldn't it be
> force_sig instead of send_sig?
>
> I've got this crazy hunch that having SEGV masked might muck somethin
On Fri, Feb 15, 2013 at 1:59 PM, Al Viro wrote:
> On Fri, Feb 15, 2013 at 12:02:50PM -0800, Linus Torvalds wrote:
>> On Wed, Feb 13, 2013 at 9:36 PM, Al Viro wrote:
>> >
>> > The only problem is that some suicides do SIGKILL, some SIGSEGV.
>> > AFAICS, it started as SIGSEGV and had been s
On Fri, Feb 15, 2013 at 12:02:50PM -0800, Linus Torvalds wrote:
> On Wed, Feb 13, 2013 at 9:36 PM, Al Viro wrote:
> >
> > The only problem is that some suicides do SIGKILL, some SIGSEGV.
> > AFAICS, it started as SIGSEGV and had been switched to SIGKILL for a.out
> > (without any comments)
On Wed, Feb 13, 2013 at 9:36 PM, Al Viro wrote:
>
> The only problem is that some suicides do SIGKILL, some SIGSEGV.
> AFAICS, it started as SIGSEGV and had been switched to SIGKILL for a.out
> (without any comments) in 1.1.62.
Ok, I really don't think it matters which one we do - either
If execve() fails past flush_old_exec(), we are obviously going to
kill the process. Right now it's implemented in $BIGNUM places in
->load_binary() and that's obviously brittle (and in at least one case
buggy - binfmt_flat lacks send_sig_info() on late failures). Now, there's
an obvious
15 matches
Mail list logo
