musl & strndupa?

musl & strndupa?

[Raphael Cohn]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

Hi,

I'm trying to compile 'audit' (aka libaudit, auditd, etc - from
http://people.redhat.com/sgrubb/audit/index.html version 2.3.2). Using musl
0.9.14.

The file 'src/ausearch-lol.c' uses a reference to 'strndupa', which I
presume is an alloca version of strndup, and presumably a _GNU_SOURCE
feature. I can't seem to see a definition for it in musl, although strdupa
exists in string.h (Indeed, http://linux.die.net/man/3/strdup suggests as
much).

Is this intentional? If so, what would anyone suggest as a work around? My
guess would be  #define strndupa(x, t) strncpy(alloca(strlen(x)+1),x,t)
but I'd like a second opinion...

Raph

[-- Attachment #2: Type: text/html, Size: 902 bytes --]

Re: musl & strndupa?

[Rich Felker]

On Wed, Jan 01, 2014 at 07:42:47PM +0000, Raphael Cohn wrote:
> Hi,
> 
> I'm trying to compile 'audit' (aka libaudit, auditd, etc - from
> http://people.redhat.com/sgrubb/audit/index.html version 2.3.2). Using musl
> 0.9.14.
> 
> The file 'src/ausearch-lol.c' uses a reference to 'strndupa', which I
> presume is an alloca version of strndup, and presumably a _GNU_SOURCE
> feature. I can't seem to see a definition for it in musl, although strdupa
> exists in string.h (Indeed, http://linux.die.net/man/3/strdup suggests as
> much).
> 
> Is this intentional? If so, what would anyone suggest as a work around? My
> guess would be  #define strndupa(x, t) strncpy(alloca(strlen(x)+1),x,t)
> but I'd like a second opinion...

That's roughly the way to do it, but you need strnlen, not strlen, and
there are various other details like properly parenthesizing macro
arguments. In addition, there's no way to avoid multiple-evaluations
of arguments unless you use the GNU C statement-expressions extension.

It should be noted that almost any use of alloca is either a bug
(potentially exploitable stack overflow) or useless (because the size
is bounded and thus could/should just be replaced by a fixed-size
array). This is the main reason I've been hesitant to go to the
trouble of providing this and dealing with the multiple-evaluation or
#ifdef __GNUC__ issue -- really, any software using alloca (and by
extension, strdupa or strndupa) should be fixed.

Rich

Re: musl & strndupa?

[Raphael Cohn]

[-- Attachment #1: Type: text/plain, Size: 2875 bytes --]

Rich,

Thank you for the extremely informative and quick response! I suspect in
the small, understandable places that use this function in this package it
should be possible to avoid multiple evaluations (well, at least for this
version of the code; no g'tee that would hold).

Out of interest, I presume there's no guarantee that alloca is aligned?
It's not a feature I've ever used - it seems like a micro-optimisation for
tight loops that should be made as part of a decision by a higher-level
language (eg Vala, which, as I understand, doesn't).

BTW, This package has a few more issues than just musl ones... it doesn't
understand cross-compilation for starters, makes insane use of code
generation (always a big smell in my book, especially when done using a
compiled language). Looks like it suffers from not enough peer review /
usage...

Raphael Cohn
Chief Architect, stormmq
Co-Chair, OASIS MQTT Standard
Secretary, OASIS AMQP Standard
raphael.cohn@stormmq.com
+44 7590 675 756

UK Office:
Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United
Kingdom
Telephone: +44 845 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number
07175657
StormMQ.com


On 1 January 2014 19:54, Rich Felker <dalias@aerifal.cx> wrote:

> On Wed, Jan 01, 2014 at 07:42:47PM +0000, Raphael Cohn wrote:
> > Hi,
> >
> > I'm trying to compile 'audit' (aka libaudit, auditd, etc - from
> > http://people.redhat.com/sgrubb/audit/index.html version 2.3.2). Using
> musl
> > 0.9.14.
> >
> > The file 'src/ausearch-lol.c' uses a reference to 'strndupa', which I
> > presume is an alloca version of strndup, and presumably a _GNU_SOURCE
> > feature. I can't seem to see a definition for it in musl, although
> strdupa
> > exists in string.h (Indeed, http://linux.die.net/man/3/strdup suggests
> as
> > much).
> >
> > Is this intentional? If so, what would anyone suggest as a work around?
> My
> > guess would be  #define strndupa(x, t) strncpy(alloca(strlen(x)+1),x,t)
> > but I'd like a second opinion...
>
> That's roughly the way to do it, but you need strnlen, not strlen, and
> there are various other details like properly parenthesizing macro
> arguments. In addition, there's no way to avoid multiple-evaluations
> of arguments unless you use the GNU C statement-expressions extension.
>
> It should be noted that almost any use of alloca is either a bug
> (potentially exploitable stack overflow) or useless (because the size
> is bounded and thus could/should just be replaced by a fixed-size
> array). This is the main reason I've been hesitant to go to the
> trouble of providing this and dealing with the multiple-evaluation or
> #ifdef __GNUC__ issue -- really, any software using alloca (and by
> extension, strdupa or strndupa) should be fixed.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 3907 bytes --]

Re: musl & strndupa?

[Rich Felker]

On Wed, Jan 01, 2014 at 08:07:07PM +0000, Raphael Cohn wrote:
> Rich,
> 
> Thank you for the extremely informative and quick response! I suspect in
> the small, understandable places that use this function in this package it
> should be possible to avoid multiple evaluations (well, at least for this
> version of the code; no g'tee that would hold).
> 
> Out of interest, I presume there's no guarantee that alloca is aligned?

You'd have to consult the compiler for a guarantee, but I think the
intent is that it's suitably aligned for any type, but perhaps not for
extended things like vector operations.

> It's not a feature I've ever used - it seems like a micro-optimisation for
> tight loops that should be made as part of a decision by a higher-level
> language (eg Vala, which, as I understand, doesn't).

The intent of alloca is to allow the programmer to be lazy about
obtaining temporary, "arbitrarily large" storage that will
automatically cease to exist when the caller returns. It's mostly
obsoleted by VLAs (but alloca can do things VLA can't, e.g. when used
in loops), but VLAs are also unsafe in the same way that there's no
way to check for allocation failures or handle them when they occur.
When you really need more than a small reasonable bounded-size buffer,
you need to be using malloc/free and dealing with the ugly failure
cases and cleanup on return...

Rich