libseccomp-discuss Mailing List for Seccomp Library
High level interface to the Linux Kernel's seccomp filter
Brought to you by:
pcmoore
Menu
▾
▴
libseccomp-discuss — General Discussion
You can subscribe to this list here.
| 2012 |
Jan
(4) |
Feb
(280) |
Mar
(187) |
Apr
(197) |
May
(10) |
Jun
(29) |
Jul
(45) |
Aug
(60) |
Sep
(30) |
Oct
(40) |
Nov
(30) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(58) |
Feb
(28) |
Mar
(47) |
Apr
(44) |
May
(12) |
Jun
(17) |
Jul
|
Aug
(6) |
Sep
(15) |
Oct
(95) |
Nov
(62) |
Dec
(10) |
| 2014 |
Jan
(19) |
Feb
(48) |
Mar
(2) |
Apr
(95) |
May
(41) |
Jun
(50) |
Jul
(20) |
Aug
(87) |
Sep
(3) |
Oct
(9) |
Nov
|
Dec
|
| 2015 |
Jan
(24) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Paul M. <pa...@pa...> - 2015-02-01 02:43:35
|
On Sat, Jan 31, 2015 at 3:48 PM, Cong Zheng <zc1...@gm...> wrote: > Hi all, > > > It's my first time to use libseccomp. My question is how can I use > libseccomp to filter the first parameter (filename) in open() syscall? > > Thanks for your help. Hello, First, we've moved this mailing list to Google Groups, you can subscribe to the new mailing list at the URL below: * https://groups.google.com/d/forum/libseccomp Now, as far as filtering the filename argument to open(), while you can filter on the string's memory address (char *), you unfortunately can't on the string value itself. This is a limitation of the kernel and not something we can fix in libseccomp. -- paul moore www.paul-moore.com |
|
From: Cong Z. <zc1...@gm...> - 2015-01-31 20:48:54
|
Hi all, It's my first time to use libseccomp. My question is how can I use libseccomp to filter the first parameter (filename) in open() syscall? Thanks for your help. - Cong |
|
From: Mike S. <str...@li...> - 2015-01-30 22:11:21
|
On 01/29/2015 03:00 PM, Paul Moore wrote: > On Thu, Jan 29, 2015 at 6:02 AM, Purcareata Bogdan <b4...@fr...> wrote: >> On 22.01.2015 18:34, Paul Moore wrote: >>> To clarify, are you planning to also develop the necessary kernel support? >>> One of the reasons we do not support ppc* in libseccomp is that the kernel >>> is currently lacking (or at least it was when I looked a few months ago) the >>> necessary CONFIG_SECCOMP_FILTER support. >> >> Thanks for pointing it out, I wasn't aware of the differences between >> seccomp strict and seccomp filter (still new to the subject). >> >> Following the reference at [1], I looked at the bit of how the requirements >> in the kernel apply to ppc: >> >> config HAVE_ARCH_SECCOMP_FILTER >> bool >> help >> An arch should select this symbol if it provides all of these things: >> - syscall_get_arch() - DONE >> - syscall_get_arguments() - DONE >> - syscall_rollback() - DONE >> - syscall_set_return_value() - DONE >> - SIGSYS siginfo_t support - DONE >> (SIGSYS present in arch/powerpc/include/uapi/asm/signal.h) >> - secure_computing is called from a ptrace_event()-safe context >> TO CHECK >> - secure_computing return value is checked and a return value of -1 >> results in the system call being skipped immediately. - TODO >> >> So what's left looks pretty feasible. I'll try to take care of it and come >> back to you when I have some news. > > For what it's worth, IBM might also have some interest in this work. > I'm not exactly sure who would be the best contact there to find out, > but if you have any contacts with IBM it might be worth sending some > mail. Yes, there is interest at IBM. I had just started looking into it when I discovered that there are others interested as well. I am definitely interested in contributing to the kernel and libseccomp support for seccomp filter on powerpc, but want to make sure I'm not duplicating effort that is already being made. Thanks, Mike |
|
From: Paul M. <pm...@re...> - 2015-01-30 21:57:32
|
On Thursday, January 29, 2015 04:03:12 PM Paul Moore wrote: > Hello all, > > For a variety of reasons I'm considering moving the libseccomp git repo and > mailing list away from SourceForge to a combination of Github and Google > Groups. Before I make it official, does anyone have any strong objections? > > Strong objections that come with a viable alternative will be considered > more than just strong objections ;) Hearing no objections, I'm moving the source repository and mailing list. The repository now lives at the following Github URL: * https://github.com/seccomp/libseccomp ... and the mailing list (see the above To line) is now on Google Groups: * https://groups.google.com/d/forum/libseccomp Note that I'm not automatically subscribing or unsubscribing anyone from the mailing lists, that will be up to you. As far as the repo is concerned you should be able to point any local trees you may have at the new Github repo and everything should work as expected. I'm going to close the existing sf.net mailing list to new subscribers in just a moment and I'll likely clear out the sf.net git tree next week as well (with a pointer to the new Github tree). Thanks for your understanding, -Paul -- paul moore security @ redhat |
|
From: Paul M. <pa...@pa...> - 2015-01-30 15:45:10
|
On Thu, Jan 29, 2015 at 6:40 PM, Nikos Mavrogiannopoulos <nm...@re...> wrote: > ----- Original Message ----- >> After doing some additional testing using a default SCMP_ACT_KILL >> filter action on 32-bit x86 and looking at the syslog/audit log for >> seccomp kill notifications, I see the following record: >> >> Jan 29 16:09:48 [kernel] audit: type=1326 audit(1422565788.766:3): >> auid=1000 uid=1000 gid=100 ses=1 pid=314 comm="00-test" >> exe="/home/pmoore/sources/seccomp/libseccomp-upstream/tests/00-test" >> sig=31 syscall=142 compat=1 ip=0xf7705d10 code=0x0 >> >> ... if we lookup syscall #142 we see that it is for _newselect() and >> not select(): >> ... it would appear that the 32-bit x86 glibc uses _newselect() >> internally for the select() function. I suggest updating your filter >> accordingly by allowing both select() and _newselect(). > > Thank you... That is pretty interesting as strace shows select being called. Yes, it is. I suspect the strace authors chose to display select() instead of _newselect() to hide some glibc implementation details and make life easier for the majority of admins/devs; unfortunately this makes it a bit more difficult for those of us trying to craft syscall filters. Someday I hope to have some better tools for analyzing binaries, but that is still a ways off. -- paul moore www.paul-moore.com |
|
From: Eduardo O. <edu...@pr...> - 2015-01-30 10:24:15
|
On Thu, Jan 29, 2015 at 04:03:12PM -0500, Paul Moore wrote: > Hello all, > > For a variety of reasons I'm considering moving the libseccomp git repo and > mailing list away from SourceForge to a combination of Github and Google > Groups. Before I make it official, does anyone have any strong objections? > I actually do prefer github. -- Eduardo Otubo ProfitBricks GmbH |
|
From: Nikos M. <nm...@re...> - 2015-01-29 23:41:02
|
----- Original Message ----- > After doing some additional testing using a default SCMP_ACT_KILL > filter action on 32-bit x86 and looking at the syslog/audit log for > seccomp kill notifications, I see the following record: > > Jan 29 16:09:48 [kernel] audit: type=1326 audit(1422565788.766:3): > auid=1000 uid=1000 gid=100 ses=1 pid=314 comm="00-test" > exe="/home/pmoore/sources/seccomp/libseccomp-upstream/tests/00-test" > sig=31 syscall=142 compat=1 ip=0xf7705d10 code=0x0 > > ... if we lookup syscall #142 we see that it is for _newselect() and > not select(): > ... it would appear that the 32-bit x86 glibc uses _newselect() > internally for the select() function. I suggest updating your filter > accordingly by allowing both select() and _newselect(). Thank you... That is pretty interesting as strace shows select being called. regards, Nikos |
|
From: Paul M. <pa...@pa...> - 2015-01-29 21:14:39
|
On Thu, Jan 29, 2015 at 8:01 AM, Nikos Mavrogiannopoulos <nm...@re...> wrote: > On Wed, 2015-01-28 at 16:10 -0500, Paul Moore wrote: >> > > Did you try adding the x86 ABI to the filter? I'm curious if that >> > > resolves the problem. >> > No, it doesn't. I also asked the user in the thread above to run the >> > reproducer and he gets the same result. Select is blocked. >> Okay, thanks for checking. We'll have to look into it. By change have you >> tested the current upstream library? We have fixed a lot of bugs since the >> last release, although I'm not sure there is anything that would affect your >> problem with select() ... > > I tried to get the git repository and compile: > http://sourceforge.net/p/libseccomp/libseccomp/ci/master/tree/ > but compiles a library which is binary incompatible with the system's > seccomp (has soversion 0, while the system's version is 2). > I statically linked it, but the issue remained. After doing some additional testing using a default SCMP_ACT_KILL filter action on 32-bit x86 and looking at the syslog/audit log for seccomp kill notifications, I see the following record: Jan 29 16:09:48 [kernel] audit: type=1326 audit(1422565788.766:3): auid=1000 uid=1000 gid=100 ses=1 pid=314 comm="00-test" exe="/home/pmoore/sources/seccomp/libseccomp-upstream/tests/00-test" sig=31 syscall=142 compat=1 ip=0xf7705d10 code=0x0 ... if we lookup syscall #142 we see that it is for _newselect() and not select(): # scmp_sys_resolver -a x86 142 _newselect ... it would appear that the 32-bit x86 glibc uses _newselect() internally for the select() function. I suggest updating your filter accordingly by allowing both select() and _newselect(). -- paul moore www.paul-moore.com |
|
From: Paul M. <pm...@re...> - 2015-01-29 21:03:21
|
Hello all, For a variety of reasons I'm considering moving the libseccomp git repo and mailing list away from SourceForge to a combination of Github and Google Groups. Before I make it official, does anyone have any strong objections? Strong objections that come with a viable alternative will be considered more than just strong objections ;) -Paul -- paul moore security @ redhat |
|
From: Paul M. <pa...@pa...> - 2015-01-29 21:00:36
|
On Thu, Jan 29, 2015 at 6:02 AM, Purcareata Bogdan <b4...@fr...> wrote: > On 22.01.2015 18:34, Paul Moore wrote: >> To clarify, are you planning to also develop the necessary kernel support? >> One of the reasons we do not support ppc* in libseccomp is that the kernel >> is currently lacking (or at least it was when I looked a few months ago) the >> necessary CONFIG_SECCOMP_FILTER support. > > Thanks for pointing it out, I wasn't aware of the differences between > seccomp strict and seccomp filter (still new to the subject). > > Following the reference at [1], I looked at the bit of how the requirements > in the kernel apply to ppc: > > config HAVE_ARCH_SECCOMP_FILTER > bool > help > An arch should select this symbol if it provides all of these things: > - syscall_get_arch() - DONE > - syscall_get_arguments() - DONE > - syscall_rollback() - DONE > - syscall_set_return_value() - DONE > - SIGSYS siginfo_t support - DONE > (SIGSYS present in arch/powerpc/include/uapi/asm/signal.h) > - secure_computing is called from a ptrace_event()-safe context > TO CHECK > - secure_computing return value is checked and a return value of -1 > results in the system call being skipped immediately. - TODO > > So what's left looks pretty feasible. I'll try to take care of it and come > back to you when I have some news. For what it's worth, IBM might also have some interest in this work. I'm not exactly sure who would be the best contact there to find out, but if you have any contacts with IBM it might be worth sending some mail. > Meanwhile, I added the support for ppc in the master libseccomp by > backporting Marcus's patch. All the regression tests pass - the initial > problem with the BPF simulator has been fixed. Okay, that's good to know. I'm a little busy right now with other things at the moment, but if you intend to work on this, perhaps I'll setup a ppc branch that we can work from while we wait for proper kernel support. > I plan to post the patch after I've validated SECCOMP_FILTER support for ppc > in the kernel. I saw that the regression tests use an userspace BPF > simulator for testing the library. Are there any tests than I can use to > validate the kernel SECCOMP_FILTER support as well? Look at the "live" tests, they are basic, but they do perform some basic sanity checks. # ./regression -T live > [1] https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt > > Thanks, > Bogdan P. -- paul moore www.paul-moore.com |
|
From: Nikos M. <nm...@re...> - 2015-01-29 13:01:50
|
On Wed, 2015-01-28 at 16:10 -0500, Paul Moore wrote: > > > Did you try adding the x86 ABI to the filter? I'm curious if that > > > resolves the problem. > > No, it doesn't. I also asked the user in the thread above to run the > > reproducer and he gets the same result. Select is blocked. > Okay, thanks for checking. We'll have to look into it. By change have you > tested the current upstream library? We have fixed a lot of bugs since the > last release, although I'm not sure there is anything that would affect your > problem with select() ... I tried to get the git repository and compile: http://sourceforge.net/p/libseccomp/libseccomp/ci/master/tree/ but compiles a library which is binary incompatible with the system's seccomp (has soversion 0, while the system's version is 2). I statically linked it, but the issue remained. regards, Nikos |
|
From: Purcareata B. <b4...@fr...> - 2015-01-29 11:17:12
|
On 22.01.2015 18:34, Paul Moore wrote: > On Thursday, January 22, 2015 09:16:43 AM Purcareata Bogdan wrote: >> On 22.01.2015 09:12, Marcus Meissner wrote: >>> On Wed, Jan 21, 2015 at 10:23:42PM -0500, Paul Moore wrote: >>>> On Wed, Jan 21, 2015 at 7:37 AM, Marcus Meissner wrote: >>>>> On Wed, Jan 21, 2015 at 02:35:51PM +0200, Purcareata Bogdan wrote: >>>>>> Hello, >>>>>> >>>>>> I noticed a patch from a while ago on the mailing list adding support >>>>>> for PowerPC platforms and zSeries [1]. The patch, however, has not been >>>>>> upstreamed due to some issues in the testsuite. I was wondering whether >>>>>> there have been any news on the patch and whether it's still of >>>>>> interest. >>>>>> >>>>>> I'm interested in running LXC containers on PowerPC platforms, and >>>>>> would >>>>>> like to have seccomp support as well. Right now, I don't have much >>>>>> experience with seccomp, but I would be glad to start looking at the >>>>>> code and contribute. >>>>>> >>>>>> [1]http://sourceforge.net/p/libseccomp/mailman/message/32609277/ >>>>> >>>>> I did not continue on this patch as my other work is keeping me very >>>>> busy, >>>>> sadly also for the foreseeable future. >>>>> >>>>> Feel free to take and improve. >>>> >>>> I also put together some patches to support ppc64, but never tested >>>> them on a ppc64 system, and to be honest it was a few months ago so >>>> I'm not sure what state they are in ... if you are interested I can >>>> try to dust them off and post them here. >>> >>> I can still test ppc32 and ppc64 (big or little endian) if there is need. >> >> Anything would be great. I'm planning to develop and test both ppc and >> ppc64 Linux. Not sure at this point if there is any impact, but the >> platforms I'm working on are book3e, not book3s. >> >> Unfortunately I don't have access to any zSeries platforms. > > To clarify, are you planning to also develop the necessary kernel support? > One of the reasons we do not support ppc* in libseccomp is that the kernel is > currently lacking (or at least it was when I looked a few months ago) the > necessary CONFIG_SECCOMP_FILTER support. Thanks for pointing it out, I wasn't aware of the differences between seccomp strict and seccomp filter (still new to the subject). Following the reference at [1], I looked at the bit of how the requirements in the kernel apply to ppc: config HAVE_ARCH_SECCOMP_FILTER bool help An arch should select this symbol if it provides all of these things: - syscall_get_arch() - DONE - syscall_get_arguments() - DONE - syscall_rollback() - DONE - syscall_set_return_value() - DONE - SIGSYS siginfo_t support - DONE (SIGSYS present in arch/powerpc/include/uapi/asm/signal.h) - secure_computing is called from a ptrace_event()-safe context TO CHECK - secure_computing return value is checked and a return value of -1 results in the system call being skipped immediately. - TODO So what's left looks pretty feasible. I'll try to take care of it and come back to you when I have some news. Meanwhile, I added the support for ppc in the master libseccomp by backporting Marcus's patch. All the regression tests pass - the initial problem with the BPF simulator has been fixed. I plan to post the patch after I've validated SECCOMP_FILTER support for ppc in the kernel. I saw that the regression tests use an userspace BPF simulator for testing the library. Are there any tests than I can use to validate the kernel SECCOMP_FILTER support as well? [1] https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt Thanks, Bogdan P. |
|
From: Paul M. <pm...@re...> - 2015-01-28 21:10:57
|
On Wednesday, January 28, 2015 09:23:29 AM Nikos Mavrogiannopoulos wrote: > On Tue, 2015-01-27 at 13:05 -0500, Paul Moore wrote: > > Did you try adding the x86 ABI to the filter? I'm curious if that > > resolves the problem. > > No, it doesn't. I also asked the user in the thread above to run the > reproducer and he gets the same result. Select is blocked. Okay, thanks for checking. We'll have to look into it. By change have you tested the current upstream library? We have fixed a lot of bugs since the last release, although I'm not sure there is anything that would affect your problem with select() ... -- paul moore security @ redhat |
|
From: Nikos M. <nm...@re...> - 2015-01-28 08:23:38
|
On Tue, 2015-01-27 at 13:05 -0500, Paul Moore wrote: > > Yes, I'm linking using the Fedora's i686 library. I should have mentioned > > that this is a reproducer for an issue reported to me: > > http://lists.infradead.org/pipermail/openconnect-devel/2015-January/002640. > > html I have no i686 available to me, that's why I reproduce that way. > > > > > > Note that allow others calls (e.g., write) are properly executed as > > > > expected. > > > > > > Have you verified this via strace, or similar? > > > > I see the output on my screen so write worked :) Running it with strace > shows the expected result. > Yes, of course. Sorry about that :) > Did you try adding the x86 ABI to the filter? I'm curious if that resolves > the problem. No, it doesn't. I also asked the user in the thread above to run the reproducer and he gets the same result. Select is blocked. http://lists.infradead.org/pipermail/openconnect-devel/2015-January/002644.html regards, Nikos |
|
From: Paul M. <pm...@re...> - 2015-01-27 18:05:23
|
On Tuesday, January 27, 2015 12:13:15 PM Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > > On Tuesday, January 27, 2015 04:45:52 PM Nikos Mavrogiannopoulos wrote: > > > Hello, > > > > > > The attached program as far as I understand creates a filter which > > > > > > allows select(). That works well on my x86-64: > > > $ gcc test.c -lseccomp;./a.out > > > all ok > > > > > > However, if I run the same thing under i686 emulation, I have: > > > $ gcc -m32 test.c -lseccomp;./a.out > > > select is blocked! > > > > Since you are running on an x86_64 system, you probably want to explicitly > > add support for the x86 ABI if you are interested in creating a filter > > that works on both x86_64 and x86. This is probably not strictly > > necessary if you are certain that you are linking to a properly build > > native x86 library, but I can't be certain based on what you've posted. > > Yes, I'm linking using the Fedora's i686 library. I should have mentioned > that this is a reproducer for an issue reported to me: > http://lists.infradead.org/pipermail/openconnect-devel/2015-January/002640. > html I have no i686 available to me, that's why I reproduce that way. > > > > Note that allow others calls (e.g., write) are properly executed as > > > expected. > > > > Have you verified this via strace, or similar? > > I see the output on my screen so write worked :) Running it with strace > shows the expected result. Yes, of course. Sorry about that :) Did you try adding the x86 ABI to the filter? I'm curious if that resolves the problem. -- paul moore security @ redhat |
|
From: Nikos M. <nm...@re...> - 2015-01-27 17:13:23
|
----- Original Message ----- > On Tuesday, January 27, 2015 04:45:52 PM Nikos Mavrogiannopoulos wrote: > > Hello, > > The attached program as far as I understand creates a filter which > > allows select(). That works well on my x86-64: > > $ gcc test.c -lseccomp;./a.out > > all ok > > > > However, if I run the same thing under i686 emulation, I have: > > $ gcc -m32 test.c -lseccomp;./a.out > > select is blocked! > > Since you are running on an x86_64 system, you probably want to explicitly > add > support for the x86 ABI if you are interested in creating a filter that works > on both x86_64 and x86. This is probably not strictly necessary if you are > certain that you are linking to a properly build native x86 library, but I > can't be certain based on what you've posted. Yes, I'm linking using the Fedora's i686 library. I should have mentioned that this is a reproducer for an issue reported to me: http://lists.infradead.org/pipermail/openconnect-devel/2015-January/002640.html I have no i686 available to me, that's why I reproduce that way. > > Note that allow others calls (e.g., write) are properly executed as > > expected. > Have you verified this via strace, or similar? I see the output on my screen so write worked :) Running it with strace shows the expected result. > Without digging to deeply, it > looks like you test select() before you test write(); if select() fails > you'll never know if write() worked correctly or not. Since I see output in my screen, I believe that write worked as expected. regards, Nikos |
|
From: Paul M. <pm...@re...> - 2015-01-27 16:02:47
|
On Tuesday, January 27, 2015 04:45:52 PM Nikos Mavrogiannopoulos wrote: > Hello, > The attached program as far as I understand creates a filter which > allows select(). That works well on my x86-64: > $ gcc test.c -lseccomp;./a.out > all ok > > However, if I run the same thing under i686 emulation, I have: > $ gcc -m32 test.c -lseccomp;./a.out > select is blocked! Since you are running on an x86_64 system, you probably want to explicitly add support for the x86 ABI if you are interested in creating a filter that works on both x86_64 and x86. This is probably not strictly necessary if you are certain that you are linking to a properly build native x86 library, but I can't be certain based on what you've posted. Look at the seccomp_arch_add(3) man page. > Note that allow others calls (e.g., write) are properly executed as > expected. Have you verified this via strace, or similar? Without digging to deeply, it looks like you test select() before you test write(); if select() fails you'll never know if write() worked correctly or not. > Running strace without seccomp being applied shows: > select(4, [3], NULL, NULL, NULL) = 1 (in [3]) > So as far as I understand the syscall select() is being called. > Am I missing something here? > > regards, > Nikos -- paul moore security @ redhat |
|
From: Nikos M. <nm...@re...> - 2015-01-27 15:46:06
|
Hello, The attached program as far as I understand creates a filter which allows select(). That works well on my x86-64: $ gcc test.c -lseccomp;./a.out all ok However, if I run the same thing under i686 emulation, I have: $ gcc -m32 test.c -lseccomp;./a.out select is blocked! Note that allow others calls (e.g., write) are properly executed as expected. Running strace without seccomp being applied shows: select(4, [3], NULL, NULL, NULL) = 1 (in [3]) So as far as I understand the syscall select() is being called. Am I missing something here? regards, Nikos |
|
From: Paul M. <pa...@pa...> - 2015-01-22 16:56:47
|
On Thursday, January 22, 2015 09:16:43 AM Purcareata Bogdan wrote: > On 22.01.2015 09:12, Marcus Meissner wrote: > > On Wed, Jan 21, 2015 at 10:23:42PM -0500, Paul Moore wrote: > >> On Wed, Jan 21, 2015 at 7:37 AM, Marcus Meissner wrote: > >>> On Wed, Jan 21, 2015 at 02:35:51PM +0200, Purcareata Bogdan wrote: > >>>> Hello, > >>>> > >>>> I noticed a patch from a while ago on the mailing list adding support > >>>> for PowerPC platforms and zSeries [1]. The patch, however, has not been > >>>> upstreamed due to some issues in the testsuite. I was wondering whether > >>>> there have been any news on the patch and whether it's still of > >>>> interest. > >>>> > >>>> I'm interested in running LXC containers on PowerPC platforms, and > >>>> would > >>>> like to have seccomp support as well. Right now, I don't have much > >>>> experience with seccomp, but I would be glad to start looking at the > >>>> code and contribute. > >>>> > >>>> [1]http://sourceforge.net/p/libseccomp/mailman/message/32609277/ > >>> > >>> I did not continue on this patch as my other work is keeping me very > >>> busy, > >>> sadly also for the foreseeable future. > >>> > >>> Feel free to take and improve. > >> > >> I also put together some patches to support ppc64, but never tested > >> them on a ppc64 system, and to be honest it was a few months ago so > >> I'm not sure what state they are in ... if you are interested I can > >> try to dust them off and post them here. > > > > I can still test ppc32 and ppc64 (big or little endian) if there is need. > > Anything would be great. I'm planning to develop and test both ppc and > ppc64 Linux. Not sure at this point if there is any impact, but the > platforms I'm working on are book3e, not book3s. > > Unfortunately I don't have access to any zSeries platforms. To clarify, are you planning to also develop the necessary kernel support? One of the reasons we do not support ppc* in libseccomp is that the kernel is currently lacking (or at least it was when I looked a few months ago) the necessary CONFIG_SECCOMP_FILTER support. -- paul moore www.paul-moore.com |
|
From: Purcareata B. <b4...@fr...> - 2015-01-22 07:32:14
|
On 22.01.2015 09:12, Marcus Meissner wrote: > On Wed, Jan 21, 2015 at 10:23:42PM -0500, Paul Moore wrote: >> On Wed, Jan 21, 2015 at 7:37 AM, Marcus Meissner <mei...@su...> wrote: >>> On Wed, Jan 21, 2015 at 02:35:51PM +0200, Purcareata Bogdan wrote: >>>> Hello, >>>> >>>> I noticed a patch from a while ago on the mailing list adding support >>>> for PowerPC platforms and zSeries [1]. The patch, however, has not been >>>> upstreamed due to some issues in the testsuite. I was wondering whether >>>> there have been any news on the patch and whether it's still of interest. >>>> >>>> I'm interested in running LXC containers on PowerPC platforms, and would >>>> like to have seccomp support as well. Right now, I don't have much >>>> experience with seccomp, but I would be glad to start looking at the >>>> code and contribute. >>>> >>>> [1]http://sourceforge.net/p/libseccomp/mailman/message/32609277/ >>> >>> I did not continue on this patch as my other work is keeping me very busy, >>> sadly also for the foreseeable future. >>> >>> Feel free to take and improve. >> >> I also put together some patches to support ppc64, but never tested >> them on a ppc64 system, and to be honest it was a few months ago so >> I'm not sure what state they are in ... if you are interested I can >> try to dust them off and post them here. > > I can still test ppc32 and ppc64 (big or little endian) if there is need. Anything would be great. I'm planning to develop and test both ppc and ppc64 Linux. Not sure at this point if there is any impact, but the platforms I'm working on are book3e, not book3s. Unfortunately I don't have access to any zSeries platforms. Thank you for the kind replies, Bogdan P. |
|
From: Marcus M. <mei...@su...> - 2015-01-22 07:12:11
|
On Wed, Jan 21, 2015 at 10:23:42PM -0500, Paul Moore wrote: > On Wed, Jan 21, 2015 at 7:37 AM, Marcus Meissner <mei...@su...> wrote: > > On Wed, Jan 21, 2015 at 02:35:51PM +0200, Purcareata Bogdan wrote: > >> Hello, > >> > >> I noticed a patch from a while ago on the mailing list adding support > >> for PowerPC platforms and zSeries [1]. The patch, however, has not been > >> upstreamed due to some issues in the testsuite. I was wondering whether > >> there have been any news on the patch and whether it's still of interest. > >> > >> I'm interested in running LXC containers on PowerPC platforms, and would > >> like to have seccomp support as well. Right now, I don't have much > >> experience with seccomp, but I would be glad to start looking at the > >> code and contribute. > >> > >> [1]http://sourceforge.net/p/libseccomp/mailman/message/32609277/ > > > > I did not continue on this patch as my other work is keeping me very busy, > > sadly also for the foreseeable future. > > > > Feel free to take and improve. > > I also put together some patches to support ppc64, but never tested > them on a ppc64 system, and to be honest it was a few months ago so > I'm not sure what state they are in ... if you are interested I can > try to dust them off and post them here. I can still test ppc32 and ppc64 (big or little endian) if there is need. Ciao, Marcus |
|
From: Paul M. <pa...@pa...> - 2015-01-22 03:52:09
|
On Wed, Jan 21, 2015 at 7:37 AM, Marcus Meissner <mei...@su...> wrote: > On Wed, Jan 21, 2015 at 02:35:51PM +0200, Purcareata Bogdan wrote: >> Hello, >> >> I noticed a patch from a while ago on the mailing list adding support >> for PowerPC platforms and zSeries [1]. The patch, however, has not been >> upstreamed due to some issues in the testsuite. I was wondering whether >> there have been any news on the patch and whether it's still of interest. >> >> I'm interested in running LXC containers on PowerPC platforms, and would >> like to have seccomp support as well. Right now, I don't have much >> experience with seccomp, but I would be glad to start looking at the >> code and contribute. >> >> [1]http://sourceforge.net/p/libseccomp/mailman/message/32609277/ > > I did not continue on this patch as my other work is keeping me very busy, > sadly also for the foreseeable future. > > Feel free to take and improve. I also put together some patches to support ppc64, but never tested them on a ppc64 system, and to be honest it was a few months ago so I'm not sure what state they are in ... if you are interested I can try to dust them off and post them here. -- paul moore www.paul-moore.com |
|
From: Purcareata B. <b4...@fr...> - 2015-01-21 12:51:03
|
Hello, I noticed a patch from a while ago on the mailing list adding support for PowerPC platforms and zSeries [1]. The patch, however, has not been upstreamed due to some issues in the testsuite. I was wondering whether there have been any news on the patch and whether it's still of interest. I'm interested in running LXC containers on PowerPC platforms, and would like to have seccomp support as well. Right now, I don't have much experience with seccomp, but I would be glad to start looking at the code and contribute. [1]http://sourceforge.net/p/libseccomp/mailman/message/32609277/ Best regards, Bogdan P. |
|
From: Marcus M. <mei...@su...> - 2015-01-21 12:37:52
|
On Wed, Jan 21, 2015 at 02:35:51PM +0200, Purcareata Bogdan wrote: > Hello, > > I noticed a patch from a while ago on the mailing list adding support > for PowerPC platforms and zSeries [1]. The patch, however, has not been > upstreamed due to some issues in the testsuite. I was wondering whether > there have been any news on the patch and whether it's still of interest. > > I'm interested in running LXC containers on PowerPC platforms, and would > like to have seccomp support as well. Right now, I don't have much > experience with seccomp, but I would be glad to start looking at the > code and contribute. > > [1]http://sourceforge.net/p/libseccomp/mailman/message/32609277/ I did not continue on this patch as my other work is keeping me very busy, sadly also for the foreseeable future. Feel free to take and improve. Ciao, Marcus |
|
From: Paul M. <pm...@re...> - 2015-01-14 19:09:31
|
On Wednesday, January 14, 2015 01:50:04 PM AKASHI Takahiro wrote: > Paul, > > My kernel patch of seccomp support for aarch64/arm64 is now mainlined > in Linus' tree (at v3.19-rc1). > Please check it out. Yes, that's good news. Unfortunately, I don't have access to any aarch64 systems so I'm relying on you to do the testing. I assume you've tested the current libseccomp repository against v3.19-rcX? Once the v3.19 kernel is released if you can do one final libseccomp test run, including the live tests, I would appreciate it. If everything works correctly I'll make a new libseccomp release. -Paul > On 09/18/2014 01:17 AM, Paul Moore wrote: > > On Wednesday, September 17, 2014 08:55:26 AM AKASHI Takahiro wrote: > >> Hi Paul, > >> > >> On 09/16/2014 03:29 PM, Paul Moore wrote: > >>> On Thursday, August 28, 2014 09:14:35 PM Paul Moore wrote: > >>>> On Friday, August 29, 2014 09:47:55 AM AKASHI Takahiro wrote: > >>>>> On 08/28/2014 11:35 PM, Paul Moore wrote: > >>>>>> On Wednesday, August 27, 2014 03:51:59 PM Paul Moore wrote: > >>>>>>> On Wednesday, August 27, 2014 09:38:06 PM Marcin Juszkiewicz wrote: > >>>>>>>> Anyway - when release so we can get it into distributions? :D > >>>>>>> > >>>>>>> Good question. I think we are at a point where we could do a new > >>>>>>> release, > >>>>>>> the addition of the various MIPS ABIs and 64-bit ARM are significant > >>>>>>> in > >>>>>>> my > >>>>>>> mind. I know the distro packagers will also really like the > >>>>>>> autotools > >>>>>>> conversion (sigh). > >>>>>> > >>>>>> Now that Markos has validated all the different MIPS variants, my > >>>>>> next > >>>>>> question is when do we expect aarch64 in a mainline kernel release? > >>>>>> In > >>>>>> general I like to wait until support is in a released upstream kernel > >>>>>> before we claim support in libseccomp. > >>>>>> > >>>>>> Aarch64 guys, when do you expect support in a released kernel from > >>>>>> Linus? > >>>>> > >>>>> Targeting v3.18, I have already posted v6 of seccomp patch (and v7 > >>>>> will > >>>>> follow soon), but not been able to convince the maintainers to ack it. > >>>> > >>>> Okay, thanks. Please let me know how things progress, I'd like to do a > >>>> new > >>>> libseccomp release shortly after v3.18 is released and it would be very > >>>> nice if we could include aarch64. > >>> > >>> Just thought I would check to see how things were going with Aarch64 and > >>> CONFIG_SECCOMP_FILTER ... any news you can share? > >> > >> It's a bit behind than what I expected, but still targeting v3.18. > >> I'm now at Linaro Connect USA and saw one of arm64 maitainers. > >> Basically we agreed, but some miner fixes are still needed. > > > > Okay, thanks for the update. -- paul moore security @ redhat |
12 messages has been excluded from this view by a project administrator.
