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
| ||
|
Date: Thu, 09 Jun 2016 20:19:53 -0400 From: Steve Grubb <sgrubb@...hat.com> To: Richard Guy Briggs <rgb@...hat.com> Cc: linux-audit@...hat.com, Arnd Bergmann <arnd@...db.de>, y2038@...ts.linaro.org, linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>, linux-fsdevel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, Linus Torvalds <torvalds@...ux-foundation.org>, Deepa Dinamani <deepa.kernel@...il.com> Subject: Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps 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
Powered by blists - more mailing lists