On Fri, Sep 23, 2016 at 08:34:43PM +0200, Jann Horn wrote:
> On Fri, Sep 23, 2016 at 11:28:26AM -0700, Kees Cook wrote:
> > Does CRIU use this? I wouldn't expect so, since they're using ptrace,
> > IIUC, to freeze/restore.
>
> As far as I can tell:
>
> parse_pid_stat() parses them into a struct p
Hi Dave,
On Mon, Nov 13, 2017 at 02:46:25PM -0800, Dave Hansen wrote:
> On 11/13/2017 02:20 PM, Dave Hansen wrote:
> > On 11/09/2017 05:09 PM, Tycho Andersen wrote:
> >> which I guess is from the additional flags in grow_dev_page() somewhere
> >> down
> >> the
On Tue, Nov 14, 2017 at 04:37:34PM -0800, Dave Hansen wrote:
> On 11/14/2017 04:33 PM, Tycho Andersen wrote:
> >>
> >> void set_bh_page(struct buffer_head *bh,
> >> ...
> >>bh->b_data = page_address(page) + offset;
> > Ah, yes. I guess there will
ilter
primitives
v4: * resend
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
---
kernel/seccomp.c | 77 +---
1 file changed, 45 insertions(+), 32 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/secc
flags).
Hopefully this will be future proof, and new per-filter metadata can be
added to this struct.
v3: * use GET_METADATA instead of GET_FLAGS
v4: * resend
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
---
include/linux/seccomp.h | 8
include/uapi/
Hi all,
Here's v6 of the seccomp filter c/r stuff. I've dropped the concept of a
seccomp fd entirely, in favor of just dumping the bpf data. This doesn't allow
us to restore correctly in all cases, though, as noted in the patch notes.
Note that this is now based on http://patchwork.ozlabs.org/pat
otentially confuse users of this interface.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Borkmann
---
include/linux/seccomp.h | 11 +
include/uapi/linu
Hi Daniel,
On Wed, Oct 07, 2015 at 12:25:39PM +0200, Daniel Borkmann wrote:
> On 10/07/2015 11:46 AM, Tycho Andersen wrote:
> >+
> >+#if defined(CONFIG_SECCOMP_FILTER) && defined(CONFIG_CHECKPOINT_RESTORE)
> >+extern long seccomp_get_filter(str
On Wed, Oct 07, 2015 at 12:34:26PM +0200, Daniel Borkmann wrote:
> On 10/07/2015 12:25 PM, Daniel Borkmann wrote:
> >On 10/07/2015 11:46 AM, Tycho Andersen wrote:
> >>This patch adds support for dumping a process' (classic BPF) seccomp
> >>filters via ptrace.
&g
Hi all,
Here's v7 of the seccomp filter c/r stuff. The biggest change is counting down
the seccomp tree instead of up for the index, although there are some other
small changes in the notes as well.
Note that this is now based on http://patchwork.ozlabs.org/patch/525492/ and
will need to be built
make it an unsigned long to match ptrace
* count "down" the tree instead of "up" when passing a filter offset
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei St
On Sat, Sep 05, 2015 at 09:13:02AM +0200, Michael Kerrisk (man-pages) wrote:
> On 09/04/2015 10:41 PM, Kees Cook wrote:
> > On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> > wrote:
> >> This is the final bit needed to support seccomp filters created via the bpf
> &
On Tue, Sep 08, 2015 at 05:07:03PM -0700, Kees Cook wrote:
>
> Yeah, bpf's union looks good. Let's add a "command" flag, though:
>
> seccomp(SECCOMP_MODE_FILTER_EBPF, int cmd, union, size);
>
> And this cmd could be ADD_FD or something?
>
> How's that look?
I think we can drop the size (using t
On Fri, Sep 04, 2015 at 02:08:37PM -0700, Kees Cook wrote:
> On Fri, Sep 4, 2015 at 2:06 PM, Tycho Andersen
> wrote:
> > On Fri, Sep 04, 2015 at 01:34:12PM -0700, Kees Cook wrote:
> >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> >> wrote:
> >>
On Wed, Sep 09, 2015 at 08:14:04AM -0700, Alexei Starovoitov wrote:
> On Wed, Sep 09, 2015 at 08:47:24AM -0600, Tycho Andersen wrote:
> > On Tue, Sep 08, 2015 at 05:07:03PM -0700, Kees Cook wrote:
> > >
> > > Yeah, bpf's union looks good. Let's add a "c
t;> > On 09/09/2015 06:07 PM, Alexei Starovoitov wrote:
> >> >>
> >> >> On Wed, Sep 09, 2015 at 09:50:35AM -0600, Tycho Andersen wrote:
> >> >
> >> > [...]
> >> >>>
> >> >>> Thoughts?
> >> >>
&
On Tue, Oct 20, 2015 at 01:26:01PM -0700, Kees Cook wrote:
> On Tue, Oct 20, 2015 at 1:20 PM, Oleg Nesterov wrote:
> >
> > Oh wait, I didn't notice this when I looked at v7.
> >
> > No, you can't do copy_to_user() from atomic context. You need to pin this
> > filter, drop the lock/irq, then copy_t
.
Tycho
>From 5be84ece99312304df2a61f727355ffd3fc604da Mon Sep 17 00:00:00 2001
From: Tycho Andersen
Date: Fri, 2 Oct 2015 18:49:43 -0600
Subject: [PATCH v9] seccomp, ptrace: add support for dumping seccomp filters
This patch adds support for dumping a process' (classic BPF) seccomp
filters via ptrace.
PTRACE_SECCOMP
Hi Oleg,
On Wed, Oct 21, 2015 at 08:51:46PM +0200, Oleg Nesterov wrote:
> On 10/20, Tycho Andersen wrote:
> >
> > Hi Kees, Oleg,
> >
> > On Tue, Oct 20, 2015 at 10:20:24PM +0200, Oleg Nesterov wrote:
> > >
> > > No, you can't do copy_t
quot;unlikely"?
>
> Btw, the conditions inside the WARN_ON() macro would already resolve
> to unlikely().
Here's an updated patch with the !filter as well.
Thanks,
Tycho
>From f37256a6f5e9e975943024ec0a26796a48521492 Mon Sep 17 00:00:00 2001
From: Tycho Andersen
Date:
Hi Oleg,
On Wed, Oct 21, 2015 at 11:07:56PM +0200, Oleg Nesterov wrote:
> On 10/21, Tycho Andersen wrote:
> >
> > Hi Oleg,
> >
> > On Wed, Oct 21, 2015 at 08:51:46PM +0200, Oleg Nesterov wrote:
> > > > +
> > > > + if (WARN_ON(count
Hi all,
On Thu, Sep 03, 2015 at 08:17:05PM -0700, Alexei Starovoitov wrote:
> On Fri, Sep 04, 2015 at 01:01:20AM +, Michael Tirado wrote:
> > Hiyall,
> >
> > I have created a seccomp white list filter for a program that launches
> > other less trustworthy programs. It's working great so far,
t when two seccomp filters were inherited from each
other and clone the filter tree accordingly.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Borkmann
---
include/
Hi all,
Here is a set that enables checkpoint restore of the underlying eBPF programs
that power seccomp filters via the API we discussed several months ago. A few
notes:
* We expose prog_id in the ebpf dump as the pointer to the ebpf program in
kernel memory, since this is unique. I'm not sure
}
but here, we enforce that the src_reg == BPF_REG_0. We should also allow
BPF_REG_X since that's what the converter generates; this enables us to
load eBPF programs that were generated by the converter.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: And
ocess.
Additionally, we mark classic converted seccomp filters as seccomp eBPF
programs, since they are a subset of what is supported in seccomp eBPF.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: A
some interesting features (notably, maps) of eBPF. However,
the primary motivation for this patchset is to enable checkpoint/restore
for seccomp filters later in the series, to this limited feature set is ok
for now.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nestero
f(BPF_PROG_DUMP) to dump the actual program at each step.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Borkmann
---
include/linux/bpf.h | 12 ++
te to it which
seems impolite. Right now we cast the pointer (and force the user to cast
it), which generates ugly warnings. I'm not sure what the right answer is
here.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
C
Hi Alexei,
On Fri, Sep 04, 2015 at 01:27:05PM -0700, Alexei Starovoitov wrote:
> On Fri, Sep 04, 2015 at 10:04:21AM -0600, Tycho Andersen wrote:
> > This commit adds a way to dump eBPF programs. The initial implementation
> > doesn't support maps, and therefore only allows
On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote:
> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> wrote:
> > This commit adds a way to dump eBPF programs. The initial implementation
> > doesn't support maps, and therefore only allows dumping seccomp ebpf
> &
On Fri, Sep 04, 2015 at 01:29:49PM -0700, Alexei Starovoitov wrote:
> On Fri, Sep 04, 2015 at 01:26:42PM -0700, Kees Cook wrote:
> > On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> > wrote:
> > > This patch adds a way for a process that is "real root" to a
On Fri, Sep 04, 2015 at 01:58:25PM -0700, Alexei Starovoitov wrote:
> On Fri, Sep 04, 2015 at 01:50:55PM -0700, Kees Cook wrote:
> > On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen
> > wrote:
> > > On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote:
> > >
On Fri, Sep 04, 2015 at 01:34:12PM -0700, Kees Cook wrote:
> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> wrote:
> > +static const struct bpf_func_proto *
> > +seccomp_func_proto(enum bpf_func_id func_id)
> > +{
> > + /* Right now seccomp eBPF loading
On Fri, Sep 04, 2015 at 01:17:47PM -0700, Alexei Starovoitov wrote:
> On Fri, Sep 04, 2015 at 10:04:19AM -0600, Tycho Andersen wrote:
> > seccomp uses eBPF as its underlying storage and execution format, and eBPF
> > has features that seccomp would like to make use of in the future.
On Fri, Sep 04, 2015 at 02:48:03PM -0700, Andy Lutomirski wrote:
> On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen
> wrote:
> > On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote:
> >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> >> wrote:
> >>
Hi Alexei,
On Fri, Sep 04, 2015 at 02:06:19PM -0700, Alexei Starovoitov wrote:
> On Fri, Sep 04, 2015 at 10:04:24AM -0600, Tycho Andersen wrote:
> > The classic converter generates conditional jumps with:
> >
> > if (BPF_SRC(fp->code) == BPF_K && (int) fp->
On Fri, Sep 04, 2015 at 04:08:53PM -0700, Andy Lutomirski wrote:
> On Fri, Sep 4, 2015 at 3:28 PM, Tycho Andersen
> wrote:
> > On Fri, Sep 04, 2015 at 02:48:03PM -0700, Andy Lutomirski wrote:
> >> On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen
> >> wrote:
> &
Hi Oleg,
On Tue, Oct 20, 2015 at 08:00:24PM +0200, Oleg Nesterov wrote:
> Sorry for delay...
No problem, thanks for the review.
> On 10/13, Tycho Andersen wrote:
> >
> > --- a/include/uapi/linux/ptrace.h
> > +++ b/include/uapi/linux/ptrace.h
> > @@ -23,6 +23,8 @@
&
Hi all,
Here's v8 of the seccomp filter c/r stuff, which has some minor changes
dropping a lock and changing a constant.
Note that this is now based on http://patchwork.ozlabs.org/patch/525492/ and
will need to be built with that patch applied. This gets rid of two incorrect
patches in a previous
make it an unsigned long to match ptrace
* count "down" the tree instead of "up" when passing a filter offset
v3: * don't take the current task's lock for inspecting its seccomp mode
* use a 0x42** constant for the ptrace command value
Signed-off-by: Tycho Ande
s on changes in net, could this get pulled
> in from that direction?
>
> Acked-by: Kees Cook
Can we get the attached patch into net-next?
Thanks,
Tycho
>From 5d9be66e4f48e0882a5546376380147f2f711bec Mon Sep 17 00:00:00 2001
From: Tycho Andersen
Date: Fri, 2 Oct 2015 18:49:43 -0600
Hi all,
Here is a patch that we'd like to go via net-next, as it depends on previous
changes in that tree.
Thanks,
Tycho
--
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.or
userspace while holding spinlocks
v5: * add another condition to WARN_ON
v6: * rebase on net-next
Signed-off-by: Tycho Andersen
Acked-by: Kees Cook
CC: Will Drewry
Reviewed-by: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Bo
On Wed, Sep 30, 2015 at 02:48:47PM -0700, Andy Lutomirski wrote:
> On Wed, Sep 30, 2015 at 2:39 PM, Tycho Andersen
> wrote:
> > On Wed, Sep 30, 2015 at 11:56:25AM -0700, Andy Lutomirski wrote:
> >> On Wed, Sep 30, 2015 at 11:55 AM, Tycho Andersen
> >> wrote:
> &
Hi all,
Here's v5 of the seccomp filter c/r set. The individual patch notes have
changes, but two highlights are:
* This series is now based on http://patchwork.ozlabs.org/patch/525492/ and
will need to be built with that patch applied. This gets rid of two incorrect
patches in the previous s
erhaps insecure.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Borkmann
---
include/linux/seccomp.h | 5 ++
include/uapi/linux/seccomp.h | 27 ++
k
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Borkmann
---
include/uapi/linux/kcmp.h | 1 +
kernel/kcmp.c | 27 +++
2 files
TER implies that there is at least one
filter. If there is a more appropriate errno (ESRCH collides as well with
ptrace) to give here that may be better.
v2: use new bpf interface save_orig to save the original filter when
necessary
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewr
On Fri, Oct 02, 2015 at 02:10:24PM -0700, Kees Cook wrote:
> On Fri, Oct 2, 2015 at 9:27 AM, Tycho Andersen
> wrote:
> > Hi all,
> >
> > Here's v5 of the seccomp filter c/r set. The individual patch notes have
> > changes, but two highlights are:
> &g
On Fri, Oct 02, 2015 at 03:52:03PM -0700, Andy Lutomirski wrote:
> On Fri, Oct 2, 2015 at 3:44 PM, Tycho Andersen
> wrote:
> > On Fri, Oct 02, 2015 at 02:10:24PM -0700, Kees Cook wrote:
> >> On Fri, Oct 2, 2015 at 9:27 AM, Tycho Andersen
> >> wrote:
> >> &
On Sat, Oct 03, 2015 at 12:57:49AM +0200, Daniel Borkmann wrote:
> On 10/03/2015 12:44 AM, Tycho Andersen wrote:
> >On Fri, Oct 02, 2015 at 02:10:24PM -0700, Kees Cook wrote:
> ...
> >Ok, how about,
> >
> >struct sock_filter insns[BPF_MAXINSNS];
> >insn_cnt = p
Hi all,
Dinesh Subhraveti has claimed that some part of this series might be
patented. While he has not furnished me with anything to confirm this
claim, I'll put this series on hold.
Tycho
On Thu, Jun 21, 2018 at 04:04:12PM -0600, Tycho Andersen wrote:
> Hi all,
>
> Here'
Hi Eric,
On Thu, Jun 14, 2018 at 04:53:51PM -0500, Eric W. Biederman wrote:
> >> static void seccomp_do_user_notification(...)
> >> {
> >> ...
> >> n.pid = get_task_pid(current, PIDTYPE_PID);
> >> ...
> >> remove_list:
> >> list_del(&n.list);
> >> put_pid(n.pid);
> >> ...
>
On Thu, Jun 14, 2018 at 02:55:03PM -0700, Matthew Helsley wrote:
> > + /*
> > +* Notification states. When SECCOMP_RET_USER_NOTIF is returned, a
> > +* struct seccomp_knotif is created and starts out in INIT. Once
> > the
> > +* handler reads the notification off of an
icates the code less, so hopefully it's ok.
v2: new in v2
v3: no changes
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Eric W. Biederman
CC: "Serge E. Hallyn"
CC: Christian Brauner
CC: Tyler Hicks
CC: Akihiro Suda
---
kernel/sec
e of anything that needs to be addressed, but of course that is
subject to change :)
Tycho
Tycho Andersen (4):
seccomp: add a return code to trap to userspace
seccomp: make get_nth_filter available outside of CHECKPOINT_RESTORE
seccomp: add a way to get a listener fd from ptrace
seccomp: a
twice (Matthew)
* fix comment typo from older version (SEND vs READ) (Matthew)
* whitespace and logic simplification (Tobin)
* add some Documentation/ bits on userspace trapping
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Eric W. Biederman
CC:
unting bug (Oleg)
v4: * change the listener's fd flags to be 0
* rename GET_LISTENER to NEW_LISTENER (Matthew)
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Eric W. Biederman
CC: "Serge E. Hallyn"
CC: Christian Brauner
CC: Tyle
* reflect GET_LISTENER -> NEW_LISTENER changes
* add to the new Documentation/ on user notifications about fd replies
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Eric W. Biederman
CC: "Serge E. Hallyn"
CC: Christian Brauner
CC: Tyler Hicks
CC
Hi Jann,
On Fri, Jun 22, 2018 at 12:48:09AM +0200, Jann Horn wrote:
> On Fri, Jun 22, 2018 at 12:04 AM Tycho Andersen wrote:
> > As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
> > version which can acquire filters is useful. There are at least two reas
On Fri, Jun 22, 2018 at 01:34:18AM +0200, Jann Horn wrote:
> On Fri, Jun 22, 2018 at 12:05 AM Tycho Andersen wrote:
> >
> > The idea here is that the userspace handler should be able to pass an fd
> > back to the trapped task, for example so it can be
On Fri, Jun 22, 2018 at 01:21:47AM +0200, Jann Horn wrote:
> On Fri, Jun 22, 2018 at 12:05 AM Tycho Andersen wrote:
> >
> > This patch introduces a means for syscalls matched in seccomp to notify
> > some other task that a particular filter has been triggered.
> [...]
>
On Fri, Jun 22, 2018 at 03:28:24AM +0200, Jann Horn wrote:
> On Fri, Jun 22, 2018 at 2:58 AM Tycho Andersen wrote:
> >
> > On Fri, Jun 22, 2018 at 01:21:47AM +0200, Jann Horn wrote:
> > > On Fri, Jun 22, 2018 at 12:05 AM Tycho Andersen wrote:
> > > [..
Hi Jann,
On Fri, Jun 22, 2018 at 04:40:20PM +0200, Jann Horn wrote:
> On Fri, Jun 22, 2018 at 12:05 AM Tycho Andersen wrote:
> > This patch introduces a means for syscalls matched in seccomp to notify
> > some other task that a particular filter has been triggered.
> >
&
aller fixes. See individual patch notes for
details.
Thanks,
Tycho
Tycho Andersen (5):
seccomp: add a return code to trap to userspace
seccomp: make get_nth_filter available outside of CHECKPOINT_RESTORE
seccomp: add a way to get a listener fd from ptrace
seccomp: add support for passin
.
v5: new in v5
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Eric W. Biederman
CC: "Serge E. Hallyn"
CC: Christian Brauner
CC: Tyler Hicks
CC: Akihiro Suda
---
samples/seccomp/.gitignore | 1 +
samples/seccomp/Makefile| 9 +-
sampl
* reflect GET_LISTENER -> NEW_LISTENER changes
* add to the new Documentation/ on user notifications about fd replies
v5: * fix documentation typo (O_EXCL -> O_CLOEXEC)
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Eric W. Biederman
CC: "Serge E
unting bug (Oleg)
v4: * change the listener's fd flags to be 0
* rename GET_LISTENER to NEW_LISTENER (Matthew)
v5: * add capable(CAP_SYS_ADMIN) requirement
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Eric W. Biederman
CC: "Serge E. Ha
rning when
only CONFIG_SECCOMP_FILTER is enabled.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Eric W. Biederman
CC: "Serge E. Hallyn"
CC: Christian Brauner
CC: Tyler Hicks
CC: Akihiro Suda
---
kernel/seccomp.c | 7 +--
1 file change
ng ioctls instead of read()/write() for struct passing
(Jann)
* add an ioctl to ensure an id is still valid
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Andy Lutomirski
CC: Oleg Nesterov
CC: Eric W. Biederman
CC: "Serge E. Hallyn"
CC: Christian Brauner
CC: Tyler Hicks
On Wed, Aug 29, 2018 at 08:59:18PM +0200, Christian Brauner wrote:
> On Tue, Aug 28, 2018 at 08:35:59AM -0600, Tycho Andersen wrote:
> > +Users can ``read()`` or ``poll()`` on a seccomp notification fd to receive
> > a
>
> You have changed this from read() to ioctl(), right
On Tue, Aug 07, 2018 at 09:11:50PM -0700, Dinesh Subhraveti wrote:
> On Mon, Aug 6, 2018 at 7:44 PM, Tycho Andersen wrote:
> > Hi all,
> >
> > Dinesh Subhraveti has claimed that some part of this series might be
> > patented. While he has not furnished me with anythin
ough the macros/ref/unref calls to not warn about uninitialized
flags. We don't need to do a ref here since we hold the per-port
mutex anyway.
Signed-off-by: Tycho Andersen
---
drivers/tty/serial/serial_core.c | 19 ++-
1 file changed, 14 insertions(+), 5 de
On Wed, Jul 11, 2018 at 02:49:08PM -0500, Serge E. Hallyn wrote:
> Quoting Tycho Andersen (ty...@tycho.ws):
> > We have reports of the following crash:
> >
> > PID: 7 TASK: 88085c6d61c0 CPU: 1 COMMAND: "kworker/u25:0"
> > #0 [88085c6db7
Hi Andy,
On Thu, Jul 12, 2018 at 12:03:08PM +0300, Andy Shevchenko wrote:
> On Wed, Jul 11, 2018 at 7:07 PM, Tycho Andersen wrote:
>
> > Anyway, since the lock is not acquired, if uart_shutdown() is called, the
> > last chunk of that function may release state->xmit.bu
On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote:
> > + if (uport)
> > + spin_lock_irqsave(&uport->lock, flags);
>
> That's the same thing as just calling uart_port_lo
On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote:
> > On Thu, Jul 12, 2018 at 05:04:38PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Jul 11, 2018 at 10:07:44AM -0600, Tycho Andersen wrote:
On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote:
> > On Thu, Jul 12, 2018 at 05:40:15PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Jul 12, 2018 at 09:08:22AM -0600, Tycho Andersen wrote:
>
On Fri, Jul 13, 2018 at 11:28:28AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 12, 2018 at 12:30:01PM -0600, Tycho Andersen wrote:
> > On Thu, Jul 12, 2018 at 08:25:45PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Jul 12, 2018 at 12:18:46PM -0600, Tycho Andersen wrote:
>
While reading this header, I noticed that the locking stuff has moved to
kernel/locking/*, so update the path in semaphore.h to point to that.
Signed-off-by: Tycho Andersen
---
include/linux/semaphore.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux
sted using the program from the add_key man page to trigger
big_key.
[1]: https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Tycho Andersen
CC: David Howells
CC: James Morris
CC: "Serge E. Hallyn"
CC: Jason A. Donenfeld
---
security/keys/big_key.c | 12 +---
1 file changed
memzero_explicit, but it seems like maybe they both
should?).
Signed-off-by: Tycho Andersen
CC: David Howells
CC: James Morris
CC: "Serge E. Hallyn"
---
security/keys/dh.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/security/keys/dh.c b/sec
On Tue, Mar 06, 2018 at 10:33:17PM +, Andy Lutomirski wrote:
> >> Suppose I'm writing a container manager. I want to run "mount" in the
> >> container, but I don't want to allow moun() in general and I want to
> >> emulate certain mount() actions. I can write a filter that catches
> >> mount
Hi Eric,
On Wed, Mar 14, 2018 at 07:21:12PM -0700, Eric Biggers wrote:
> On Mon, Mar 12, 2018 at 10:29:07PM -0600, Tycho Andersen wrote:
> > Similarly to the previous patch, we would like to get rid of stack
> > allocated arrays: https://lkml.org/lkml/2018/3/7/621
> >
>
Hi Eric,
On Wed, Mar 14, 2018 at 06:51:39PM -0700, Eric Biggers wrote:
> On Mon, Mar 12, 2018 at 10:29:06PM -0600, Tycho Andersen wrote:
> > We're interested in getting rid of all of the stack allocated arrays in the
> > kernel [1]. This patch removes one in keys by swit
Hi Kees,
On Wed, Mar 07, 2018 at 03:07:14PM -0800, Kees Cook wrote:
> The "sym" calculation is actually a fixed size, but since the max()
> macro uses some extensive tricks for safety, it ends up looking like a
> variable size. This replaces max() with a simple max macro which is
> sufficient for
In keeping with the directive to get rid of VLAs [1], let's drop the VLA
from ima_audit_measurement(). We need to adjust the return type of
ima_audit_measurement, because now this function can fail if an allocation
fails.
[1]: https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Tycho And
Whoops, seems the IMA list has moved since I last sent a patch. I'll
resend shortly.
In keeping with the directive to get rid of VLAs [1], let's drop the VLA
from ima_audit_measurement(). We need to adjust the return type of
ima_audit_measurement, because now this function can fail if an allocation
fails.
[1]: https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Tycho And
On Thu, Mar 08, 2018 at 07:47:37PM +0200, Andy Shevchenko wrote:
> On Thu, Mar 8, 2018 at 7:14 PM, Tycho Andersen wrote:
> > In keeping with the directive to get rid of VLAs [1], let's drop the VLA
> > from ima_audit_measurement(). We need to adjust the return type of
>
On Thu, Mar 08, 2018 at 01:50:30PM -0500, Mimi Zohar wrote:
> On Thu, 2018-03-08 at 11:37 -0700, Tycho Andersen wrote:
> > On Thu, Mar 08, 2018 at 07:47:37PM +0200, Andy Shevchenko wrote:
> > > On Thu, Mar 8, 2018 at 7:14 PM, Tycho Andersen wrote:
> > > > In keeping
On Thu, Mar 08, 2018 at 02:20:17PM -0500, Mimi Zohar wrote:
> On Thu, 2018-03-08 at 12:04 -0700, Tycho Andersen wrote:
> > On Thu, Mar 08, 2018 at 01:50:30PM -0500, Mimi Zohar wrote:
> > > On Thu, 2018-03-08 at 11:37 -0700, Tycho Andersen wrote:
> > > > On Thu, Ma
ormat instead of doing a second allocation
Signed-off-by: Tycho Andersen
---
security/integrity/ima/ima.h | 4 ++--
security/integrity/ima/ima_api.c | 22 +-
security/integrity/ima/ima_main.c | 7 +--
3 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/sec
Hi Mimi,
On Thu, Mar 08, 2018 at 03:36:14PM -0500, Mimi Zohar wrote:
> On Thu, 2018-03-08 at 13:23 -0700, Tycho Andersen wrote:
>
> > /*
> > diff --git a/security/integrity/ima/ima_main.c
> > b/security/integrity/ima/ima_main.c
> > index 2cfb0c714967..356faae6
Hi Mimi,
On Thu, Mar 08, 2018 at 05:05:40PM -0500, Mimi Zohar wrote:
> On Thu, 2018-03-08 at 14:45 -0700, Tycho Andersen wrote:
> > Hi Mimi,
> >
> > On Thu, Mar 08, 2018 at 03:36:14PM -0500, Mimi Zohar wrote:
> > > On Thu, 2018-03-08 at 13:
ormat instead of doing a second allocation
v3: ignore failures in ima_audit_measurement()
Signed-off-by: Tycho Andersen
---
security/integrity/ima/ima_api.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/security/integrit
me to emit status (i.e. trade memory for time). Since the number
of stripes is probably low, this is hopefully not that expensive.
Signed-off-by: Tycho Andersen
CC: Alasdair Kergon
CC: Mike Snitzer
---
drivers/md/dm-stripe.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
di
On Thu, Mar 08, 2018 at 10:01:07PM -0800, Joe Perches wrote:
> On Fri, 2018-03-09 at 16:50 +1100, Tobin C. Harding wrote:
> > The kernel would like to have all stack VLA usage removed[1]. The
> > arrays are fixed here (declared with a const variable) but they appear
> > like VLAs to the compiler.
Hi all,
I'm getting the WARN below. I think (?) what I'm doing when I get it
is that I'm unmounting a subvolume while it's being synced (concurrent
uses of the subvolume, at least, happy to look into it further if the
stack trace is not so useful). Anyway, I can fairly reliably reproduce
this on 4
1 - 100 of 573 matches
Mail list logo
