Re: [Y2038] [PATCH 17/21] audit: Use timespec64 to represent audit timestamps

[Richard Guy Briggs]

On 16/06/09, Steve Grubb wrote:
> On Thursday, June 09, 2016 07:59:43 PM Richard Guy Briggs wrote:
> > On 16/06/09, Steve Grubb wrote:
> > > On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
> > > > struct timespec is not y2038 safe.
> > > > Audit timestamps are recorded in string format into
> > > > an audit buffer for a given context.
> > > > These mark the entry timestamps for the syscalls.
> > > > Use y2038 safe struct timespec64 to represent the times.
> > > > The log strings can handle this transition as strings can
> > > > hold upto 1024 characters.
> > > 
> > > Have you tested this with ausearch or any audit utilities? As an aside, a
> > > time stamp that is up to 1024 characters long is terribly wasteful
> > > considering how many events we get.
> > 
> > Steve,
> > 
> > I don't expect the size of the time stamp text to change since the
> > format isn't being changed and I don't expect the date stamp text length
> > to change until Y10K, but you never know what will happen in 8
> > millenia...  (Who knows, maybe that damn Linux server in my basement
> > will still be running then...)
> > 
> > Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)?
> 
> Bytes, yes. But I was thinking that if its going to get big we should 
> consider 
> switching from a base 10 representation to base 16. That would give us back a 
> few bytes. We discuss this on the linux-audit list rather than the main list.

This seems like a false economy to me.  If I understand correctly, it
will be 285 years before we roll the next text digit.  The next binary
digit in the internal kernel format is in 22 years.

I know there have been discussions about changing to a binary format,
which seems to have a lot more to offer than breaking the current format
for a few bytes.

Is this not the linux-audit main list?  Is there another one I am
missing?

> -Steve

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 06/21] fs: udf: Replace CURRENT_TIME with current_fs_time()

[Deepa Dinamani]

On Thu, Jun 9, 2016 at 12:41 AM, Jan Kara  wrote:
> On Wed 08-06-16 22:04:50, Deepa Dinamani wrote:
>> Logical Volume Integrity format is described to have the
>> same timestamp format for "Recording Date and time" as
>> the other [a,c,m]timestamps.
>> Hence using current_fs_time() instead here promises to
>> maintain the same granularity as other timestamps.
>>
> Just one nit below.
>
>> @@ -2030,7 +2030,7 @@ static void udf_close_lvid(struct super_block *sb)
>> - udf_time_to_disk_stamp(>recordingDateAndTime, CURRENT_TIME);
>> + udf_time_to_disk_stamp(>recordingDateAndTime, 
>> current_fs_time(sb));
>
> Please wrap this line properly so that it does not exceed 80 characters.
> Other than that feel free to add:
>
> Reviewed-by: Jan Kara 

Thanks, I will take care of this in v2 of the patch series.
- Deepa
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 17/21] audit: Use timespec64 to represent audit timestamps

[Deepa Dinamani]

On Thu, Jun 9, 2016 at 7:31 AM, Steve Grubb  wrote:
> On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
>> Audit timestamps are recorded in string format into
>> an audit buffer for a given context.
>> These mark the entry timestamps for the syscalls.
>> Use y2038 safe struct timespec64 to represent the times.
>> The log strings can handle this transition as strings can
>> hold upto 1024 characters.
>
> Have you tested this with ausearch or any audit utilities? As an aside, a time
> stamp that is up to 1024 characters long is terribly wasteful considering how
> many events we get.

/* AUDIT_BUFSIZ is the size of the temporary buffer used for formatting
 * audit records.  Since printk uses a 1024 byte buffer, this buffer
 * should be at least that large. */
#define AUDIT_BUFSIZ 1024

The commit text is pointing out that the reserve space ensured in each
call to audit_log_vformat is already much more than is needed by this
call from audit_log_start.

Also, since struct timespec64 is already the same as struct timespec
on 64-bit systems, there is really no functional change except on
32-bit machines.

Let me know if you want me to try it out on a 32-bit system.

-Deepa
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 17/21] audit: Use timespec64 to represent audit timestamps

[Steve Grubb]

On Thursday, June 09, 2016 07:59:43 PM Richard Guy Briggs wrote:
> On 16/06/09, Steve Grubb wrote:
> > On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
> > > struct timespec is not y2038 safe.
> > > Audit timestamps are recorded in string format into
> > > an audit buffer for a given context.
> > > These mark the entry timestamps for the syscalls.
> > > Use y2038 safe struct timespec64 to represent the times.
> > > The log strings can handle this transition as strings can
> > > hold upto 1024 characters.
> > 
> > Have you tested this with ausearch or any audit utilities? As an aside, a
> > time stamp that is up to 1024 characters long is terribly wasteful
> > considering how many events we get.
> 
> Steve,
> 
> I don't expect the size of the time stamp text to change since the
> format isn't being changed and I don't expect the date stamp text length
> to change until Y10K, but you never know what will happen in 8
> millenia...  (Who knows, maybe that damn Linux server in my basement
> will still be running then...)
> 
> Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)?

Bytes, yes. But I was thinking that if its going to get big we should consider 
switching from a base 10 representation to base 16. That would give us back a 
few bytes. We discuss this on the linux-audit list rather than the main list.

-Steve
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 18/21] fs: nfs: Make nfs boot time y2038 safe

[Trond Myklebust]

On 6/9/16, 01:05, "Deepa Dinamani"  wrote:

>boot_time is represented as a struct timespec.
>struct timespec and CURRENT_TIME are not y2038 safe.
>Overall, the plan is to use timespec64 for all internal
>kernel representation of timestamps.
>CURRENT_TIME will also be removed.
>Use struct timespec64 to represent boot_time.
>And, ktime_get_real_ts64() for the boot_time value.
>
>boot_time is used to construct the nfs client boot verifier.
>This will now wrap in 2106 instead of 2038 on 32-bit systems.
>The server only relies on the value being persistent until
>reboot so the wrapping should be fine.

We really do not give a damn about wraparound here, since the boot time is only 
ever compared for an exact match, and the odds of two reboots occurring exactly 
2^32 * 10^9 nanoseconds apart are cosmically small...

If struct timespec is going away, can we just convert this into a ktime_t?

Trond

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()

[Linus Torvalds]

On Thu, Jun 9, 2016 at 12:35 AM, Jan Kara  wrote:
>
> You create line longer than 80 characters for affs and reiserfs. Please
> wrap those lines properly.

No, please do *NOT* do things like that.

These kind of mechanical patches should

 (a) be as mechanical as possible (and see elsewhere about why I think
'sb' should be 'inode' and the patch should have been 95% automated
with a trivial script thanks to that change)

 (b) be made as easy to verify visually as possible.

That (b) means that a conversion should *not* add whitespace fixups or
add other non-mechanical cleanups, because it's a *lot* easier to see
that a conversion like

-   inode->i_mtime = inode->i_ctime = CURRENT_TIME_SEC;
+   inode->i_mtime = inode->i_ctime = current_fs_time(inode);

makes no other changes, but if you start doing line-splitting or other
transformations (add new variables etc to get at 'sb'), suddenly you
have to verify the patch at a completely different level.

In other words, it's actually really important to make these kinds of
bulk changes be very very obvious. Including to the point of making
them visually easier to scan as a patch by not making any other
changes.

  Linus
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 02/21] fs: ext4: Use current_fs_time() for inode timestamps

[Linus Torvalds]

On Wed, Jun 8, 2016 at 10:04 PM, Deepa Dinamani  wrote:
> CURRENT_TIME_SEC and CURRENT_TIME are not y2038 safe.
> current_fs_time() will be transitioned to be y2038 safe
> along with vfs.
>
> current_fs_time() returns timestamps according to the
> granularities set in the super_block.

All existing users and all the ones in this patch (and the others too,
although I didn't go through them very carefully) really would prefer
just passing in the inode directly, rather than the superblock.

So I don't want to add more users of this broken interface.  It was a
mistake to use the superblock. The fact that the time granularity
exists there is pretty much irrelevant. If every single user wants to
use an inode pointer, then that is what the function should get.

 Linus
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 17/21] audit: Use timespec64 to represent audit timestamps

[Steve Grubb]

On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
> struct timespec is not y2038 safe.
> Audit timestamps are recorded in string format into
> an audit buffer for a given context.
> These mark the entry timestamps for the syscalls.
> Use y2038 safe struct timespec64 to represent the times.
> The log strings can handle this transition as strings can
> hold upto 1024 characters.

Have you tested this with ausearch or any audit utilities? As an aside, a time 
stamp that is up to 1024 characters long is terribly wasteful considering how 
many events we get.

-Steve


> Signed-off-by: Deepa Dinamani 
> Cc: Paul Moore 
> Cc: Eric Paris 
> Cc: linux-au...@redhat.com
> ---
>  include/linux/audit.h |  4 ++--
>  kernel/audit.c| 10 +-
>  kernel/audit.h|  2 +-
>  kernel/auditsc.c  |  6 +++---
>  4 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 961a417..2f6a1123 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -335,7 +335,7 @@ static inline void audit_ptrace(struct task_struct *t)
>   /* Private API (for audit.c only) */
>  extern unsigned int audit_serial(void);
>  extern int auditsc_get_stamp(struct audit_context *ctx,
> -   struct timespec *t, unsigned int *serial);
> +   struct timespec64 *t, unsigned int *serial);
>  extern int audit_set_loginuid(kuid_t loginuid);
> 
>  static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
> @@ -510,7 +510,7 @@ static inline void __audit_seccomp(unsigned long
> syscall, long signr, int code) static inline void audit_seccomp(unsigned
> long syscall, long signr, int code) { }
>  static inline int auditsc_get_stamp(struct audit_context *ctx,
> -   struct timespec *t, unsigned int *serial)
> +   struct timespec64 *t, unsigned int *serial)
>  {
>   return 0;
>  }
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 22bb4f2..6c2f405 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1325,10 +1325,10 @@ unsigned int audit_serial(void)
>  }
> 
>  static inline void audit_get_stamp(struct audit_context *ctx,
> -struct timespec *t, unsigned int *serial)
> +struct timespec64 *t, unsigned int *serial)
>  {
>   if (!ctx || !auditsc_get_stamp(ctx, t, serial)) {
> - *t = CURRENT_TIME;
> + ktime_get_real_ts64(t);
>   *serial = audit_serial();
>   }
>  }
> @@ -1370,7 +1370,7 @@ struct audit_buffer *audit_log_start(struct
> audit_context *ctx, gfp_t gfp_mask, int type)
>  {
>   struct audit_buffer *ab = NULL;
> - struct timespec t;
> + struct timespec64   t;
>   unsigned intuninitialized_var(serial);
>   int reserve = 5; /* Allow atomic callers to go up to five
>   entries over the normal backlog limit */
> @@ -1422,8 +1422,8 @@ struct audit_buffer *audit_log_start(struct
> audit_context *ctx, gfp_t gfp_mask,
> 
>   audit_get_stamp(ab->ctx, , );
> 
> - audit_log_format(ab, "audit(%lu.%03lu:%u): ",
> -  t.tv_sec, t.tv_nsec/100, serial);
> + audit_log_format(ab, "audit(%llu.%03lu:%u): ",
> +  (unsigned long long)t.tv_sec, t.tv_nsec/100, 
> serial);
>   return ab;
>  }
> 
> diff --git a/kernel/audit.h b/kernel/audit.h
> index cbbe6bb..029d674 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -111,7 +111,7 @@ struct audit_context {
>   enum audit_statestate, current_state;
>   unsigned intserial; /* serial number for record */
>   int major;  /* syscall number */
> - struct timespec ctime;  /* time of syscall entry */
> + struct timespec64   ctime;  /* time of syscall entry */
>   unsigned long   argv[4];/* syscall arguments */
>   longreturn_code;/* syscall return code */
>   u64 prio;
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 62ab53d..ecebb3c 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1523,7 +1523,7 @@ void __audit_syscall_entry(int major, unsigned long
> a1, unsigned long a2, return;
> 
>   context->serial = 0;
> - context->ctime  = CURRENT_TIME;
> + ktime_get_real_ts64(>ctime);
>   context->in_syscall = 1;
>   context->current_state  = state;
>   context->ppid   = 0;
> @@ -1932,13 +1932,13 @@ EXPORT_SYMBOL_GPL(__audit_inode_child);
>  /**
>   * auditsc_get_stamp - get local copies of audit_context values
>   * @ctx: audit_context for the task
> - * @t: timespec to store time recorded in the audit_context
> + * @t: timespec64 to store time recorded in the audit_context
>   * @serial: serial value that is recorded 

Re: [Y2038] [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()

[Bob Copeland]

On Wed, Jun 08, 2016 at 10:04:45PM -0700, Deepa Dinamani wrote:
> CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will
> be transitioned to use 64 bit time along with vfs in a
> separate patch.
> There is no plan to transistion CURRENT_TIME_SEC to use
> y2038 safe time interfaces.

[...]

> Cc: Bob Copeland 

OMFS parts look sane, thanks.

-- 
Bob Copeland %% http://bobcopeland.com/
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()

[Jan Kara]

On Wed 08-06-16 22:04:45, Deepa Dinamani wrote:
> CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will
> be transitioned to use 64 bit time along with vfs in a
> separate patch.
> There is no plan to transistion CURRENT_TIME_SEC to use
> y2038 safe time interfaces.
> 
> current_fs_time() will also be extended to use superblock
> range checking parameters when range checking is introduced.
> 
> This works because alloc_super() fills in the the s_time_gran
> in super block to NSEC_PER_SEC.
> 
> Also note that filesystem specific times like the birthtime,
> creation time that were using same interfaces to obtain time
> retain same logistics.

You create line longer than 80 characters for affs and reiserfs. Please
wrap those lines properly. Other than that feel free to add:

Acked-by: Jan Kara 

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038