On Fri, Jul 10, 2020 at 01:42:54PM +0100, Will Deacon wrote:
> On Sat, Jul 04, 2020 at 09:56:50PM -0700, Kees Cook wrote:
> > (What doesn't pass for you? I tried to go find kernelci.org test output,
> > but it doesn't appear to actually run selftests yet?)
>
> Sorry, realised I forgot to reply to
On Sat, Jul 04, 2020 at 09:56:50PM -0700, Kees Cook wrote:
> On Sat, Jul 04, 2020 at 01:33:56PM +0100, Will Deacon wrote:
> > On Fri, Jul 03, 2020 at 08:52:05AM -0700, Kees Cook wrote:
> > > On Fri, Jul 03, 2020 at 04:44:27PM +0100, Will Deacon wrote:
> > > > On Fri, Jul 03, 2020 at 08:17:19AM -070
On Mon, Jul 06, 2020 at 09:15:51AM +0100, Will Deacon wrote:
> On Sat, Jul 04, 2020 at 09:56:50PM -0700, Kees Cook wrote:
> > different per-architecture expectations). If I read this thread
> > correctly, we need to test:
> >
> > syscall(-1), direct, returns ENOSYS
> > syscall(-10), direc
On Sat, Jul 04, 2020 at 09:56:50PM -0700, Kees Cook wrote:
> On Sat, Jul 04, 2020 at 01:33:56PM +0100, Will Deacon wrote:
> > On Fri, Jul 03, 2020 at 08:52:05AM -0700, Kees Cook wrote:
> > > On Fri, Jul 03, 2020 at 04:44:27PM +0100, Will Deacon wrote:
> > > > On Fri, Jul 03, 2020 at 08:17:19AM -070
On Sat, Jul 04, 2020 at 01:33:56PM +0100, Will Deacon wrote:
> On Fri, Jul 03, 2020 at 08:52:05AM -0700, Kees Cook wrote:
> > On Fri, Jul 03, 2020 at 04:44:27PM +0100, Will Deacon wrote:
> > > On Fri, Jul 03, 2020 at 08:17:19AM -0700, Kees Cook wrote:
> > > > On Fri, Jul 03, 2020 at 09:39:14AM +010
On Fri, Jul 03, 2020 at 04:27:37PM -0400, Keno Fischer wrote:
> > > Now, if we have a seccomp filter that simply does
> > > SECCOMP_RET_TRACE, and a ptracer that simply
> > > does PTRACE_CONT
> >
> > Ok, so this means that we're _skipping_ the system call, right?
>
> If the system call were positi
On Fri, Jul 03, 2020 at 08:52:05AM -0700, Kees Cook wrote:
> On Fri, Jul 03, 2020 at 04:44:27PM +0100, Will Deacon wrote:
> > On Fri, Jul 03, 2020 at 08:17:19AM -0700, Kees Cook wrote:
> > > On Fri, Jul 03, 2020 at 09:39:14AM +0100, Will Deacon wrote:
> > > > diff --git a/arch/arm64/kernel/syscall.
> > Now, if we have a seccomp filter that simply does
> > SECCOMP_RET_TRACE, and a ptracer that simply
> > does PTRACE_CONT
>
> Ok, so this means that we're _skipping_ the system call, right?
If the system call were positive this would result in the system call
being executed. The notion of "skipp
On Fri, Jul 03, 2020 at 04:44:27PM +0100, Will Deacon wrote:
> On Fri, Jul 03, 2020 at 08:17:19AM -0700, Kees Cook wrote:
> > On Fri, Jul 03, 2020 at 09:39:14AM +0100, Will Deacon wrote:
> > > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> > > index 5f5b868292f5..a13661f44
On Fri, Jul 03, 2020 at 08:17:19AM -0700, Kees Cook wrote:
> On Fri, Jul 03, 2020 at 09:39:14AM +0100, Will Deacon wrote:
> > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> > index 5f5b868292f5..a13661f44818 100644
> > --- a/arch/arm64/kernel/syscall.c
> > +++ b/arch/arm64
On Fri, Jul 03, 2020 at 09:39:14AM +0100, Will Deacon wrote:
> Hi Keno,
>
> On Fri, May 22, 2020 at 09:01:01PM -0400, Keno Fischer wrote:
> > I'm seeing the following while porting a ptracer from
> > x86_64 to arm64 (cc'ing arm64 folks, but in this case
> > x86_64 is the odd one out, I think other
Hi Keno,
On Fri, May 22, 2020 at 09:01:01PM -0400, Keno Fischer wrote:
> I'm seeing the following while porting a ptracer from
> x86_64 to arm64 (cc'ing arm64 folks, but in this case
> x86_64 is the odd one out, I think other archs would
> be consistent with arm64).
>
> Consider userspace code li
I'm seeing the following while porting a ptracer from
x86_64 to arm64 (cc'ing arm64 folks, but in this case
x86_64 is the odd one out, I think other archs would
be consistent with arm64).
Consider userspace code like the following:
```
int ret = syscall(-10, 0);
assert(ret == -ENOSYS);
```
(Never
13 matches
Mail list logo
