Re: [PATCH v4 0/4] seccomp trap to userspace
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 anything to confirm this > > claim, I'll put this series on hold. > > For the sake of everyone's clarity, there is no patent or intellectual > property issue here and we'd like to see this feature in the kernel. I did > indicate that there is a patent related to the mechanism underlying this > patch set but that is completely incidental to the issue here. We have > filed that patent only for the purpose of defense and have no interest or > resources to go after infringements. As such, I spoke about the approach, > it's value for networking and a few possible ways of implementing it in the > kernel at Linux Plumbers Conference 2017. > > As a contractor and a member of our team at AppSwitch (FKA Fermat), Tycho > Andersen helped implement a fully user space version of system call trap > mechanism based on seccomp / fd-passing and participated in our team > discussions about upstreaming a kernel version of the feature. Given that > context, we were taken aback that he posted the v1 patch set without > letting us know and without any mention of AppSwitch in the post even > though he was still under contract at that time. It seems we disagree on the series of events, but agree that this patchset should move forward. I'll work on preparing a v5. Thanks! Tycho
Re: [PATCH v4 0/4] seccomp trap to userspace
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 anything to confirm this > > claim, I'll put this series on hold. > > For the sake of everyone's clarity, there is no patent or intellectual > property issue here and we'd like to see this feature in the kernel. I did > indicate that there is a patent related to the mechanism underlying this > patch set but that is completely incidental to the issue here. We have > filed that patent only for the purpose of defense and have no interest or > resources to go after infringements. As such, I spoke about the approach, > it's value for networking and a few possible ways of implementing it in the > kernel at Linux Plumbers Conference 2017. > > As a contractor and a member of our team at AppSwitch (FKA Fermat), Tycho > Andersen helped implement a fully user space version of system call trap > mechanism based on seccomp / fd-passing and participated in our team > discussions about upstreaming a kernel version of the feature. Given that > context, we were taken aback that he posted the v1 patch set without > letting us know and without any mention of AppSwitch in the post even > though he was still under contract at that time. It seems we disagree on the series of events, but agree that this patchset should move forward. I'll work on preparing a v5. Thanks! Tycho
Re: [PATCH v4 0/4] seccomp trap to userspace
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 anything to confirm this > claim, I'll put this series on hold. For the sake of everyone's clarity, there is no patent or intellectual property issue here and we'd like to see this feature in the kernel. I did indicate that there is a patent related to the mechanism underlying this patch set but that is completely incidental to the issue here. We have filed that patent only for the purpose of defense and have no interest or resources to go after infringements. As such, I spoke about the approach, it's value for networking and a few possible ways of implementing it in the kernel at Linux Plumbers Conference 2017. As a contractor and a member of our team at AppSwitch (FKA Fermat), Tycho Andersen helped implement a fully user space version of system call trap mechanism based on seccomp / fd-passing and participated in our team discussions about upstreaming a kernel version of the feature. Given that context, we were taken aback that he posted the v1 patch set without letting us know and without any mention of AppSwitch in the post even though he was still under contract at that time. In any case, please note that we will communicate with Tycho directly regarding this matter going forward. -- Dinesh Subhraveti
Re: [PATCH v4 0/4] seccomp trap to userspace
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 anything to confirm this > claim, I'll put this series on hold. For the sake of everyone's clarity, there is no patent or intellectual property issue here and we'd like to see this feature in the kernel. I did indicate that there is a patent related to the mechanism underlying this patch set but that is completely incidental to the issue here. We have filed that patent only for the purpose of defense and have no interest or resources to go after infringements. As such, I spoke about the approach, it's value for networking and a few possible ways of implementing it in the kernel at Linux Plumbers Conference 2017. As a contractor and a member of our team at AppSwitch (FKA Fermat), Tycho Andersen helped implement a fully user space version of system call trap mechanism based on seccomp / fd-passing and participated in our team discussions about upstreaming a kernel version of the feature. Given that context, we were taken aback that he posted the v1 patch set without letting us know and without any mention of AppSwitch in the post even though he was still under contract at that time. In any case, please note that we will communicate with Tycho directly regarding this matter going forward. -- Dinesh Subhraveti
Re: [PATCH v4 0/4] seccomp trap to userspace
On Mon, 2018-08-06 at 20:44 -0600, 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 anything to confirm this > claim, I'll put this series on hold. Just on a general policy for handling things like this. Firstly, never discuss specifics on a mailing list. Patents are a really tricky area where advice in confidence is needed and lack of confidentiality usually only benefits the patent holder. Secondly, vague threats (like this) can be safely ignored. Thanks to the terms of the GPL and the specific actions of OIN, we legitimately have licences to a vast pool of patents, so we should assume for every vague threat of the existence of a patent that we do legitimately possess a licence until the threat is made specific. Finally, if the vague threat becomes specific (which means citation of patent by number and claim) you need to engage the resources we have at our disposal to investigate. Likely it will be OIN resources that do this investigation, but the way to begin is to start with your corporate counsel for contributions on behalf of a company. If they're on behalf of you as an individual, you can begin with Counsel which the Linux Foundation will provide. James
Re: [PATCH v4 0/4] seccomp trap to userspace
On Mon, 2018-08-06 at 20:44 -0600, 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 anything to confirm this > claim, I'll put this series on hold. Just on a general policy for handling things like this. Firstly, never discuss specifics on a mailing list. Patents are a really tricky area where advice in confidence is needed and lack of confidentiality usually only benefits the patent holder. Secondly, vague threats (like this) can be safely ignored. Thanks to the terms of the GPL and the specific actions of OIN, we legitimately have licences to a vast pool of patents, so we should assume for every vague threat of the existence of a patent that we do legitimately possess a licence until the threat is made specific. Finally, if the vague threat becomes specific (which means citation of patent by number and claim) you need to engage the resources we have at our disposal to investigate. Likely it will be OIN resources that do this investigation, but the way to begin is to start with your corporate counsel for contributions on behalf of a company. If they're on behalf of you as an individual, you can begin with Counsel which the Linux Foundation will provide. James
Re: [PATCH v4 0/4] seccomp trap to userspace
On Mon, Aug 06, 2018 at 09:19:04PM -0700, Andy Lutomirski wrote: > On Mon, Aug 6, 2018 at 8:30 PM, Christian Brauner > wrote: > > On Mon, Aug 06, 2018 at 08:44:42PM -0600, 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 anything to confirm this > >> claim, I'll put this series on hold. > > > > Hey man, > > > > Sorry to hear that your faced with such nonsense, Tycho. This is utter > > bullsh*t of course. If you have more details at some point and feel > > comfortable doing so it would probably be good to share them here. > > IANAL, but I think it would probably *not* be good to share them here. > Patent law is seriously fucked up like that. **ugh**. Yeah, you're probably right. My thought was that in the face of publicity this nonesense might go away quickly. Christian
Re: [PATCH v4 0/4] seccomp trap to userspace
On Mon, Aug 06, 2018 at 09:19:04PM -0700, Andy Lutomirski wrote: > On Mon, Aug 6, 2018 at 8:30 PM, Christian Brauner > wrote: > > On Mon, Aug 06, 2018 at 08:44:42PM -0600, 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 anything to confirm this > >> claim, I'll put this series on hold. > > > > Hey man, > > > > Sorry to hear that your faced with such nonsense, Tycho. This is utter > > bullsh*t of course. If you have more details at some point and feel > > comfortable doing so it would probably be good to share them here. > > IANAL, but I think it would probably *not* be good to share them here. > Patent law is seriously fucked up like that. **ugh**. Yeah, you're probably right. My thought was that in the face of publicity this nonesense might go away quickly. Christian
Re: [PATCH v4 0/4] seccomp trap to userspace
On Mon, Aug 6, 2018 at 8:30 PM, Christian Brauner wrote: > On Mon, Aug 06, 2018 at 08:44:42PM -0600, 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 anything to confirm this >> claim, I'll put this series on hold. > > Hey man, > > Sorry to hear that your faced with such nonsense, Tycho. This is utter > bullsh*t of course. If you have more details at some point and feel > comfortable doing so it would probably be good to share them here. IANAL, but I think it would probably *not* be good to share them here. Patent law is seriously fucked up like that. --Andy
Re: [PATCH v4 0/4] seccomp trap to userspace
On Mon, Aug 6, 2018 at 8:30 PM, Christian Brauner wrote: > On Mon, Aug 06, 2018 at 08:44:42PM -0600, 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 anything to confirm this >> claim, I'll put this series on hold. > > Hey man, > > Sorry to hear that your faced with such nonsense, Tycho. This is utter > bullsh*t of course. If you have more details at some point and feel > comfortable doing so it would probably be good to share them here. IANAL, but I think it would probably *not* be good to share them here. Patent law is seriously fucked up like that. --Andy
Re: [PATCH v4 0/4] seccomp trap to userspace
On Mon, Aug 06, 2018 at 08:44:42PM -0600, 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 anything to confirm this > claim, I'll put this series on hold. Hey man, Sorry to hear that your faced with such nonsense, Tycho. This is utter bullsh*t of course. If you have more details at some point and feel comfortable doing so it would probably be good to share them here. Christian > > Tycho > > On Thu, Jun 21, 2018 at 04:04:12PM -0600, Tycho Andersen wrote: > > Hi all, > > > > Here's v4 of the seccomp trap to userspace series. v3 is here: > > https://lkml.org/lkml/2018/5/31/527 > > > > I believe we've addressed the two burning questions I had about v3: 1. > > it seems ok not to use netlink, since there's not a great way to re-use > > the API without a lot of unnecessary code and 2. only having return > > capability for fds seems fine with people. Or at least I haven't heard > > any strong objections. > > > > I've re-worked a bunch of things in this version based on feedback from > > the last series. See patch notes for details. At this point I'm not > > aware 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: add support for passing fds via USER_NOTIF > > > > .../userspace-api/seccomp_filter.rst | 79 +++ > > arch/Kconfig | 7 + > > include/linux/seccomp.h | 18 +- > > include/uapi/linux/ptrace.h | 2 + > > include/uapi/linux/seccomp.h | 23 +- > > kernel/ptrace.c | 4 + > > kernel/seccomp.c | 491 ++- > > tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +- > > 8 files changed, 1172 insertions(+), 12 deletions(-) > > > > -- > > 2.17.1 > > > ___ > Containers mailing list > contain...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/containers
Re: [PATCH v4 0/4] seccomp trap to userspace
On Mon, Aug 06, 2018 at 08:44:42PM -0600, 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 anything to confirm this > claim, I'll put this series on hold. Hey man, Sorry to hear that your faced with such nonsense, Tycho. This is utter bullsh*t of course. If you have more details at some point and feel comfortable doing so it would probably be good to share them here. Christian > > Tycho > > On Thu, Jun 21, 2018 at 04:04:12PM -0600, Tycho Andersen wrote: > > Hi all, > > > > Here's v4 of the seccomp trap to userspace series. v3 is here: > > https://lkml.org/lkml/2018/5/31/527 > > > > I believe we've addressed the two burning questions I had about v3: 1. > > it seems ok not to use netlink, since there's not a great way to re-use > > the API without a lot of unnecessary code and 2. only having return > > capability for fds seems fine with people. Or at least I haven't heard > > any strong objections. > > > > I've re-worked a bunch of things in this version based on feedback from > > the last series. See patch notes for details. At this point I'm not > > aware 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: add support for passing fds via USER_NOTIF > > > > .../userspace-api/seccomp_filter.rst | 79 +++ > > arch/Kconfig | 7 + > > include/linux/seccomp.h | 18 +- > > include/uapi/linux/ptrace.h | 2 + > > include/uapi/linux/seccomp.h | 23 +- > > kernel/ptrace.c | 4 + > > kernel/seccomp.c | 491 ++- > > tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +- > > 8 files changed, 1172 insertions(+), 12 deletions(-) > > > > -- > > 2.17.1 > > > ___ > Containers mailing list > contain...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/containers
Re: [PATCH v4 0/4] seccomp trap to userspace
> On 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 anything to confirm this > claim, I'll put this series on hold. That... is utterly ridiculous. Does LF have a mechanism to figure out wtf and deal with it by, for example, filing for ex parte review. Every microkernel ever should strongly resemble prior art. > > Tycho > >> On Thu, Jun 21, 2018 at 04:04:12PM -0600, Tycho Andersen wrote: >> Hi all, >> >> Here's v4 of the seccomp trap to userspace series. v3 is here: >> https://lkml.org/lkml/2018/5/31/527 >> >> I believe we've addressed the two burning questions I had about v3: 1. >> it seems ok not to use netlink, since there's not a great way to re-use >> the API without a lot of unnecessary code and 2. only having return >> capability for fds seems fine with people. Or at least I haven't heard >> any strong objections. >> >> I've re-worked a bunch of things in this version based on feedback from >> the last series. See patch notes for details. At this point I'm not >> aware 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: add support for passing fds via USER_NOTIF >> >> .../userspace-api/seccomp_filter.rst | 79 +++ >> arch/Kconfig | 7 + >> include/linux/seccomp.h | 18 +- >> include/uapi/linux/ptrace.h | 2 + >> include/uapi/linux/seccomp.h | 23 +- >> kernel/ptrace.c | 4 + >> kernel/seccomp.c | 491 ++- >> tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +- >> 8 files changed, 1172 insertions(+), 12 deletions(-) >> >> -- >> 2.17.1 >>
Re: [PATCH v4 0/4] seccomp trap to userspace
> On 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 anything to confirm this > claim, I'll put this series on hold. That... is utterly ridiculous. Does LF have a mechanism to figure out wtf and deal with it by, for example, filing for ex parte review. Every microkernel ever should strongly resemble prior art. > > Tycho > >> On Thu, Jun 21, 2018 at 04:04:12PM -0600, Tycho Andersen wrote: >> Hi all, >> >> Here's v4 of the seccomp trap to userspace series. v3 is here: >> https://lkml.org/lkml/2018/5/31/527 >> >> I believe we've addressed the two burning questions I had about v3: 1. >> it seems ok not to use netlink, since there's not a great way to re-use >> the API without a lot of unnecessary code and 2. only having return >> capability for fds seems fine with people. Or at least I haven't heard >> any strong objections. >> >> I've re-worked a bunch of things in this version based on feedback from >> the last series. See patch notes for details. At this point I'm not >> aware 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: add support for passing fds via USER_NOTIF >> >> .../userspace-api/seccomp_filter.rst | 79 +++ >> arch/Kconfig | 7 + >> include/linux/seccomp.h | 18 +- >> include/uapi/linux/ptrace.h | 2 + >> include/uapi/linux/seccomp.h | 23 +- >> kernel/ptrace.c | 4 + >> kernel/seccomp.c | 491 ++- >> tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +- >> 8 files changed, 1172 insertions(+), 12 deletions(-) >> >> -- >> 2.17.1 >>
Re: [PATCH v4 0/4] seccomp trap to userspace
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's v4 of the seccomp trap to userspace series. v3 is here: > https://lkml.org/lkml/2018/5/31/527 > > I believe we've addressed the two burning questions I had about v3: 1. > it seems ok not to use netlink, since there's not a great way to re-use > the API without a lot of unnecessary code and 2. only having return > capability for fds seems fine with people. Or at least I haven't heard > any strong objections. > > I've re-worked a bunch of things in this version based on feedback from > the last series. See patch notes for details. At this point I'm not > aware 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: add support for passing fds via USER_NOTIF > > .../userspace-api/seccomp_filter.rst | 79 +++ > arch/Kconfig | 7 + > include/linux/seccomp.h | 18 +- > include/uapi/linux/ptrace.h | 2 + > include/uapi/linux/seccomp.h | 23 +- > kernel/ptrace.c | 4 + > kernel/seccomp.c | 491 ++- > tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +- > 8 files changed, 1172 insertions(+), 12 deletions(-) > > -- > 2.17.1 >
Re: [PATCH v4 0/4] seccomp trap to userspace
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's v4 of the seccomp trap to userspace series. v3 is here: > https://lkml.org/lkml/2018/5/31/527 > > I believe we've addressed the two burning questions I had about v3: 1. > it seems ok not to use netlink, since there's not a great way to re-use > the API without a lot of unnecessary code and 2. only having return > capability for fds seems fine with people. Or at least I haven't heard > any strong objections. > > I've re-worked a bunch of things in this version based on feedback from > the last series. See patch notes for details. At this point I'm not > aware 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: add support for passing fds via USER_NOTIF > > .../userspace-api/seccomp_filter.rst | 79 +++ > arch/Kconfig | 7 + > include/linux/seccomp.h | 18 +- > include/uapi/linux/ptrace.h | 2 + > include/uapi/linux/seccomp.h | 23 +- > kernel/ptrace.c | 4 + > kernel/seccomp.c | 491 ++- > tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +- > 8 files changed, 1172 insertions(+), 12 deletions(-) > > -- > 2.17.1 >
[PATCH v4 0/4] seccomp trap to userspace
Hi all, Here's v4 of the seccomp trap to userspace series. v3 is here: https://lkml.org/lkml/2018/5/31/527 I believe we've addressed the two burning questions I had about v3: 1. it seems ok not to use netlink, since there's not a great way to re-use the API without a lot of unnecessary code and 2. only having return capability for fds seems fine with people. Or at least I haven't heard any strong objections. I've re-worked a bunch of things in this version based on feedback from the last series. See patch notes for details. At this point I'm not aware 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: add support for passing fds via USER_NOTIF .../userspace-api/seccomp_filter.rst | 79 +++ arch/Kconfig | 7 + include/linux/seccomp.h | 18 +- include/uapi/linux/ptrace.h | 2 + include/uapi/linux/seccomp.h | 23 +- kernel/ptrace.c | 4 + kernel/seccomp.c | 491 ++- tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +- 8 files changed, 1172 insertions(+), 12 deletions(-) -- 2.17.1
[PATCH v4 0/4] seccomp trap to userspace
Hi all, Here's v4 of the seccomp trap to userspace series. v3 is here: https://lkml.org/lkml/2018/5/31/527 I believe we've addressed the two burning questions I had about v3: 1. it seems ok not to use netlink, since there's not a great way to re-use the API without a lot of unnecessary code and 2. only having return capability for fds seems fine with people. Or at least I haven't heard any strong objections. I've re-worked a bunch of things in this version based on feedback from the last series. See patch notes for details. At this point I'm not aware 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: add support for passing fds via USER_NOTIF .../userspace-api/seccomp_filter.rst | 79 +++ arch/Kconfig | 7 + include/linux/seccomp.h | 18 +- include/uapi/linux/ptrace.h | 2 + include/uapi/linux/seccomp.h | 23 +- kernel/ptrace.c | 4 + kernel/seccomp.c | 491 ++- tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +- 8 files changed, 1172 insertions(+), 12 deletions(-) -- 2.17.1
