linux-kernel - Re: [PATCH 05/14] KDB: add more exports for supporting KDB modules

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: <513FB434.4050908@sgi.com>
Date:	Tue, 12 Mar 2013 16:03:16 -0700
From:	Mike Travis <travis@....com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Jason Wessel <jason.wessel@...driver.com>,
	Dimitri Sivanich <sivanich@....com>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	kgdb-bugreport@...ts.sourceforge.net, x86@...nel.org,
	linux-kernel@...r.kernel.org, Tim Bird <tim.bird@...sony.com>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Sasha Levin <sasha.levin@...cle.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Cong Wang <amwang@...hat.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Oleg Nesterov <oleg@...hat.com>,
	Serge Hallyn <serge.hallyn@...onical.com>
Subject: Re: [PATCH 05/14] KDB: add more exports for supporting KDB modules



On 3/12/2013 3:39 PM, Eric W. Biederman wrote:
> Mike Travis <travis@....com> writes:
> 
>> Let me see if I can understand the concept better.  By denying
>> an external hardware vendor the use of KDB to support a significant
>> piece of proprietary hardware on Linux, I furthering the interests
>> of Linux and the community how?
> 
> By ignoring interests of someone who does not cooperate with the
> community we encourage people to cooperate with the community.

I can see this point.
> 
>> Looking back at the KDB sources originally posted on oss.sgi.com I
>> did not see any restrictions on the use of KDB.  How/why was that
>> restriction granted and by whom?  Was SGI, the original copyright
>> owner of KDB, asked or even informed of that decision?  I'm not
>> trying to be a lawyer here, but someone decided (perhaps wrongly)
>> that KDB should only be used by GPL modules.
> 
> The symbols quoted below are have absolutely nothing to do with KDB
> ever.  They are pieces of code that you should only use in very
> exceptional circumpstances, or you risk breaking the kernel in strange
> and mysterious ways.

Yes, those below were indeed a mistake on my part.  Thanks for catching that.
> 
> Beyond that there are modules with GPL compatible licenses.  That is the
> only kind of module that the kernel license allows.

Okay.
> 
>> I'm not married to this matter by any means and I will change them all
>> if that's what's needed for acceptance.  But I do think that placing
>> unnecessary roadblocks in the path of developing more capabilities
>> for the Linux system, is causing a disservice to the the users of
>> Linux and the overall Linux community.
> 
> A capability that no one else can use, and that generates support
> requests that can not be supported is not developing more capabilities
> for the Linux system.  It is denying those of us who ask for repayment
> in code, our compensation.  It is theft.

Not sure I've ever looked at it this way, but again I can see your point.
> 
> Eric

Thanks for the meaningful feedback Eric.

Mike

> 
>>>> --- linux.orig/kernel/signal.c
>>>> +++ linux/kernel/signal.c
>>>> @@ -1419,7 +1419,7 @@ out_unlock:
>>>>    	rcu_read_unlock();
>>>>    	return ret;
>>>>    }
>>>> -EXPORT_SYMBOL_GPL(kill_pid_info_as_cred);
>>>> +EXPORT_SYMBOL(kill_pid_info_as_cred);
>>>>
>>>>    /*
>>>>     * kill_something_info() interprets pid in interesting ways just like kill(2).
>>>> @@ -2491,7 +2491,7 @@ out:
>>>>    }
>>>>
>>>>    EXPORT_SYMBOL(recalc_sigpending);
>>>> -EXPORT_SYMBOL_GPL(dequeue_signal);
>>>> +EXPORT_SYMBOL(dequeue_signal);
>>>>    EXPORT_SYMBOL(flush_signals);
>>>>    EXPORT_SYMBOL(force_sig);
>>>>    EXPORT_SYMBOL(send_sig);
>>>> @@ -3661,4 +3661,5 @@ kdb_send_sig_info(struct task_struct *t,
>>>>    	else
>>>>    		kdb_printf("Signal %d is sent to process %d.\n", sig, t->pid);
>>>>    }
>>>> +EXPORT_SYMBOL(kdb_send_sig_info);
>>>>    #endif	/* CONFIG_KGDB_KDB */
--
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/