Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 22 Jul 2019 20:31:32 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Kees Cook <keescook@chromium.org>
cc:     Andy Lutomirski <luto@amacapital.net>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [5.2 REGRESSION] Generic vDSO breaks seccomp-enabled userspace
 on i386
In-Reply-To: <201907221012.41504DCD@keescook>
Message-ID: <alpine.DEB.2.21.1907222027090.1659@nanos.tec.linutronix.de>
References: <20190719170343.GA13680@linux.intel.com> <19EF7AC8-609A-4E86-B45E-98DFE965DAAB@amacapital.net> <201907221012.41504DCD@keescook>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 22 Jul 2019, Kees Cook wrote:
> On Fri, Jul 19, 2019 at 01:40:13PM -0400, Andy Lutomirski wrote:
> > > On Jul 19, 2019, at 1:03 PM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> > > 
> > > The generic vDSO implementation, starting with commit
> > > 
> > >   7ac870747988 ("x86/vdso: Switch to generic vDSO implementation")
> > > 
> > > breaks seccomp-enabled userspace on 32-bit x86 (i386) kernels.  Prior to
> > > the generic implementation, the x86 vDSO used identical code for both
> > > x86_64 and i386 kernels, which worked because it did all calcuations using
> > > structs with naturally sized variables, i.e. didn't use __kernel_timespec.
> > > 
> > > The generic vDSO does its internal calculations using __kernel_timespec,
> > > which in turn requires the i386 fallback syscall to use the 64-bit
> > > variation, __NR_clock_gettime64.
> > 
> > This is basically doomed to break eventually, right?
> 
> Just so I'm understanding: the vDSO change introduced code to make an
> actual syscall on i386, which for most seccomp filters would be rejected?

No. The old x86 specific VDSO implementation had a fallback syscall as
well, i.e. clock_gettime(). On 32bit clock_gettime() uses the y2038
endangered timespec.

So when the VDSO was made generic we changed the internal data structures
to be 2038 safe right away. As a consequence the fallback syscall is not
clock_gettime(), it's clock_gettime64(). which seems to surprise seccomp.

Thanks,

	tglx