linux-ext4 - Re: [PATCH 1/3] ext4: add EXT4_IOC

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:	Sun, 17 Aug 2008 22:36:56 -0400
From:	Theodore Tso <tytso@....edu>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/3] ext4: add EXT4_IOC_GETCRTIME ioctl

On Mon, Aug 18, 2008 at 10:08:11AM +0800, Li Zefan wrote:
> > 
> > I'm worried about writing a struct timespec directly to user space,
> > because the kernel's idea of what is struct timespec might not be the
> > same as the userspace's understanding of struct timespec ---
> 
> We have system call nanosleep(), which copies a struct timespec directly
> from user space.

The difference is that for system calls, we have a glue layer (glibc)
whose duties include translating between the kernel data structures
and the userpsace data structures --- and for various architectures
there are ***no*** guarantees that the interfaces shipped by glibc in
/usr/include match up with the data structures used by the kernel in
/usr/src/linux/include/linux.

When you use an ioctl, you bypass the glibc translation layer, so life
can get iffy here.  And given that struct timespec contains time_t,
which *can* differ from architecture to architecure in in terms of
being either 32 bits or 64 bits, and what is in the kernel might be
different from what is in the user space /usr/include, I get doubly
nervous.

> > I think we would be better off explicitly defining a structure, or
> > just returning the seconds and nanoseconds in explicit primitive
> > types.

That's the quick and dirty fast answer, yes.  The long-term (but one
which involves much more work) is to define a new struct
kernel<->glibc stat interface (we already have 5 or so :-) to extend
it include st_crtime, and then try to get glibc to use the magic of
ELF symbol versioning so there is a new struct stat as defined in
/usr/include, and a new stat(2) call defined in glibc, which returns
the new struct stat which include st_crtime.  This also means we have
to define proper semantics for what happens if a filesystem doesn't
support st_crtime.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html