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]
Date:   Thu, 31 Mar 2022 10:42:12 -0700
From:   Axel Rasmussen <axelrasmussen@...gle.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Mike Rapoport <rppt@...nel.org>, Linux MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org
Subject: Re: [PATCH] mm/secretmem: fix panic when growing a memfd_secret

Any strong opinions on which error code is used? I think overall I
would still pick EOPNOTSUPP, but happy to change it if anyone feels
strongly.

- I think ENOSYS is specific to syscall nr not defined
- I think ENOTTY is specific to ioctls
- The kernel (sort of mistakenly) defines ENOTSUPP instead of ENOTSUP,
but it's marked deprecated and it's recommended to use EOPNOTSUPP
instead (despite POSIX saying these should be distinct and for
different uses).

On Thu, Mar 24, 2022 at 2:44 PM Axel Rasmussen <axelrasmussen@...gle.com> wrote:
>
> On Thu, Mar 24, 2022 at 2:33 PM Matthew Wilcox <willy@...radead.org> wrote:
> >
> > On Thu, Mar 24, 2022 at 02:09:09PM -0700, Axel Rasmussen wrote:
> > > This patch avoids the panic by implementing a custom setattr for
> > > memfd_secret, which detects resizes specifically (setting the size for
> > > the first time works just fine, since there are no existing pages to try
> > > to zero), and rejects them as not supported (ENOTSUP).
> >
> > Isn't ENOTTY the normal return value for this?  Or even ENOSYS?
>
> I'm unsure.
>
> Since errno(3) says ENOTTY means "Inappropriate I/O control operation"
> that makes me think it's meant to be used only for ioctls?
>
> I tried ENOSYS, but checkpatch warns me it's meant to be used for
> "invalid syscall nr" and nothing else.
>
> ENOTSUP / ENOTSUPP / EOPNOTSUPP all have their own share of
> weirdnesses too, though. There's the whole ENOTSUP / ENOTSUPP mess,
> and then also the fact that glibc says ENOTSUP == EOPNOTSUPP, whereas
> POSIX says EOPNOTSUPP should be distinct and used specifically for
> sockets...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ