linux-kernel - [RFC 04/32] fs: introduce sys_newfstat64/sys

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: <1401480116-1973111-5-git-send-email-arnd@arndb.de>
Date:	Fri, 30 May 2014 22:01:28 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-kernel@...r.kernel.org
Cc:	linux-arch@...r.kernel.org, joseph@...esourcery.com,
	john.stultz@...aro.org, hch@...radead.org, tglx@...utronix.de,
	geert@...ux-m68k.org, lftan@...era.com, hpa@...or.com,
	linux-fsdevel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>
Subject: [RFC 04/32] fs: introduce sys_newfstat64/sys_newfstatat64

We want to be able to read file system timestamps beyond year 2038,
which is currently impossibly on 32-bit systems, since none of the
various stat syscall interfaces (oldstat, stat, stat64) handles
correctly.

This introduces a fourth version of the syscalls, called newfstat64
and newfstatat64, which operate on struct newstat64. Each 32-bit
architecture needs to define a version of this structure.
Architectures that have a 64-bit CPU should use the native 64-bit
'struct stat' if possible, so we can avoid adding a compat_newfstatat64
syscall. Note that there is no sys_newlstat64 or sys_newstat64,
as both can be trivially emulated from libc using newfstatat64.

This approach might not be the best solution, as there have been
proposals in the past to add a new 'struct xstat' interface that
would not only solve the y2038 problem but provide a number of
other extensions as well. I have chickened out and avoided reviving
that discussion for now. This new set of syscalls is a much simpler
addition and is hopefully less controversial.
If we end up merging xstat first, we won't need this patch.

Signed-off-by: Arnd Bergmann <arnd@...db.de>
---
 fs/stat.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/fs/stat.c b/fs/stat.c
index ae0c3ce..77fd219 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -445,6 +445,61 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename,
 }
 #endif /* __ARCH_WANT_STAT64 || __ARCH_WANT_COMPAT_STAT64 */
 
+#ifdef __ARCH_HAS_NEWSTAT64
+/*
+ * we only need this for the native 32-bit path, all architectures should
+ * define the 32-bit newstat64 as compatible with the 64-bit stat or
+ * stat64.
+ */
+static long cp_new_newstat64(struct kstat *stat, struct newstat64 __user *statbuf)
+{
+	struct newstat64 tmp;
+
+	memset(&tmp, 0, sizeof(tmp));
+	tmp.st_dev = huge_encode_dev(stat->dev);
+	tmp.st_rdev = huge_encode_dev(stat->rdev);
+	tmp.st_ino = stat->ino;
+	tmp.st_mode = stat->mode;
+	tmp.st_nlink = stat->nlink;
+	tmp.st_uid = from_kuid_munged(current_user_ns(), stat->uid);
+	tmp.st_gid = from_kgid_munged(current_user_ns(), stat->gid);
+	tmp.st_atime = stat->atime.tv_sec;
+	tmp.st_atime_nsec = stat->atime.tv_nsec;
+	tmp.st_mtime = stat->mtime.tv_sec;
+	tmp.st_mtime_nsec = stat->mtime.tv_nsec;
+	tmp.st_ctime = stat->ctime.tv_sec;
+	tmp.st_ctime_nsec = stat->ctime.tv_nsec;
+	tmp.st_size = stat->size;
+	tmp.st_blocks = stat->blocks;
+	tmp.st_blksize = stat->blksize;
+	return copy_to_user(statbuf,&tmp,sizeof(tmp)) ? -EFAULT : 0;
+}
+
+SYSCALL_DEFINE2(newfstat64, unsigned long, fd, struct newstat64 __user *, statbuf)
+{
+	struct kstat stat;
+	int error;
+
+	error = vfs_fstat(fd, &stat);
+	if (error)
+		return error;
+
+	return cp_new_newstat64(&stat, statbuf);
+}
+
+SYSCALL_DEFINE4(newfstatat64, int, dfd, const char __user *, filename,
+		struct newstat64 __user *, statbuf, int, flag)
+{
+	struct kstat stat;
+	int error;
+
+	error = vfs_fstatat(dfd, filename, &stat, flag);
+	if (error)
+		return error;
+	return cp_new_newstat64(&stat, statbuf);
+}
+#endif
+
 /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */
 void __inode_add_bytes(struct inode *inode, loff_t bytes)
 {
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/