[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140306152458.GG5202@mudshark.cambridge.arm.com>
Date: Thu, 6 Mar 2014 15:24:58 +0000
From: Will Deacon <will.deacon@....com>
To: AKASHI Takahiro <takahiro.akashi@...aro.org>
Cc: "wad@...omium.org" <wad@...omium.org>,
Catalin Marinas <Catalin.Marinas@....com>,
"dsaxena@...aro.org" <dsaxena@...aro.org>,
"arndb@...db.de" <arndb@...db.de>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/3] arm64: Add seccomp support
On Thu, Mar 06, 2014 at 02:34:46AM +0000, AKASHI Takahiro wrote:
> On 03/01/2014 02:20 AM, Will Deacon wrote:
> > On Tue, Feb 25, 2014 at 09:20:24AM +0000, AKASHI Takahiro wrote:
> > I'm slightly surprised that we do the secure computing check first. Doesn't
> > this allow a debugger to change the syscall to something else after we've
> > decided that it's ok?
>
> To be honest, I just followed other architectures' implementation.
> Can you elaborate any use case that you have in your mind?
My initial thought was that we should do the secure_computing check *after*
the debugger has finished messing around with the registers. However, I
suppose you'd have had to enable ptrace in your seccompd filter for that
scenario to occur, so there's probably not an issue here after all.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists