|Summary:||sys-libs/efivar fails to compile against musl|
|Product:||Gentoo Linux||Reporter:||Travis Tilley <ttilley>|
|Component:||Hardened||Assignee:||Gentoo musl team <musl>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
|Attachments:||fix compilation against musl|
Description Travis Tilley 2015-03-20 03:05:54 UTC
Created attachment 399294 [details, diff] fix compilation against musl sys-libs/efivar fails with an error related to the usage of `__va_arg_pack_len`. additionally, a strange assumption about sizeof(char) causes a runtime segfault. Attached is a patch that fixes the issue, make against the hardened-dev musl branch.
Comment 1 Mike Gilbert 2015-03-20 03:22:16 UTC
Just curious: Where did sizeof (struct guidname) come from?
Comment 2 Travis Tilley 2015-03-20 04:15:40 UTC
it allocates memory for a guidname struct using sizeof(char) instead of sizeof(struct guidname) and the comment explains this away by saying "strictly speaking, this *has* to be too large.". actually, i'm not sure if the comment is explaining this away, or asking why it's written like that. i'm somewhat confused myself. the other part of the patch, for `__va_arg_pack_len`, seems to just be a consistency issue as the builtin version is used just a few lines above.
Comment 3 Mike Gilbert 2015-03-20 14:14:08 UTC
(In reply to Travis Tilley from comment #2) Ah I see what's happening there. Since sizeof(char) is the 1 on just about any sane system, it is effectively calling calloc(inlen, 1). It is allocating a buffer of the same size as the input file. The for loop below it expects at least enough space to hold one struct guidname for each line in the input file. I wonder why it doesn't just count the number of lines in the input file and use that for the calloc call?
Comment 4 Anthony Basile 2015-03-20 18:24:09 UTC
Okay I committed this to the musl overlay. But the patch should go upstream. It looks reasonable. I'm leaving bugs that still need upstreaming as IN_PROGRESS.
Comment 5 Felix Janda 2015-03-21 08:19:55 UTC
Patches sent upstream: https://github.com/rhinstaller/efivar/pull/17
Comment 6 Felix Janda 2015-03-31 17:10:25 UTC
Comment 7 Anthony Basile 2015-06-10 12:04:07 UTC
@floppym. Looks like there's been a bunch of releases since 0.15 in the tree. Should we bump? (I'll take care of it to not burden you).
Comment 8 Mike Gilbert 2015-07-19 17:17:52 UTC
(In reply to Anthony Basile from comment #7) > @floppym. Looks like there's been a bunch of releases since 0.15 in the > tree. Should we bump? (I'll take care of it to not burden you). We are now on the current release (efivar-0.21), so I'm closing this.
Comment 9 Anthony Basile 2015-07-19 18:08:40 UTC
(In reply to Mike Gilbert from comment #8) > (In reply to Anthony Basile from comment #7) > > @floppym. Looks like there's been a bunch of releases since 0.15 in the > > tree. Should we bump? (I'll take care of it to not burden you). > > We are now on the current release (efivar-0.21), so I'm closing this. Okay we'll just used the ~arch version. I'm removing the ebuild from the musl overlay.