s://lore.kernel.org/lkml/20200612104629.GA15814@ircssh-2.c.rugged-nimbus-611.internal
>
> Suggested-by: Matt Denton
> Link: https://lore.kernel.org/r/20200603011044.7972-4-sar...@sargun.me
> Signed-off-by: Sargun Dhillon
> Co-developed-by: Kees Cook
> Signed-off-by: Kees Cook
Reviewed-by: Will Drewry
Hi Richard, Helen,
On Sat, Nov 3, 2018 at 4:10 AM Richard Weinberger wrote:
>
> Helen,
>
> Am Samstag, 3. November 2018, 04:53:39 CET schrieb Helen Koike:
> > As mentioned in the discussion from the previous version of this patch,
> > Android
> > and Chrome OS do not use initramfs mostly due to
Hi Richard, Helen,
On Sat, Nov 3, 2018 at 4:10 AM Richard Weinberger wrote:
>
> Helen,
>
> Am Samstag, 3. November 2018, 04:53:39 CET schrieb Helen Koike:
> > As mentioned in the discussion from the previous version of this patch,
> > Android
> > and Chrome OS do not use initramfs mostly due to
y should benefit to other test
> > components.
>
> Unless Shuah thinks this should live in a new include/ directory, this
> looks fine to me.
>
> Acked-by: Kees Cook <keesc...@chromium.org>
Same here!
Acked-by: Will Drewry <w...@chromium.org>
>
> Thanks
>
> Unless Shuah thinks this should live in a new include/ directory, this
> looks fine to me.
>
> Acked-by: Kees Cook
Same here!
Acked-by: Will Drewry
>
> Thanks!
>
> -Kees
>
> >
> > Signed-off-by: Mickaël Salaün
> > Cc: Andy Lutomirski
> >
On Wed, Jun 11, 2014 at 5:32 PM, Kees Cook wrote:
> On Wed, Jun 11, 2014 at 3:28 PM, Andy Lutomirski wrote:
>> On Wed, Jun 11, 2014 at 3:27 PM, H. Peter Anvin wrote:
>>> On 06/11/2014 03:22 PM, Andy Lutomirski wrote:
On Wed, Jun 11, 2014 at 3:18 PM, H. Peter Anvin wrote:
> On
On Wed, Jun 11, 2014 at 5:32 PM, Kees Cook keesc...@chromium.org wrote:
On Wed, Jun 11, 2014 at 3:28 PM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Jun 11, 2014 at 3:27 PM, H. Peter Anvin h...@zytor.com wrote:
On 06/11/2014 03:22 PM, Andy Lutomirski wrote:
On Wed, Jun 11, 2014 at 3:18
p.c:
>> kernel/seccomp.c:296:6: warning: no previous prototype for
>> 'seccomp_attach_user_filter' [-Wmissing-prototypes]
>>
>> Signed-off-by: Rashika Kheria
>> Reviewed-by: Josh Triplett
>
> Acked-by: Kees Cook
Acked-by: Will Drewry
It amazing what things s
/seccomp.c:
kernel/seccomp.c:296:6: warning: no previous prototype for
'seccomp_attach_user_filter' [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria rashika.khe...@gmail.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
Acked-by: Kees Cook keesc...@chromium.org
Acked-by: Will Drewry w
On Wed, Jan 15, 2014 at 1:04 PM, Oleg Nesterov wrote:
> On 01/14, Will Drewry wrote:
>>
>> On Tue, Jan 14, 2014 at 1:21 PM, Oleg Nesterov wrote:
>>
>> >> + get_seccomp_filter(caller);
>> >> + /*
>>
On Wed, Jan 15, 2014 at 1:04 PM, Oleg Nesterov o...@redhat.com wrote:
On 01/14, Will Drewry wrote:
On Tue, Jan 14, 2014 at 1:21 PM, Oleg Nesterov o...@redhat.com wrote:
+ get_seccomp_filter(caller);
+ /*
+ * Drop the task
On Tue, Jan 14, 2014 at 3:09 PM, Andy Lutomirski wrote:
> On Tue, Jan 14, 2014 at 12:59 PM, Will Drewry wrote:
>> On Tue, Jan 14, 2014 at 2:24 PM, Andy Lutomirski wrote:
>>> On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry wrote:
>>>> On Mon, Jan 13, 2014 at 5:36 PM
On Tue, Jan 14, 2014 at 1:21 PM, Oleg Nesterov wrote:
> On 01/13, Will Drewry wrote:
>>
>> +static pid_t seccomp_sync_threads(void)
>> +{
>> + struct task_struct *thread, *caller;
>> + pid_t failed = 0;
>> + thread = caller =
On Tue, Jan 14, 2014 at 2:24 PM, Andy Lutomirski wrote:
> On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry wrote:
>> On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski wrote:
>>> On 01/13/2014 12:30 PM, Will Drewry wrote:
>>>> Applying restrictive seccomp filte
On Tue, Jan 14, 2014 at 2:13 PM, Oleg Nesterov wrote:
> On 01/14, Oleg Nesterov wrote:
>>
>> On 01/14, Oleg Nesterov wrote:
>> >
>> > > + get_seccomp_filter(caller);
>> > > + /*
>> > > + * Drop the task reference to the shared ancestor since
>> > >
On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski wrote:
> On 01/13/2014 12:30 PM, Will Drewry wrote:
>> Applying restrictive seccomp filter programs to large or diverse
>> codebases often requires handling threads which may be started early in
>> the process lifetime (e.g., b
On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski l...@amacapital.net wrote:
On 01/13/2014 12:30 PM, Will Drewry wrote:
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code
On Tue, Jan 14, 2014 at 2:13 PM, Oleg Nesterov o...@redhat.com wrote:
On 01/14, Oleg Nesterov wrote:
On 01/14, Oleg Nesterov wrote:
+ get_seccomp_filter(caller);
+ /*
+ * Drop the task reference to the shared ancestor since
+
On Tue, Jan 14, 2014 at 2:24 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry w...@chromium.org wrote:
On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski l...@amacapital.net wrote:
On 01/13/2014 12:30 PM, Will Drewry wrote:
Applying restrictive seccomp
On Tue, Jan 14, 2014 at 1:21 PM, Oleg Nesterov o...@redhat.com wrote:
On 01/13, Will Drewry wrote:
+static pid_t seccomp_sync_threads(void)
+{
+ struct task_struct *thread, *caller;
+ pid_t failed = 0;
+ thread = caller = current;
+
+ read_lock(tasklist_lock
On Tue, Jan 14, 2014 at 3:09 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Jan 14, 2014 at 12:59 PM, Will Drewry w...@chromium.org wrote:
On Tue, Jan 14, 2014 at 2:24 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry w...@chromium.org wrote
(missed this on the first run)
Add an entry for the PR_SECCOMP_EXT entry point and the
only existing consumer, SECCOMP_EXT_ACT_TSYNC.
Signed-off-by: Will Drewry
---
Documentation/prctl/seccomp_filter.txt | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff
LL filters (where the task is running as
SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
transitioned into SECCOMP_MODE_FILTER. On success, 0 is returned. On
failure, the pid of one of the failing threads will be returned.
Suggested-by: Julien Tinnes
Signed-off-by: W
-by: Will Drewry
---
include/linux/seccomp.h |4 ++--
kernel/seccomp.c| 22 +-
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 6f19cfd..85c0895 100644
--- a/include/linux/seccomp.h
+++ b/include/linux
-by: Will Drewry w...@chromium.org
---
include/linux/seccomp.h |4 ++--
kernel/seccomp.c| 22 +-
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 6f19cfd..85c0895 100644
--- a/include/linux/seccomp.h
-by: Will Drewry w...@chromium.org
---
include/linux/seccomp.h |7 +++
include/uapi/linux/prctl.h |6 ++
include/uapi/linux/seccomp.h |6 ++
kernel/seccomp.c | 128 ++
kernel/sys.c |3 +
5 files changed, 150
(missed this on the first run)
Add an entry for the PR_SECCOMP_EXT entry point and the
only existing consumer, SECCOMP_EXT_ACT_TSYNC.
Signed-off-by: Will Drewry w...@chromium.org
---
Documentation/prctl/seccomp_filter.txt | 28 +++-
1 file changed, 27 insertions(+), 1
Thanks!
Reviewed-By: Will Drewry
On Wed, Nov 6, 2013 at 5:31 PM, Kees Cook wrote:
> Make sure that seccomp filter won't be built when ARM OABI is in use,
> since there is work needed to distinguish calling conventions. Until
> that is done (which is likely never since OABI is deprecat
On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
wrote:
> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
>> > 1. Set a different audit arch for OABI syscalls (e.g.
>> > AUDIT_ARCH_ARMOABI). That is, treat OABI
On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
1. Set a different audit arch for OABI syscalls (e.g.
AUDIT_ARCH_ARMOABI). That is,
Thanks!
Reviewed-By: Will Drewry w...@chromium.org
On Wed, Nov 6, 2013 at 5:31 PM, Kees Cook keesc...@chromium.org wrote:
Make sure that seccomp filter won't be built when ARM OABI is in use,
since there is work needed to distinguish calling conventions. Until
that is done (which is likely
On Mon, Oct 28, 2013 at 5:02 PM, Paul Moore wrote:
> On Thursday, October 24, 2013 02:14:15 PM Andy Lutomirski wrote:
>> On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore wrote:
>> > On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
>> >> I'm looking at the seccomp code, the ARM entry
On Mon, Oct 28, 2013 at 5:02 PM, Paul Moore pmo...@redhat.com wrote:
On Thursday, October 24, 2013 02:14:15 PM Andy Lutomirski wrote:
On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore pmo...@redhat.com wrote:
On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
I'm looking at the
(unsigned long long)hash_block);
> v->hash_failed = 1;
> r = -EIO;
> + verity_hash_error(v, (unsigned long long)hash_block);
> goto release_ret_r;
>
notifiers chains!)
Acked-by: Will Drewry w...@chromium.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
ed
>> code.
>>
>> Signed-off-by: Nicolas Schichan
>
> Acked-by: Kees Cook
>
> I'd love to see this for x86 too. I suspect it'd be a small change
> after this series lands.
Agreed - and thanks for working through the necessary changes!
Acked-By: Will Drewry
(for the s
-by: Nicolas Schichan nschic...@freebox.fr
Acked-by: Kees Cook keesc...@chromium.org
I'd love to see this for x86 too. I suspect it'd be a small change
after this series lands.
Agreed - and thanks for working through the necessary changes!
Acked-By: Will Drewry w...@chromium.org
(for the series
Better late than never .. right?
Acked-by: Will Drewry
Thanks!
On Fri, Mar 15, 2013 at 1:12 PM, Kees Cook wrote:
> On Fri, Mar 15, 2013 at 10:02 AM, Nicolas Schichan
> wrote:
>>
>> Signed-off-by: Nicolas Schichan
>
> Ah, good catch. Thanks!
>
> Acked-by:
Better late than never .. right?
Acked-by: Will Drewry w...@chromium.org
Thanks!
On Fri, Mar 15, 2013 at 1:12 PM, Kees Cook keesc...@chromium.org wrote:
On Fri, Mar 15, 2013 at 10:02 AM, Nicolas Schichan nschic...@freebox.fr
wrote:
Signed-off-by: Nicolas Schichan nschic...@freebox.fr
Ah
Arnd Bergmann
>> Cc: Heiko Carstens
>> Cc: Kees Cook
>> Cc: James Morris
>
> I'm fine with this. Thanks!
>
> Acked-by: Kees Cook
Thanks! This makes a lot of sense and maybe buys a bit more time to
figure out the best way to build these (all?) samples for the
I'm fine with this. Thanks!
Acked-by: Kees Cook keesc...@chromium.org
Thanks! This makes a lot of sense and maybe buys a bit more time to
figure out the best way to build these (all?) samples for the target.
Acked-by: Will Drewry w...@chromium.org
---
samples/seccomp/Makefile |2
Thanks for the patch!
On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant wrote:
> Adds a new return value to seccomp filters that causes an
> informational kernel message to be printed. The message
> includes the system call number.
I don't have strong opinions about this either way, but here are
Thanks for the patch!
On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant cor...@linux.vnet.ibm.com wrote:
Adds a new return value to seccomp filters that causes an
informational kernel message to be printed. The message
includes the system call number.
I don't have strong opinions about this
Thanks!
Acked-by: Will Drewry
On Wed, Nov 28, 2012 at 5:15 PM, Kees Cook wrote:
> The seccomp path was using AUDIT_ANOM_ABEND from when seccomp mode 1
> could only kill a process. While we still want to make sure an audit
> record is forced on a kill, this should use a separate re
Thanks!
Acked-by: Will Drewry w...@chromium.org
On Wed, Nov 28, 2012 at 5:15 PM, Kees Cook keesc...@chromium.org wrote:
The seccomp path was using AUDIT_ANOM_ABEND from when seccomp mode 1
could only kill a process. While we still want to make sure an audit
record is forced on a kill
>
> I'm not familiar with seccomp in general, but the changes look ok now from
> an ARM point-of-view:
>
> Reviewed-by: Will Deacon
>
> These should probably go via Russell (who will put them into -next), so
> please send them to the patch system.
>
For the seccomp sid
not familiar with seccomp in general, but the changes look ok now from
an ARM point-of-view:
Reviewed-by: Will Deacon will.dea...@arm.com
These should probably go via Russell (who will put them into -next), so
please send them to the patch system.
For the seccomp side,
Acked-by: Will Drewry w
On Tue, Aug 21, 2012 at 1:08 PM, Stephen Warren wrote:
> On 08/20/2012 10:47 PM, Will Drewry wrote:
>> On Mon, Aug 20, 2012 at 1:30 PM, Stephen Warren
>> wrote:
>>> On 08/20/2012 12:22 PM, Tejun Heo wrote:
>>>> Hello,
>>>>
>>>> On
On Tue, Aug 21, 2012 at 1:08 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/20/2012 10:47 PM, Will Drewry wrote:
On Mon, Aug 20, 2012 at 1:30 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 08/20/2012 12:22 PM, Tejun Heo wrote:
Hello,
On Fri, Aug 17, 2012 at 04:10:52PM -0600
On Mon, Aug 20, 2012 at 1:30 PM, Stephen Warren wrote:
> On 08/20/2012 12:22 PM, Tejun Heo wrote:
>> Hello,
>>
>> On Fri, Aug 17, 2012 at 04:10:52PM -0600, Stephen Warren wrote:
>>> I was considering extending the kernel command-line option
>>> root=PARTUUID= to also support MBR (NT disk
On Mon, Aug 20, 2012 at 1:30 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/20/2012 12:22 PM, Tejun Heo wrote:
Hello,
On Fri, Aug 17, 2012 at 04:10:52PM -0600, Stephen Warren wrote:
I was considering extending the kernel command-line option
root=PARTUUID= to also support MBR (NT disk
rn -ENOSYS) and older kernels (which
>> return the value from pt_regs). This is silly; we should just
>> return -ENOSYS.
>>
>> This is unlikely to ever happen on x86 because the return value in
>> pt_regs starts out as -ENOSYS, but a silly tracer can change that.
>&
...@amacapital.net
Cc: Will Drewry w...@chromium.org
---
arch/x86/include/asm/syscall.h | 11 +++
kernel/seccomp.c | 15 +++
2 files changed, 26 insertions(+), 0 deletions(-)
Will, can you pick this, or some version of it, up in your
seccomp-for-ARM tree
On Tue, Jul 17, 2012 at 9:13 PM, Will Drewry wrote:
> On Tue, Jul 17, 2012 at 6:19 PM, Andy Lutomirski wrote:
>> Currently, if a tracer changes a syscall nr to __NR_future_enosys,
>> behavior will differ between kernels that know about
>> __NR_future_enosys (and return -ENOS
n
>vsyscall by returning -ENOSYS. (This is unlikely to make a
>noticeable difference on x86-64 due to the way the system call
>entry works.)
>
> - On x86-64 with vsyscall=emulate, skipped vsyscalls were buggy.
>
> This updates the documentation accordingly.
>
> Signed-
...@amacapital.net
Cc: Will Drewry w...@chromium.org
---
Documentation/prctl/seccomp_filter.txt | 74 --
arch/x86/kernel/vsyscall_64.c | 110
+---
kernel/seccomp.c | 13 +++-
3 files changed, 137 insertions(+), 60
On Tue, Jul 17, 2012 at 9:13 PM, Will Drewry w...@chromium.org wrote:
On Tue, Jul 17, 2012 at 6:19 PM, Andy Lutomirski l...@amacapital.net wrote:
Currently, if a tracer changes a syscall nr to __NR_future_enosys,
behavior will differ between kernels that know about
__NR_future_enosys
his is silly; we should just
> return -ENOSYS.
>
> This is unlikely to ever happen on x86 because the return value in
> pt_regs starts out as -ENOSYS, but a silly tracer can change that.
>
> Signed-off-by: Andy Lutomirski
> Cc: Will Drewry
> ---
> arch/x86/include/asm
On Tue, Jul 17, 2012 at 6:19 PM, Andy Lutomirski wrote:
> Apologies for the lateness of this stuff. I was at a conference last
> week when the Chrome issue was discovered and I couldn't do this
> properly until I got back.
>
> Will, can you confirm that this version is okay and passes your
On Tue, Jul 17, 2012 at 6:19 PM, Andy Lutomirski l...@amacapital.net wrote:
Apologies for the lateness of this stuff. I was at a conference last
week when the Chrome issue was discovered and I couldn't do this
properly until I got back.
Will, can you confirm that this version is okay and
). This is silly; we should just
return -ENOSYS.
This is unlikely to ever happen on x86 because the return value in
pt_regs starts out as -ENOSYS, but a silly tracer can change that.
Signed-off-by: Andy Lutomirski l...@amacapital.net
Cc: Will Drewry w...@chromium.org
---
arch/x86/include/asm
On Sat, Jul 14, 2012 at 11:21 AM, Andrew Lutomirski wrote:
> On Sat, Jul 14, 2012 at 9:15 AM, Andrew Lutomirski wrote:
>> On Sat, Jul 14, 2012 at 8:57 AM, Will Drewry wrote:
>>> On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry wrote:
>>>> On Sat, Jul 14, 2012 at 10:4
On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry wrote:
> On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski wrote:
>> I think I'd prefer if changing to something other than whatever value is
>> used to cancel the syscall resulted in a crash rather than just being
>> igno
k given vsyscall's status and the fact that
ptrace+seccomp+vsyscall=emulate isn't horrible, I think it's fine to
either ignore (what is in tree now) or to allow ptrace to skip,
without providing full functionality. But obviously, my view my be
biased!
thanks!
will
>
> On Jul 14, 2012 10:35
Current quirky ptrace behavior with vsyscall and seccomp
does not allow tracers to bypass the call. This change
provides that ability by checking if orig_ax changed.
Signed-off-by: Will Drewry
---
arch/x86/kernel/vsyscall_64.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions
-by: Will Drewry
---
Documentation/prctl/seccomp_filter.txt | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/prctl/seccomp_filter.txt
b/Documentation/prctl/seccomp_filter.txt
index 597c3c5..67ed88b 100644
--- a/Documentation/prctl/seccomp_filter.txt
+++ b
vsyscall_seccomp introduced a dependency on __secure_computing. On
configurations with CONFIG_SECCOMP disabled, compilation will fail.
Reported-by: feng xiangjun
Signed-off-by: Will Drewry
---
arch/x86/kernel/vsyscall_64.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/x86
vsyscall_seccomp introduced a dependency on __secure_computing. On
configurations with CONFIG_SECCOMP disabled, compilation will fail.
Reported-by: feng xiangjun fengxj...@gmail.com
Signed-off-by: Will Drewry w...@chromium.org
---
arch/x86/kernel/vsyscall_64.c |4
1 file changed, 4
-by: Will Drewry w...@chromium.org
---
Documentation/prctl/seccomp_filter.txt | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/prctl/seccomp_filter.txt
b/Documentation/prctl/seccomp_filter.txt
index 597c3c5..67ed88b 100644
--- a/Documentation/prctl
Current quirky ptrace behavior with vsyscall and seccomp
does not allow tracers to bypass the call. This change
provides that ability by checking if orig_ax changed.
Signed-off-by: Will Drewry w...@chromium.org
---
arch/x86/kernel/vsyscall_64.c | 10 +++---
1 file changed, 7 insertions
status and the fact that
ptrace+seccomp+vsyscall=emulate isn't horrible, I think it's fine to
either ignore (what is in tree now) or to allow ptrace to skip,
without providing full functionality. But obviously, my view my be
biased!
thanks!
will
On Jul 14, 2012 10:35 AM, Will Drewry w
On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry w...@chromium.org wrote:
On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski l...@mit.edu wrote:
I think I'd prefer if changing to something other than whatever value is
used to cancel the syscall resulted in a crash rather than just being
ignored
On Sat, Jul 14, 2012 at 11:21 AM, Andrew Lutomirski l...@mit.edu wrote:
On Sat, Jul 14, 2012 at 9:15 AM, Andrew Lutomirski l...@mit.edu wrote:
On Sat, Jul 14, 2012 at 8:57 AM, Will Drewry w...@chromium.org wrote:
On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry w...@chromium.org wrote:
On Sat
is in effect.
If v2 of the first patch is preferred, then this patch will need to
be changed to indicate that SECCOMP_RET_TRACE does not allow
system calls to be remapped _or_ skipped.
Signed-off-by: Will Drewry
---
Documentation/prctl/seccomp_filter.txt | 22 ++
1 file changed
ported-by: Owen Kibel
Signed-off-by: Will Drewry
v3: - allow ptrace orig_ax changes to skip the syscall since changing it is not
an option. (result of discussions with luto)
- ensure ptrace register modification doesn't change return behavior taking
the "normal" retur
On Fri, Jul 13, 2012 at 7:48 PM, Will Drewry wrote:
> On Fri, Jul 13, 2012 at 6:00 PM, Andrew Lutomirski wrote:
>> On Fri, Jul 13, 2012 at 10:06 AM, Will Drewry wrote:
>>> If a seccomp filter program is installed, older static binaries and
>>> distributions with
On Fri, Jul 13, 2012 at 6:00 PM, Andrew Lutomirski wrote:
> On Fri, Jul 13, 2012 at 10:06 AM, Will Drewry wrote:
>> If a seccomp filter program is installed, older static binaries and
>> distributions with older libc implementations (glibc 2.13 and earlier)
>> that
onally, system call return behavior is emulated in line
with other vsyscall entrypoints for the trace/trap cases.
Reported-by: Owen Kibel
Signed-off-by: Will Drewry
v2: - fixed ip and sp on SECCOMP_RET_TRAP/TRACE (thanks to l...@mit.edu)
---
arch/x86/kernel/vsyscall_64.c
On Fri, Jul 13, 2012 at 9:32 AM, Andrew Lutomirski wrote:
> On Thu, Jul 12, 2012 at 10:17 PM, Will Drewry wrote:
>> If a seccomp filter program is installed, older static binaries and
>> distributions with older libc implementations (glibc 2.13 and earlier)
>> that
On Fri, Jul 13, 2012 at 9:32 AM, Andrew Lutomirski l...@mit.edu wrote:
On Thu, Jul 12, 2012 at 10:17 PM, Will Drewry w...@chromium.org wrote:
If a seccomp filter program is installed, older static binaries and
distributions with older libc implementations (glibc 2.13 and earlier)
that rely
, system call return behavior is emulated in line
with other vsyscall entrypoints for the trace/trap cases.
Reported-by: Owen Kibel qme...@gmail.com
Signed-off-by: Will Drewry w...@chromium.org
v2: - fixed ip and sp on SECCOMP_RET_TRAP/TRACE (thanks to l...@mit.edu)
---
arch/x86/kernel/vsyscall_64.c
On Fri, Jul 13, 2012 at 6:00 PM, Andrew Lutomirski l...@mit.edu wrote:
On Fri, Jul 13, 2012 at 10:06 AM, Will Drewry w...@chromium.org wrote:
If a seccomp filter program is installed, older static binaries and
distributions with older libc implementations (glibc 2.13 and earlier)
that rely
On Fri, Jul 13, 2012 at 7:48 PM, Will Drewry w...@chromium.org wrote:
On Fri, Jul 13, 2012 at 6:00 PM, Andrew Lutomirski l...@mit.edu wrote:
On Fri, Jul 13, 2012 at 10:06 AM, Will Drewry w...@chromium.org wrote:
If a seccomp filter program is installed, older static binaries and
distributions
-by: Owen Kibel qme...@gmail.com
Signed-off-by: Will Drewry w...@chromium.org
v3: - allow ptrace orig_ax changes to skip the syscall since changing it is not
an option. (result of discussions with luto)
- ensure ptrace register modification doesn't change return behavior taking
is in effect.
If v2 of the first patch is preferred, then this patch will need to
be changed to indicate that SECCOMP_RET_TRACE does not allow
system calls to be remapped _or_ skipped.
Signed-off-by: Will Drewry w...@chromium.org
---
Documentation/prctl/seccomp_filter.txt | 22
vsyscall emulation is in use (vsyscall=emulate is the
default).
This patch emulates system call entry inside a vsyscall=emulate trap
such that seccomp can properly evaluate the system call.
Reported-by: Owen Kibel
Signed-off-by: Will Drewry
---
arch/x86/kernel/vsyscall_64.c | 29
vsyscall emulation is in use (vsyscall=emulate is the
default).
This patch emulates system call entry inside a vsyscall=emulate trap
such that seccomp can properly evaluate the system call.
Reported-by: Owen Kibel qme...@gmail.com
Signed-off-by: Will Drewry w...@chromium.org
---
arch/x86/kernel
87 matches
Mail list logo
