lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120802164225.GA4268@linux.vnet.ibm.com>
Date:	Thu, 2 Aug 2012 22:12:25 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Anton Arapov <anton@...hat.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	William Cohen <wcohen@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] uprobes: Ignore unsupported instructions in uprobe_mmap

> > uprobe_mmap()->install_breakpoint() can fail if the probed insn is not
> > supported
> 
> But there are other reasons why it can fail,
> 
> > However failing mmap_region()/do_fork() because of a probe on an
> > unsupported instruction is wrong.
> 
> Srikar, I strongly, absolutely disagree. Please correct me, but..
> 
> Do you realize how much uprobes hooks in mmap_region/dup_mmap are broken?
> 
> (cough, can't resist, vma_adjust()->uprobe_mmap() is not right too, but
>  this is another story).
> 
> OK, lets start with dup_mmap:
> 
> 		// retval == 0
> 
> 		if (file && uprobe_mmap(tmp))
> 			goto out;
> 
> 	out:
> 		up_write(&mm->mmap_sem);
> 		flush_tlb_mm(oldmm);
> 		up_write(&oldmm->mmap_sem);
> 		return retval;
> 
> Given that retval == 0, what do you think dup_mmap() returns if
> uprobe_mmap() fails? And note that we didn't copy all vmas.
> OK, at least this can't crash (afaics), and easy to fix.
> 
> 
> But mmap_region() is worse, much worse. It simply can _not_ fail
> after uprobe_mmap (of course, I am not saying this is unfixable)
> without the crash. And note that the crash is "delayed". And btw,
> like dup_mmap(), mmap_region() doesn't return the error too.

Oh, thats really a bad mistake from my side. I apologize.

> 
> Srikar, I strongly believe this horror must not exist. Either
> we should teach mmap_region() and dup_mmap() (and vma_adjust!)
> to fail correctly, or we should ignore the error code.
> 
> It is that simple, isn't it?
> 

Right.

> Whatever you do with uprobe_mmap(), even if you change it to always
> return 0, the code in mmap_region() is absolutely, absolutely broken.
> 

But uprobe_mmap() still needs to walk thro the probe list and 
insert the other probes. Currently we just ignore the remaining probes
and that has to be fixed within uprobe_mmap.

> Do you agree?
> 
> And once again. I agree, in the long term we should reconsider
> this change. But we need a simple fix for now/stable.
> 

Agree.

> > Hence change uprobe_mmap() to ignore unsupported instructions.
> 
> OK. Now suppose that mmap_region()-> uprobe_mmap() fails because
> the caller is SIGKILL'ed (so __get_user_pages fails). Given that
> mmap_region() can't handle the error correctly, the kernel can
> crash.
> 

How about having your fix + my patch to fix the uprobe_mmap()?

-- 
Thanks and Regards
Srikar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ