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: <87li9sp7j0.fsf@xmission.com>
Date:	Tue, 12 Mar 2013 15:39:31 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Mike Travis <travis@....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

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 coopearte with the
community we encourage people to cooperate with the community.

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

Beyond that there are modules with GPL compatible licenses.  That is the
only kind of module that the kernel license allows.

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

Eric

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