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: <CAGXu5jKqCJB7L+T_ghv=qixt4J_eq4L6+o5MwueTZ8_GVfeDTQ@mail.gmail.com>
Date:	Sun, 29 May 2016 19:16:54 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Hector Martin <marcan@...can.st>
Cc:	Emese Revfy <re.emese@...il.com>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Brad Spengler <spender@...ecurity.net>,
	PaX Team <pageexec@...email.hu>
Subject: Re: [PATCH v1 1/3] Add the latent_entropy gcc plugin

On Sun, May 29, 2016 at 10:59 AM, Hector Martin <marcan@...can.st> wrote:
> On Mon, May 23, 2016 at 3:15 PM, Emese Revfy <re.emese@...il.com> wrote:
>> +/*
>> + * Copyright 2012-2016 by the PaX Team <pageexec@...email.hu>
>> + * Copyright 2016 by Emese Revfy <re.emese@...il.com>
>> + * Licensed under the GPL v2
>> + *
>> + * Note: the choice of the license means that the compilation process is
>> + *       NOT 'eligible' as defined by gcc's library exception to the GPL v3,
>> + *       but for the kernel it doesn't matter since it doesn't link against
>> + *       any of the gcc libraries
>> + *
>> + * gcc plugin to help generate a little bit of entropy from program state,
>> + * used throughout the uptime of the kernel
>
> The "Note" seems misleading. Since this is a GCC plugin, and directly
> uses GCC's internal interfaces, doesn't that make it a derived work of
> GCC, and thus, require that it be licensed under GPLv3 instead of GPLv2
> (which is incompatible)?
>
> AFAIK this is how the GPLv3 works in this context, and the GCC exception
> doesn't change that because it only applies to libgcc and friends (and
> does not weaken the default effects of the GPL over the rest of GCC). My
> understanding is that the whole "eligible compilation" licensing hack
> was designed to hinder non-linking proprietary compilation passes that
> operate over data files containing an internal GCC representation, but
> plain old loaded plugins still need to be GPLv3 regardless of whether
> you link the end result to libgcc or not.
>
> (Also, don't some arches link against libgcc, further complicating this?
> Trying to use this compiler plugin with those arches would wind up with
> non-redistributable kernels, this time due to the exception.)

IANAL. My interpretation is that plugins can be whatever license they
want to be, and if they declare that they're GPL-compatible (which
GPLv2 is), then the produced output can be under whatever license it
wants. Regardless, things are clearly following the intended purposes:
the plugin is free software, used to help gcc compile free software,
so no weird proprietary source, steps, or outputs, which is what the
gcc folks were trying to make sure continued to happen.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ