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  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]
Date:	Sun, 24 Mar 2013 17:54:00 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Anton Arapov <anton@...hat.com>
Cc:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Josh Stone <jistone@...hat.com>,
	Frank Eigler <fche@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	adrian.m.negreanu@...el.com, Torsten.Polle@....de
Subject: Re: [PATCH 6/7] uretprobes: limit the depth of return probe
	nestedness

On 03/22, Anton Arapov wrote:
>
>   Unlike the kretprobes we can't trust userspace, thus must have
> protection from user space attacks,

Plus the user-space have the "unlimited" stack, it looks simply
impossible to handle the deep recursion correctly.

Lets consider the simplest case,

	void probed_func(int x)
	{
		if (--x)
			probed_func(x);
	}

We could add ret_instance->recursion_counter to handle this case and
avoid kmalloc(). But this way we won't be able to implement the new
features like data-pouch.

> this patch limits the return
> probes nestedness as a simple remedy for it.
>   The intention is to have KISS and bare minimum solution for the
> initial implementation in order to not complicate the uretprobes
> code.
>
>   In the future we may come up with more sophisticated solution that
> should remove this depth limitation, however it is not easy task
> and lays beyond this patchset. It should consider things like: breakpoint
> address lays outside the stack and stack growth direction, longjmp,
> sigaltstack... be able to clean up return instances.

I agree. Perhaps we should at least try to do something more clever in
future, but this needs another (certainly nontrivial) series, we should
not mix this with the initial implementation, it should be as simple as
possible.

Oleg.

--
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