On Sun, 28 Jul 2019, Thomas Gleixner wrote:
> On Sun, 28 Jul 2019, Arnd Bergmann wrote:
>
> > On Sun, Jul 28, 2019 at 12:30 PM Thomas Gleixner wrote:
> > > On Sun, 28 Jul 2019, Arnd Bergmann wrote:
> > > > On Sat, Jul 27, 2019 at 7:53 PM Andy Lutomirski wrote:
> >
> > > Which is totally
On Sun, 28 Jul 2019, Arnd Bergmann wrote:
> On Sun, Jul 28, 2019 at 12:30 PM Thomas Gleixner wrote:
> > On Sun, 28 Jul 2019, Arnd Bergmann wrote:
> > > On Sat, Jul 27, 2019 at 7:53 PM Andy Lutomirski wrote:
>
> > Which is totally irrelevant because res is NULL and that NULL pointer check
> >
On Sun, Jul 28, 2019 at 12:30 PM Thomas Gleixner wrote:
> On Sun, 28 Jul 2019, Arnd Bergmann wrote:
> > On Sat, Jul 27, 2019 at 7:53 PM Andy Lutomirski wrote:
> Which is totally irrelevant because res is NULL and that NULL pointer check
> should simply return -EFAULT, which is what the syscall
On Sun, 28 Jul 2019, Arnd Bergmann wrote:
> We also need to decide what to do about __cvdso_clock_gettime32()
> once we add a compile-time option to make all time32 syscalls
> to return an error. Returning -ENOSYS from the clock_gettime32()
> fallback is probably a good idea, but for consistency
On Sun, 28 Jul 2019, Arnd Bergmann wrote:
> On Sat, Jul 27, 2019 at 7:53 PM Andy Lutomirski wrote:
> lib/vdso/gettimeofday.c:
> static __maybe_unused int
> __cvdso_clock_gettime32(clockid_t clock, struct old_timespec32 *res)
> {
> struct __kernel_timespec ts;
> int ret;
>
>
On Sat, Jul 27, 2019 at 7:53 PM Andy Lutomirski wrote:
>
> On Fri, Jul 26, 2019 at 11:01 AM Sean Christopherson
> wrote:
> >
> > 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,
On Sat, Jul 27, 2019 at 2:52 PM Thomas Gleixner wrote:
>
> On Sat, 27 Jul 2019, Thomas Gleixner wrote:
> > On Sat, 27 Jul 2019, Andy Lutomirski wrote:
> > >
> > > I think it's getting quite late to start inventing new seccomp
> > > features to fix this. I think the right solution for 5.3 is to
On Sat, 27 Jul 2019, Thomas Gleixner wrote:
> On Sat, 27 Jul 2019, Andy Lutomirski wrote:
> >
> > I think it's getting quite late to start inventing new seccomp
> > features to fix this. I think the right solution for 5.3 is to change
> > the 32-bit vdso fallback to use the old clock_gettime,
On Sat, 27 Jul 2019, Andy Lutomirski wrote:
> On Fri, Jul 26, 2019 at 11:01 AM Sean Christopherson
> wrote:
> >
> > +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
On Fri, Jul 26, 2019 at 11:01 AM Sean Christopherson
wrote:
>
> +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
+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
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()
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
>
On Tue, 23 Jul 2019, Kees Cook wrote:
> On Mon, Jul 22, 2019 at 04:47:36PM -0700, Andy Lutomirski wrote:
> > I don't love this whole concept, but I also don't have a better idea.
>
> How about we revert the vDSO change? :P
Sigh. Add more special case code to the VDSO again?
> I keep coming back
On Tue, Jul 23, 2019 at 2:55 PM Kees Cook wrote:
>
> On Mon, Jul 22, 2019 at 04:47:36PM -0700, Andy Lutomirski wrote:
> > On Mon, Jul 22, 2019 at 4:28 PM Kees Cook wrote:
> > > I've built a straw-man for this idea... but I have to say I don't
> > > like it. This can lead to really unexpected
On Mon, Jul 22, 2019 at 04:47:36PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 22, 2019 at 4:28 PM Kees Cook wrote:
> > I've built a straw-man for this idea... but I have to say I don't
> > like it. This can lead to really unexpected behaviors if someone
> > were to have differing filters for the
On Tue, Jul 23, 2019 at 07:04:46AM -0700, Andy Lutomirski wrote:
>
>
> > On Jul 23, 2019, at 2:18 AM, Peter Zijlstra wrote:
> >
> >> On Mon, Jul 22, 2019 at 04:47:36PM -0700, Andy Lutomirski wrote:
> >>
> >> I don't love this whole concept, but I also don't have a better idea.
> >
> > Are we
> On Jul 23, 2019, at 2:18 AM, Peter Zijlstra wrote:
>
>> On Mon, Jul 22, 2019 at 04:47:36PM -0700, Andy Lutomirski wrote:
>>
>> I don't love this whole concept, but I also don't have a better idea.
>
> Are we really talking about changing the kernel because BPF is expecting
> things? That
On Mon, Jul 22, 2019 at 04:47:36PM -0700, Andy Lutomirski wrote:
> I don't love this whole concept, but I also don't have a better idea.
Are we really talking about changing the kernel because BPF is expecting
things? That is, did we just elevate everything BPF can observe to ABI?
/me runs for
On Mon, Jul 22, 2019 at 4:28 PM Kees Cook wrote:
>
> On Mon, Jul 22, 2019 at 12:17:16PM -0700, Andy Lutomirski wrote:
> > On Mon, Jul 22, 2019 at 11:39 AM Kees Cook wrote:
> > >
> > > On Mon, Jul 22, 2019 at 08:31:32PM +0200, Thomas Gleixner wrote:
> > > > On Mon, 22 Jul 2019, Kees Cook wrote:
>
On Mon, Jul 22, 2019 at 12:17:16PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 22, 2019 at 11:39 AM Kees Cook wrote:
> >
> > On Mon, Jul 22, 2019 at 08:31:32PM +0200, Thomas Gleixner wrote:
> > > On Mon, 22 Jul 2019, Kees Cook wrote:
> > > > Just so I'm understanding: the vDSO change introduced
On Mon, Jul 22, 2019 at 11:39 AM Kees Cook wrote:
>
> On Mon, Jul 22, 2019 at 08:31:32PM +0200, Thomas Gleixner wrote:
> > On Mon, 22 Jul 2019, Kees Cook wrote:
> > > Just so I'm understanding: the vDSO change introduced code to make an
> > > actual syscall on i386, which for most seccomp filters
On Mon, Jul 22, 2019 at 08:31:32PM +0200, Thomas Gleixner wrote:
> On Mon, 22 Jul 2019, Kees Cook wrote:
> > 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
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
> > > wrote:
> > >
> > > The generic vDSO implementation, starting with commit
> > >
> > > 7ac870747988 ("x86/vdso: Switch to
On Fri, Jul 19, 2019 at 01:40:13PM -0400, Andy Lutomirski wrote:
> > On Jul 19, 2019, at 1:03 PM, Sean Christopherson
> > wrote:
> >
> > The generic vDSO implementation, starting with commit
> >
> > 7ac870747988 ("x86/vdso: Switch to generic vDSO implementation")
> >
> > breaks
> On Jul 19, 2019, at 1:03 PM, Sean Christopherson
> 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
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
27 matches
Mail list logo
