linux-kernel - Re: [patch 6/7] process filtering for fault-injection capabilities

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] [day] [month] [year] [list]

Date:	Fri, 13 Oct 2006 11:52:42 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Don Mullis <dwm@...r.net>
Cc:	Akinobu Mita <akinobu.mita@...il.com>,
	linux-kernel@...r.kernel.org, ak@...e.de
Subject: Re: [patch 6/7] process filtering for fault-injection capabilities

On Fri, 13 Oct 2006 10:28:54 -0700
Don Mullis <dwm@...r.net> wrote:

> On Thu, 2006-10-12 at 16:43 +0900, Akinobu Mita wrote:
> > This patch provides process filtering feature.
> > The process filter allows failing only permitted processes
> > by /proc/<pid>/make-it-fail
> 
> Akinobu: Toward the end of the previous round of review, we had 
> the following exchange:
>         
>         On Tue, 2006-09-19 at 17:05 +0800, Akinobu Mita wrote:
>         On Mon, Sep 18, 2006 at 10:54:51PM -0700, Don Mullis wrote:
>         > > Add functionality to the process_filter variable: A negative argument
>         > > injects failures for only for pid==-process_filter, thereby permitting
>         > > per-process failures from boot time.
>         > > 
>         > 
>         > Is it better to add new filter for this purpose?
>         > Because someone may want to filter by tgid instead of pid.
>         > 
>         > - positive value is for task->pid
>         > - nevative value is for task->tgid
>         
>         Your idea sounds good to me.
> 
> 
> So naturally I'm wondering why the functionality was dropped.
> An application I had in mind was to identify which of the boot-time
> calls to the slab allocator must not fail but are not yet marked
> __GFP_NOFAIL (some experimentation showed that for pid 1 there are
> lots of these).
> 
> Andrew: Would such an exercise would be worth the effort?
> 

If we're looking for unchecked boot-time allocation failures then I'd say
no, there's not much point in adding code to check for these.  We tend to
assume that the machine has enough memory to boot the kernel and initial
userspace.

That being said, some boot-time allocations are in code which could also
have been compiled into a module, so we do want to be checking those,
because we do care about memory-allocation failures at modprobe time.  But
we can check for these by building the relevant driver as a module and then
testing it.



And the "if it's positive it's a pid, if it's negative it's a tgid"
interface is rather unpleasant - if we're going to do this we should use
separate control files, or use something like

	echo "pid=1234" > /proc/process_filter
	echo "tgid=4321" > /proc/process_filter

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