On Sat 05-09-20 09:47:03, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
>
> Soon, XFS will support quota grace period expiration timestamps beyond
> the year 2038, widen the timestamp fields to handle the extra time bits.
> Internally, XFS now stores unsigned 34-bit quantities, so the extra 8
> bits here should work fine. (Note that XFS is the only user of this
> structure.)
>
> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
Looks good to me. Just one question below:
> diff --git a/fs/quota/quota.c b/fs/quota/quota.c
> index 5444d3c4d93f..eefac57c52fd 100644
> --- a/fs/quota/quota.c
> +++ b/fs/quota/quota.c
> @@ -481,6 +481,14 @@ static inline u64 quota_btobb(u64 bytes)
> return (bytes + (1 << XFS_BB_SHIFT) - 1) >> XFS_BB_SHIFT;
> }
>
> +static inline s64 copy_from_xfs_dqblk_ts(const struct fs_disk_quota *d,
> + __s32 timer, __s8 timer_hi)
> +{
> + if (d->d_fieldmask & FS_DQ_BIGTIME)
> + return (u32)timer | (s64)timer_hi << 32;
> + return timer;
> +}
> +
So this doesn't do any checks that the resulting time fits into 34-bits you
speak about in the changelog. So how will XFS react if malicious / buggy
userspace will pass too big timestamp? I suppose xfs_fs_set_dqblk() should
return EFBIG or EINVAL or something like that which I'm not sure it does...
For record I've checked VFS quota implementation and it doesn't need any
checks because VFS in memory structures and on-disk format use 64-bit
timestamps. The ancient quota format uses 32-bit timestamps for 32-bit
archs so these would get silently truncated when stored on disk but
honestly I don't think I care (that format was deprecated some 20 years
ago).
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
