Re: [PATCH v3 4/6] ieee1275: implement vec5 for cas negotiation
On 2023-02-01 21:31, Robbie Harwood wrote:
Stefan Berger writes:
+.vec5_size = 1 + sizeof (struct option_vector5) - 2,
+.vec5 = {
+ 0, 0, 0, 0, 0, 0, 0, 0, 256
+}
Hi Stefan and Diego, are you able to speak to vec5 setting?
I have been talking with Avnish Chouhan (CC'd) downstream and requested
they sync with you, but this patch doesn't seem to have their changes.
They have proposed two different changes. The first, which I'm
currently carrying, is
https://github.com/rhboot/grub2/commit/c2e640266247e3e0d3268f5ef20a734f5800f577
which sets
.vec5 = { -1, -1, -1, -1, -1, -1, -1, -1, 256 }
while the latest proposal is
https://gist.github.com/frozencemetery/b36d8ee9b6282645fac52bf5a010b439
which sets
.vec5 = { 0, 192, 0, 128, 0, 0, 0, 0, 256 }
Obviously I can't ship all three at once. As I'm not an expert on cas,
could you all please unify this into a single suggestion we can ship
upstream and down?
(If it helps, I believe these are IBM bugs
https://bugzilla.linux.ibm.com/show_bug.cgi?id=200825 and
https://bugzilla.linux.ibm.com/show_bug.cgi?id=200213 )
Be well,
--Robbie
Hi Robbie,
Stefan and I synced up on this. He'll merge the latest proposal.
Thank you!
Regards,
Avnish Chouhan
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Question re correctness of module license check
The module loader contains the following check:[1]
/* Me, Vladimir Serbinenko, hereby I add this module check as per new
GNU module policy. Note that this license check is informative only.
Modules have to be licensed under GPLv3 or GPLv3+ (optionally
multi-licensed under other licences as well) independently of the
presence of this check and solely by linking (module loading in GRUB
constitutes linking) and GRUB core being licensed under GPLv3+.
Be sure to understand your license obligations.
*/
static grub_err_t
grub_dl_check_license (grub_dl_t mod, Elf_Ehdr *e)
{
Elf_Shdr *s = grub_dl_find_section (e, ".module_license");
if (s == NULL)
return grub_error (GRUB_ERR_BAD_MODULE,
"no license section in module %.63s", mod->name);
if (grub_strcmp ((char *) e + s->sh_offset, "LICENSE=GPLv3") == 0
|| grub_strcmp ((char *) e + s->sh_offset, "LICENSE=GPLv3+") == 0
|| grub_strcmp ((char *) e + s->sh_offset, "LICENSE=GPLv2+") == 0)
return GRUB_ERR_NONE;
return grub_error (GRUB_ERR_BAD_MODULE,
"incompatible license in module %.63s: %.63s", mod->name,
(char *) e + s->sh_offset);
}
IANAL, but my understanding is that GRUB's license is complied with when
the loaded module is covered by a license that can be "subsumed"[2] by
the GPLv3 (or that can subsume the GPLv3, like a future GPLv4). As
noted by [2], this includes Apache, MPL, etc.
As for the "GNU module policy", I could not find what this references:
- The commit introducing the check doesn't mention what this policy is,
where it comes from or where it was discussed.[3]
- Neither does the mailing list thread in which the GRUB change was
discussed.[4]
- Looking up variations of "GNU module licensing policy" didn't reveal
any clues either (only [5], which seems to further support the notion
that licenses other than GPL might be acceptable).
>From the above, it is my conclusion that
(a) usage of other compatible licenses for modules is legally
permissible, contrary to the suggestion of the quoted comment; and
(b) any such GNU policy mandating modules be GPL licensed is either
disused to the point of obscurity or never truly existed in the
first place (i.e. was the result of some ad-hoc process or
misunderstanding, etc, rather than some officially promulgated and
promoted policy. I don't intend to insinuate deliberate
untruthfulness).
Is this fair/accurate? If so, can the check be relaxed to accept
compatible licenses and the comment clarified?
[1]:
https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/kern/dl.c?id=65bc45963014773e2062ccc63ff34a089d2e352e#n451
[2]: https://www.gnu.org/licenses/license-compatibility.html#combining
[3]:
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e745cf0ca64f94fa072d777cde8186aca2b78c1f
[4]: https://lists.gnu.org/archive/html/grub-devel/2011-04/msg00089.html
[5]: https://www.gnu.org/licenses/gpl-faq.en.html#GPLModuleLicense
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Question re correctness of module license check
George Barrett writes:
> The module loader contains the following check:[1]
>
> /* Me, Vladimir Serbinenko, hereby I add this module check as per new
>GNU module policy. Note that this license check is informative only.
>Modules have to be licensed under GPLv3 or GPLv3+ (optionally
>multi-licensed under other licences as well) independently of the
>presence of this check and solely by linking (module loading in GRUB
>constitutes linking) and GRUB core being licensed under GPLv3+.
>Be sure to understand your license obligations.
> */
> static grub_err_t
> grub_dl_check_license (grub_dl_t mod, Elf_Ehdr *e)
> {
> Elf_Shdr *s = grub_dl_find_section (e, ".module_license");
>
> if (s == NULL)
> return grub_error (GRUB_ERR_BAD_MODULE,
> "no license section in module %.63s", mod->name);
>
> if (grub_strcmp ((char *) e + s->sh_offset, "LICENSE=GPLv3") == 0
> || grub_strcmp ((char *) e + s->sh_offset, "LICENSE=GPLv3+") == 0
> || grub_strcmp ((char *) e + s->sh_offset, "LICENSE=GPLv2+") == 0)
> return GRUB_ERR_NONE;
>
> return grub_error (GRUB_ERR_BAD_MODULE,
>"incompatible license in module %.63s: %.63s", mod->name,
>(char *) e + s->sh_offset);
> }
>
> IANAL, but my understanding is that GRUB's license is complied with when
> the loaded module is covered by a license that can be "subsumed"[2] by
> the GPLv3 (or that can subsume the GPLv3, like a future GPLv4). As
> noted by [2], this includes Apache, MPL, etc.
>
> As for the "GNU module policy", I could not find what this references:
> - The commit introducing the check doesn't mention what this policy is,
>where it comes from or where it was discussed.[3]
> - Neither does the mailing list thread in which the GRUB change was
>discussed.[4]
> - Looking up variations of "GNU module licensing policy" didn't reveal
>any clues either (only [5], which seems to further support the notion
>that licenses other than GPL might be acceptable).
>
>>From the above, it is my conclusion that
> (a) usage of other compatible licenses for modules is legally
> permissible, contrary to the suggestion of the quoted comment; and
> (b) any such GNU policy mandating modules be GPL licensed is either
> disused to the point of obscurity or never truly existed in the
> first place (i.e. was the result of some ad-hoc process or
> misunderstanding, etc, rather than some officially promulgated and
> promoted policy. I don't intend to insinuate deliberate
> untruthfulness).
>
> Is this fair/accurate? If so, can the check be relaxed to accept
> compatible licenses and the comment clarified?
>
> [1]:
> https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/kern/dl.c?id=65bc45963014773e2062ccc63ff34a089d2e352e#n451
> [2]: https://www.gnu.org/licenses/license-compatibility.html#combining
> [3]:
> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e745cf0ca64f94fa072d777cde8186aca2b78c1f
> [4]: https://lists.gnu.org/archive/html/grub-devel/2011-04/msg00089.html
> [5]: https://www.gnu.org/licenses/gpl-faq.en.html#GPLModuleLicense
Despite having patched this code, I don't understand what this license
check is intended to accomplish. The usual caveats apply: I don't like
proprietary software either, I'm not a lawyer, etc..
First, on secureboot platforms (which is "lots" of them), the modules
have to be baked into grub at image creation time. There's no point in
a license check there.
That aside, theoretically grub modules can either come from within the
grub source tree, or externally. If they're internal to the tree, then
they must already have compatible copyright - else they would not have
been committed.
We're not aware of anyone trying to use external modules, and as
discussed previously on the list that's fraught anyhow, but suppose they
were. Even if the license on their module were maximally incompatible
with grub's, all that does is render them non-redistributable. (This is
akin to the situation ffmpeg can get into when certain GPL-incompatible
pieces are built.) There's no basis for refusing to load the module
outright.
But even then, suppose there were. As your post points out, the process
of deciding what's "compatible" is much more complicated than strcmp.
We would need a list of acceptable licenses, which we keep updated
somehow - and if we're being intellectually honest, the capability to
parse and understand full SPDX expressions (or similar). I doubt any of
us seriously want that in the bootloader.
So to return to the start, if it's not generally going to do much as-is,
then why do I care? Unfortunately, the module license checks is pretty
much the first thing that handles a module. If either the module or its
containing signed image is malformed, truncated, etc., then we can get
errors in the license check. They're not
Re: Question re correctness of module license check
On Fri, Feb 03, 2023 at 13:17:01 -0500, Robbie Harwood wrote: > We're not aware of anyone trying to use external modules, and as > discussed previously on the list that's fraught anyhow, but suppose they > were. Even if the license on their module were maximally incompatible > with grub's, all that does is render them non-redistributable. I was thinking something like this myself, but I accepted the premise of the doc comment for the purposes of discussion since I'm not confident in my vague understanding of those matters. > But even then, suppose there were. As your post points out, the process > of deciding what's "compatible" is much more complicated than strcmp. > We would need a list of acceptable licenses, which we keep updated > somehow - and if we're being intellectually honest, the capability to > parse and understand full SPDX expressions (or similar). I doubt any of > us seriously want that in the bootloader. I'd be fine with having the check dropped, but I was actually thinking of a more conservative approach: instead of checking for a specific license, check for a declaration of license compatibility. Something like a flag (signalled with, say, GRUB_MOD_LICENSE_GPLv3_COMPATIBLE) that was checked for instead. This would shift the policy mechanism mostly out of the code to the humans instead. (Of course, there'd be a lot of code churn updating all the module sources to use the new macro instead of the current GRUB_MOD_LICENSE. It might be simpler to check for a license string like "GPLv3 compatible"; it seems like this is how the "GPLv3" string is used in practice anyway.[1][2]) But, as you say, the benefit of the check seems specious at best. > So to return to the start, if it's not generally going to do much as-is, > then why do I care? What motivated the question for me was looking into using something like mbedtls for X.509 support. In checking whether the module loader recognised the Apache license, I saw not only that it didn't but that the comment seemed to explicitly forbid the use of differently-licensed modules due to some unspecified policy. I figure it'd be nice if I were the last to embark on that particular wild goose chase :) > Unfortunately, the module license checks is pretty much the first > thing that handles a module. If either the module or its containing > signed image is malformed, truncated, etc., then we can get errors in > the license check. They're not helpful and an end-user certainly > can't act on them properly. > Be well, > --Robbie Thanks [1]: https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00109.html [2]: https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00058.html ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] net/bootp: Fix unchecked return value
In the function send_dhcp_packet(), added an error check for the return value of grub_netbuff_push(). Fixes: CID 404614 Signed-off-by: Alec Brown --- grub-core/net/bootp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/grub-core/net/bootp.c b/grub-core/net/bootp.c index 7d31dba97..abe45ef7b 100644 --- a/grub-core/net/bootp.c +++ b/grub-core/net/bootp.c @@ -583,7 +583,9 @@ send_dhcp_packet (struct grub_net_network_level_interface *iface) grub_memcpy (&pack->mac_addr, &iface->hwaddress.mac, 6); - grub_netbuff_push (nb, sizeof (*udph)); + err = grub_netbuff_push (nb, sizeof (*udph)); + if (err) +goto out; udph = (struct udphdr *) nb->data; udph->src = grub_cpu_to_be16_compile_time (68); -- 2.27.0 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
