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: <20230729100401.GA4577@1wt.eu>
Date:   Sat, 29 Jul 2023 12:04:01 +0200
From:   Willy Tarreau <w@....eu>
To:     Zhangjin Wu <falcon@...ylab.org>
Cc:     linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        tanyuan@...ylab.org
Subject: Re: [PATCH 1/2] tools/nolibc: add pipe() support

On Sat, Jul 29, 2023 at 04:37:00PM +0800, Zhangjin Wu wrote:
> > This one does not have the correct prototype for the function exposed
> > to the user, pipe really is "int pipe(int pipefd[2])". Maybe you were
> > thinking about sys_pipe() instead ? But since MIPS also has pipe2() now,
> > there's no reason to make an exception.
> >
> 
> Yes, pipe2() should be a better choice, but I have seen this sentence in
> syscall manpage [1]:
> 
>        /* On Alpha, IA-64, MIPS, SuperH, and SPARC/SPARC64, pipe() has the
>           following prototype; see NOTES */
> 
>        #include <unistd.h>
> 
>        struct fd_pair {
>            long fd[2];
>        };
>        struct fd_pair pipe(void);
> 
> If it is about syscall, then we are ok to align all of the architectures
> together to use "int pipe(int pipefd[2])"

Yes it's OK, that's how applications expect it to be used:

  https://pubs.opengroup.org/onlinepubs/9699919799/functions/pipe.html

For the archs you mention above, it's the libc that wraps the call,
exactly what we ought to do as well (using pipe2() since it will be
easier).

Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ