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
>> 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
Signed-off-by: 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 (a
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 th
ices.
>
> 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
r_t block,
> (unsigned long long)hash_block);
> v->hash_failed = 1;
> r = -EIO;
> + verity_hash_error(v, (unsigned long long)hash_block);
> goto release_re
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:
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.
>&
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 signature
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
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
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
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 rely on
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 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 rely on
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
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"
tion 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 fi
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
ned-off-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
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
bh. I think 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
>
&g
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
>> ig
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 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 tests?
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
gt;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-
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
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 sysca
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 dep
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 wha
pointer updates, writes to
the pointer are now protected by the task_lock. Read access remains
lockless because pointer updates themselves are atomic. However,
writes often entail additional checking (like maximum instruction
counts) which require locking to perform safely.
Signed-off-by: Will
o. NULL 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-
(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
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 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 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 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 = current;
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 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 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 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 06/11/201
[3]:
> https://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
>
> 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
> >
44 matches
Mail list logo