[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
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
>
> 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 06/11/201
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
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 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 = current;
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
(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
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-
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
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
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
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
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
>> 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
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:
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
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
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
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 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
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 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
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-
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 tests?
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
>> ig
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
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
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
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
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
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"
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 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 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
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
44 matches
Mail list logo
