From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@kernel.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Paul Bolle <pebolle@tiscali.nl>
Subject: Re: [5.2 REGRESSION] Generic vDSO breaks seccomp-enabled userspace on i386
Date: Fri, 26 Jul 2019 11:01:03 -0700 [thread overview]
Message-ID: <20190726180103.GE3188@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1907240155080.2034@nanos.tec.linutronix.de>
+cc Paul
On Wed, Jul 24, 2019 at 01:56:34AM +0200, Thomas Gleixner wrote:
> On Tue, 23 Jul 2019, Kees Cook wrote:
>
> > On Wed, Jul 24, 2019 at 12:59:03AM +0200, Thomas Gleixner wrote:
> > > And as we have sys_clock_gettime64() exposed for 32bit anyway you need to
> > > deal with that in seccomp independently of the VDSO. It does not make sense
> > > to treat sys_clock_gettime() differently than sys_clock_gettime64(). They
> > > both expose the same information, but the latter is y2038 safe.
> >
> > Okay, so combining Andy's ideas on aliasing and "more seccomp flags",
> > we could declare that clock_gettime64() is not filterable on 32-bit at
> > all without the magic SECCOMP_IGNORE_ALIASES flag or something. Then we
> > would alias clock_gettime64 to clock_gettime _before_ the first evaluation
> > (unless SECCOMP_IGNORE_ALIASES is set)?
> >
> > (When was clock_gettime64() introduced? Is it too long ago to do this
> > "you can't filter it without a special flag" change?)
>
> clock_gettime64() and the other sys_*time64() syscalls which address the
> y2038 issue were added in 5.1
Paul Bolle pointed out that this regression showed up in v5.3-rc1, not
v5.2. In Paul's case, systemd-journal is failing.
next prev parent reply other threads:[~2019-07-26 18:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 17:03 [5.2 REGRESSION] Generic vDSO breaks seccomp-enabled userspace on i386 Sean Christopherson
2019-07-19 17:40 ` Andy Lutomirski
2019-07-22 17:16 ` Kees Cook
2019-07-22 18:31 ` Thomas Gleixner
2019-07-22 18:39 ` Kees Cook
2019-07-22 19:17 ` Andy Lutomirski
2019-07-22 23:28 ` Kees Cook
2019-07-22 23:47 ` Andy Lutomirski
2019-07-23 9:18 ` Peter Zijlstra
2019-07-23 14:04 ` Andy Lutomirski
2019-07-23 15:14 ` Peter Zijlstra
2019-07-23 21:55 ` Kees Cook
2019-07-23 22:55 ` Andy Lutomirski
2019-07-23 22:59 ` Thomas Gleixner
2019-07-23 23:43 ` Kees Cook
2019-07-23 23:56 ` Thomas Gleixner
2019-07-26 18:01 ` Sean Christopherson [this message]
2019-07-27 17:49 ` Andy Lutomirski
2019-07-27 18:43 ` Thomas Gleixner
2019-07-27 21:52 ` Thomas Gleixner
2019-07-28 0:33 ` Andy Lutomirski
2019-07-28 9:57 ` Arnd Bergmann
2019-07-28 10:30 ` Thomas Gleixner
2019-07-28 15:27 ` Arnd Bergmann
2019-07-28 18:14 ` Thomas Gleixner
2019-07-28 18:16 ` Thomas Gleixner
2019-07-28 11:13 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190726180103.GE3188@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pebolle@tiscali.nl \
--cc=tglx@linutronix.de \
--cc=vincenzo.frascino@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.