public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: y2038@lists.linaro.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, Brian Foster <bfoster@redhat.com>,
	Dave Chinner <dchinner@redhat.com>,
	Allison Collins <allison.henderson@oracle.com>,
	Jan Kara <jack@suse.cz>, Eric Sandeen <sandeen@sandeen.net>
Subject: Re: [PATCH v2 20/24] xfs: disallow broken ioctls without compat-32-bit-time
Date: Fri, 13 Dec 2019 13:05:09 -0800	[thread overview]
Message-ID: <20191213210509.GK99875@magnolia> (raw)
In-Reply-To: <20191213205417.3871055-11-arnd@arndb.de>

On Fri, Dec 13, 2019 at 09:53:48PM +0100, Arnd Bergmann wrote:
> When building a kernel that disables support for 32-bit time_t
> system calls, it also makes sense to disable the old xfs_bstat
> ioctls completely, as they truncate the timestamps to 32-bit
> values.

Note that current xfs doesn't support > 32-bit timestamps at all, so for
now the old bulkstat/swapext ioctls will never overflow.

Granted, I melded everyone's suggestions into a more fully formed
'bigtime' feature patchset that I'll dump out soon as part of my usual
end of year carpetbombing of the mailing list, so we likely still need
most of this patch anyway...

> Any application using these needs to be updated to use the v5
> interfaces.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  fs/xfs/xfs_ioctl.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index 7b35d62ede9f..a4a4eed8879c 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -36,6 +36,7 @@
>  #include "xfs_reflink.h"
>  #include "xfs_ioctl.h"
>  
> +#include <linux/compat.h>
>  #include <linux/mount.h>
>  #include <linux/namei.h>
>  
> @@ -617,6 +618,23 @@ xfs_fsinumbers_fmt(
>  	return xfs_ibulk_advance(breq, sizeof(struct xfs_inogrp));
>  }
>  
> +/* disallow y2038-unsafe ioctls with CONFIG_COMPAT_32BIT_TIME=n */
> +static bool xfs_have_compat_bstat_time32(unsigned int cmd)

The v5 bulkstat ioctls follow an entirely separate path through
xfs_ioctl.c, so I think you don't need the @cmd parameter.

> +{
> +	if (IS_ENABLED(CONFIG_COMPAT_32BIT_TIME))
> +		return true;
> +
> +	if (IS_ENABLED(CONFIG_64BIT) && !in_compat_syscall())
> +		return true;
> +
> +	if (cmd == XFS_IOC_FSBULKSTAT_SINGLE ||
> +	    cmd == XFS_IOC_FSBULKSTAT ||
> +	    cmd == XFS_IOC_SWAPEXT)
> +		return false;
> +
> +	return true;
> +}
> +
>  STATIC int
>  xfs_ioc_fsbulkstat(
>  	xfs_mount_t		*mp,
> @@ -637,6 +655,9 @@ xfs_ioc_fsbulkstat(
>  	if (!capable(CAP_SYS_ADMIN))
>  		return -EPERM;
>  
> +	if (!xfs_have_compat_bstat_time32(cmd))
> +		return -EINVAL;
> +
>  	if (XFS_FORCED_SHUTDOWN(mp))
>  		return -EIO;
>  
> @@ -1815,6 +1836,11 @@ xfs_ioc_swapext(
>  	struct fd	f, tmp;
>  	int		error = 0;
>  
> +	if (xfs_have_compat_bstat_time32(XFS_IOC_SWAPEXT)) {

if (!xfs_have...()) ?

--D

> +		error = -EINVAL;
> +		goto out;
> +	}
> +
>  	/* Pull information for the target fd */
>  	f = fdget((int)sxp->sx_fdtarget);
>  	if (!f.file) {
> -- 
> 2.20.0
> 

  reply	other threads:[~2019-12-13 21:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13 20:49 [PATCH v2 00/24] drivers, fs: y2038 updates Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 19/24] xfs: rename compat_time_t to old_time32_t Arnd Bergmann
2019-12-13 21:18   ` Darrick J. Wong
2019-12-16 16:31     ` Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 20/24] xfs: disallow broken ioctls without compat-32-bit-time Arnd Bergmann
2019-12-13 21:05   ` Darrick J. Wong [this message]
2019-12-16 16:45     ` Arnd Bergmann
2019-12-16 16:52       ` Darrick J. Wong
2019-12-17 15:06         ` Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 21/24] xfs: quota: move to time64_t interfaces Arnd Bergmann
2019-12-13 21:17   ` Darrick J. Wong
2019-12-16 16:52     ` Arnd Bergmann
2019-12-17 15:02       ` Arnd Bergmann
2019-12-17 22:15         ` Darrick J. Wong
2019-12-18 16:44           ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191213210509.GK99875@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=allison.henderson@oracle.com \
    --cc=arnd@arndb.de \
    --cc=bfoster@redhat.com \
    --cc=dchinner@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox