linux-kernel - Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps

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:	Wed, 15 Jun 2016 17:23:20 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Deepa Dinamani <deepa.kernel@...il.com>,
	Richard Guy Briggs <rgb@...hat.com>,
	Steve Grubb <sgrubb@...hat.com>
Cc:	Arnd Bergmann <arnd@...db.de>, y2038@...ts.linaro.org,
	linux-kernel@...r.kernel.org, linux-audit@...hat.com,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps

On Thu, Jun 9, 2016 at 7:59 PM, Richard Guy Briggs <rgb@...hat.com> 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...)

Yeah, I'm not really worried about the string date field growing; this
is more an internal implementation detail to make sure we can keep the
lights on in a few decades from now.

Deepa, I'm not going to merge your patchset because I'm guessing all
your timespec64 patches will likely go in at once, but you are free to
add my ack if you need to respin.

Acked-by: Paul Moore <paul@...l-moore.com>

-- 
paul moore
www.paul-moore.com