seccomp.2: Explain arch checking, value (non-)truncation, expand example
PATCH 1/1 seccomp.2: Explain arch checking, value (non-)truncation, expand example
Document some more-or-less surprising things about seccomp. I'm not sure whether changing the example code like that is a good idea - maybe that part of the patch should be left out?
Demo code for the X32 issue:
https://gist.github.com/thejh/c5b670a816bbb9791a6d
Demo code for full 64bit registers being visible in seccomp if the i386 ABI is used on a 64bit system:
https://gist.github.com/thejh/c37b27aefc44ab775db5
--- man2/seccomp.2 | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 66 insertions(+), 6 deletions(-)
man2/seccomp.2 +66 -6
@@ -223,6 +223,47 @@ struct seccomp_data { .fi .in +Because the numbers of system calls vary between architectures and +some architectures (e.g. X86-64) allow user-space code to use +the calling conventions of multiple architectures, it is usually +necessary to verify the value of the +.IR arch +field. + +The +.IR arch +field is not unique for all calling conventions. The X86-64 ABI and +the X32 ABI both use +.BR AUDIT_ARCH_X86_64 +as +.IR arch , +and they run on the same processors. Instead, the mask +.BR __X32_SYSCALL_BIT +is used on the system call number to tell the two ABIs apart. +This means that in order to create a seccomp-based +blacklist for system calls performed through the X86-64 ABI, +it is necessary to not only check that +.IR arch +equals +.BR AUDIT_ARCH_X86_64 , +but also to explicitly reject all syscalls that contain +.BR __X32_SYSCALL_BIT +in +.IR nr . + +When checking values from +.IR args +against a blacklist, keep in mind that arguments are often +silently truncated before being processed, but after the seccomp +check. For example, this happens if the i386 ABI is used on an +X86-64 kernel: Although the kernel will normally not look beyond +the 32 lowest bits of the arguments, the values of the full +64-bit registers will be present in the seccomp data. A less +surprising example is that if any 64-bit ABI is used to perform +a syscall that takes an argument of type int, the +more-significant half of the argument register is ignored by +the syscall, but visible in the seccomp data. + A seccomp filter returns a 32-bit value consisting of two parts: the most significant 16 bits (corresponding to the mask defined by the constant
@@ -584,38 +625,57 @@ cecilia #include <linux/seccomp.h> #include <sys/prctl.h> +#define X32_SYSCALL_BIT 0x40000000 + static int install_filter(int syscall_nr, int t_arch, int f_errno) { + int forbidden_bitmask = 0; + /* assume that AUDIT_ARCH_X86_64 means the normal X86-64 ABI */ + if (t_arch == AUDIT_ARCH_X86_64) + forbidden_bitmask = X32_SYSCALL_BIT; + struct sock_filter filter[] = { /* [0] Load architecture from 'seccomp_data' buffer into accumulator */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, arch))), - /* [1] Jump forward 4 instructions if architecture does not + /* [1] Jump forward 7 instructions if architecture does not match 't_arch' */ - BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 4), + BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 7), /* [2] Load system call number from 'seccomp_data' buffer into accumulator */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, nr))), - /* [3] Jump forward 1 instruction if system call number + /* [3] Determine ABI from system call number - only needed for X86-64 + in blacklist usecases */ + BPF_STMT(BPF_ALU | BPF_AND | BPF_K, forbidden_bitmask), + + /* [4] Check ABI - only needed for X86-64 in blacklist usecases */ + BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, 0, 0, 4), + + /* [5] Load system call number from 'seccomp_data' buffer into + accumulator */ + BPF_STMT(BPF_LD | BPF_W | BPF_ABS, + (offsetof(struct seccomp_data, nr))), + + /* [6] Jump forward 1 instruction if system call number does not match 'syscall_nr' */ BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, syscall_nr, 0, 1), - /* [4] Matching architecture and system call: don't execute + /* [7] Matching architecture and system call: don't execute the system call, and return 'f_errno' in 'errno' */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | (f_errno & SECCOMP_RET_DATA)), - /* [5] Destination of system call number mismatch: allow other + /* [8] Destination of system call number mismatch: allow other system calls */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), - /* [6] Destination of architecture mismatch: kill process */ + /* [9] Destination of architecture mismatch: kill process */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL), };
Signature · 1 line
2.1.4
Quoted 10 lines · Jann Horn
Document some more-or-less surprising things about seccomp. I'm not sure whether changing the example code like that is a good idea - maybe that part of the patch should be left out?
Demo code for the X32 issue:
https://gist.github.com/thejh/c5b670a816bbb9791a6dDemo code for full 64bit registers being visible in seccomp if the i386 ABI is used on a 64bit system:
https://gist.github.com/thejh/c37b27aefc44ab775db5
So, it is probably worth noting the x32 ABI somewhere, and seccomp.2 is probably reasonable, though maybe it should be explicitly detailed in syscall.2?
In the seccomp.2 manpage, though, I think we should discourage blacklisting, since whitelisting is a much more effective way to do attack surface reduction on syscalls. (And, as such, x32 would be already eliminated from x86-64 filters.)
It is, however, reasonable to update the example just so it can be super-explicit, though I'd change the comments to say something more direct about the whitelisting vs blacklisting, like "While this example uses whitelisting, this is how an overlapping syscall ABI could be tested." or something. Additionally, I think it would be better to test for >= instead of & to avoid having to reload the syscall nr.
Thanks for this clarification!
-Kees
Quoted 123 lines
--- man2/seccomp.2 | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 66 insertions(+), 6 deletions(-)man2/seccomp.2 +66
-7@@ -223,6 +223,47 @@ struct seccomp_data { .fi .in +Because the numbers of system calls vary between architectures and +some architectures (e.g. X86-64) allow user-space code to use +the calling conventions of multiple architectures, it is usually +necessary to verify the value of the +.IR arch +field. + +The +.IR arch +field is not unique for all calling conventions. The X86-64 ABI and +the X32 ABI both use +.BR AUDIT_ARCH_X86_64 +as +.IR arch , +and they run on the same processors. Instead, the mask +.BR __X32_SYSCALL_BIT +is used on the system call number to tell the two ABIs apart. +This means that in order to create a seccomp-based +blacklist for system calls performed through the X86-64 ABI, +it is necessary to not only check that +.IR arch +equals +.BR AUDIT_ARCH_X86_64 , +but also to explicitly reject all syscalls that contain +.BR __X32_SYSCALL_BIT +in +.IR nr . + +When checking values from +.IR args +against a blacklist, keep in mind that arguments are often +silently truncated before being processed, but after the seccomp +check. For example, this happens if the i386 ABI is used on an +X86-64 kernel: Although the kernel will normally not look beyond +the 32 lowest bits of the arguments, the values of the full +64-bit registers will be present in the seccomp data. A less +surprising example is that if any 64-bit ABI is used to perform +a syscall that takes an argument of type int, the +more-significant half of the argument register is ignored by +the syscall, but visible in the seccomp data. + A seccomp filter returns a 32-bit value consisting of two parts: the most significant 16 bits (corresponding to the mask defined by the constant@@ -584,38 +625,57 @@ cecilia #include <linux/seccomp.h> #include <sys/prctl.h> +#define X32_SYSCALL_BIT 0x40000000 + static int install_filter(int syscall_nr, int t_arch, int f_errno) { + int forbidden_bitmask = 0; + /* assume that AUDIT_ARCH_X86_64 means the normal X86-64 ABI */ + if (t_arch == AUDIT_ARCH_X86_64) + forbidden_bitmask = X32_SYSCALL_BIT; + struct sock_filter filter[] = { /* [0] Load architecture from 'seccomp_data' buffer into accumulator */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, arch))), - /* [1] Jump forward 4 instructions if architecture does not + /* [1] Jump forward 7 instructions if architecture does not match 't_arch' */ - BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 4), + BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 7), /* [2] Load system call number from 'seccomp_data' buffer into accumulator */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, nr))), - /* [3] Jump forward 1 instruction if system call number + /* [3] Determine ABI from system call number - only needed for X86-64 + in blacklist usecases */ + BPF_STMT(BPF_ALU | BPF_AND | BPF_K, forbidden_bitmask), + + /* [4] Check ABI - only needed for X86-64 in blacklist usecases */ + BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, 0, 0, 4), + + /* [5] Load system call number from 'seccomp_data' buffer into + accumulator */ + BPF_STMT(BPF_LD | BPF_W | BPF_ABS, + (offsetof(struct seccomp_data, nr))), + + /* [6] Jump forward 1 instruction if system call number does not match 'syscall_nr' */ BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, syscall_nr, 0, 1), - /* [4] Matching architecture and system call: don't execute + /* [7] Matching architecture and system call: don't execute the system call, and return 'f_errno' in 'errno' */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | (f_errno & SECCOMP_RET_DATA)), - /* [5] Destination of system call number mismatch: allow other + /* [8] Destination of system call number mismatch: allow other system calls */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), - /* [6] Destination of architecture mismatch: kill process */ + /* [9] Destination of architecture mismatch: kill process */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL), }; --2.1.4
Signature · 6 lines
Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Kees Cook
Quoted 7 lines · Jann Horn
Document some more-or-less surprising things about seccomp. I'm not sure whether changing the example code like that is a good idea - maybe that part of the patch should be left out?
Demo code for the X32 issue:
https://gist.github.com/thejh/c5b670a816bbb9791a6d
Quoted 7 lines
Quoted 3 lines
Demo code for full 64bit registers being visible in seccomp if the i386 ABI is used on a 64bit system:
https://gist.github.com/thejh/c37b27aefc44ab775db5So, it is probably worth noting the x32 ABI somewhere, and seccomp.2 is probably reasonable, though maybe it should be explicitly detailed in syscall.2?
I guess that would be sensible. However, I still think that the seccomp manpage should mention it, too, or advise the reader to also carefully read the syscall.2 manpage.
Quoted 4 lines
In the seccomp.2 manpage, though, I think we should discourage blacklisting, since whitelisting is a much more effective way to do attack surface reduction on syscalls. (And, as such, x32 would be already eliminated from x86-64 filters.)
I agree, whitelisting should be encouraged. However, as far as I can tell, people use seccomp not only for proper, strict sandboxing, but also to e.g. fix small security problems in containers or to provide additional precautions for them. In that case, I think that the use of a blacklist is more understandable, and various project use seccomp that way or at least support the use of blacklists: The default policy of LXC is a blacklist, sandstorm.io uses a seccomp blacklist and blacklists specific ptrace calls, systemd-nspawn uses a blacklist (although the manpage says that that's meant as a precaution against accidental damage, not as a security measure), systemd supports both whitelists and blacklists in the SystemCallFilter directive.
Quoted 4 lines
It is, however, reasonable to update the example just so it can be super-explicit, though I'd change the comments to say something more direct about the whitelisting vs blacklisting, like "While this example uses whitelisting,
You mean you would want to change the example to use whitelisting? That sounds like a good idea.
Quoted 4 lines
this is how an overlapping syscall ABI
could be tested." or something. Additionally, I think it would be better to test for >= instead of & to avoid having to reload the syscall nr.
Yes, sounds good.
Quoted 13 lines · Jann Horn
Quoted 12 lines · Kees Cook
Quoted 10 lines · Jann Horn
Document some more-or-less surprising things about seccomp. I'm not sure whether changing the example code like that is a good idea - maybe that part of the patch should be left out?
Demo code for the X32 issue:
https://gist.github.com/thejh/c5b670a816bbb9791a6dDemo code for full 64bit registers being visible in seccomp if the i386 ABI is used on a 64bit system:
https://gist.github.com/thejh/c37b27aefc44ab775db5
Quoted 7 lines
Quoted 3 lines
So, it is probably worth noting the x32 ABI somewhere, and seccomp.2 is probably reasonable, though maybe it should be explicitly detailed in syscall.2?
I guess that would be sensible. However, I still think that the seccomp manpage should mention it, too, or advise the reader to also carefully read the syscall.2 manpage.
Yeah, I think both should include it.
Quoted 21 lines
Quoted 6 lines
In the seccomp.2 manpage, though, I think we should discourage blacklisting, since whitelisting is a much more effective way to do attack surface reduction on syscalls. (And, as such, x32 would be already eliminated from x86-64 filters.)
I agree, whitelisting should be encouraged. However, as far as I can tell, people use seccomp not only for proper, strict sandboxing, but also to e.g. fix small security problems in containers or to provide additional precautions for them. In that case, I think that the use of a blacklist is more understandable, and various project use seccomp that way or at least support the use of blacklists: The default policy of LXC is a blacklist, sandstorm.io uses a seccomp blacklist and blacklists specific ptrace calls, systemd-nspawn uses a blacklist (although the manpage says that that's meant as a precaution against accidental damage, not as a security measure), systemd supports both whitelists and blacklists in the SystemCallFilter directive.
Quoted 7 lines
Quoted 4 lines
It is, however, reasonable to update the example just so it can be super-explicit, though I'd change the comments to say something more direct about the whitelisting vs blacklisting, like "While this example uses whitelisting,
You mean you would want to change the example to use whitelisting? That sounds like a good idea.
Oh man, I clearly didn't have enough coffee. Yeah, the example is blacklisting, isn't it? Let's leave that alone and just add the mask check, as you recommended. I still think it should avoid the AND so we don't have to reload the syscall nr, though.
Thanks!
-Kees
Quoted 8 lines
Quoted 6 lines
this is how an overlapping syscall ABI
could be tested." or something. Additionally, I think it would be better to test for >= instead of & to avoid having to reload the syscall nr.Yes, sounds good.
Signature · 6 lines
Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jann,
Thanks for working on this page. I'm a little unclear at this point. Am I correct to assume you are going to revise this patch in the light of Kees's comments and send a new patch?
Thanks,
Michael
Quoted 56 lines · Jann Horn
Quoted 8 lines · Kees Cook
Quoted 7 lines · Jann Horn
Document some more-or-less surprising things about seccomp. I'm not sure whether changing the example code like that is a good idea - maybe that part of the patch should be left out?
Demo code for the X32 issue:
https://gist.github.com/thejh/c5b670a816bbb9791a6dQuoted 7 lines
Quoted 3 lines
Demo code for full 64bit registers being visible in seccomp if the i386 ABI is used on a 64bit system:
https://gist.github.com/thejh/c37b27aefc44ab775db5So, it is probably worth noting the x32 ABI somewhere, and seccomp.2 is probably reasonable, though maybe it should be explicitly detailed in syscall.2?
I guess that would be sensible. However, I still think that the seccomp manpage should mention it, too, or advise the reader to also carefully read the syscall.2 manpage.
Quoted 4 lines
In the seccomp.2 manpage, though, I think we should discourage blacklisting, since whitelisting is a much more effective way to do attack surface reduction on syscalls. (And, as such, x32 would be already eliminated from x86-64 filters.)
I agree, whitelisting should be encouraged. However, as far as I can tell, people use seccomp not only for proper, strict sandboxing, but also to e.g. fix small security problems in containers or to provide additional precautions for them. In that case, I think that the use of a blacklist is more understandable, and various project use seccomp that way or at least support the use of blacklists: The default policy of LXC is a blacklist, sandstorm.io uses a seccomp blacklist and blacklists specific ptrace calls, systemd-nspawn uses a blacklist (although the manpage says that that's meant as a precaution against accidental damage, not as a security measure), systemd supports both whitelists and blacklists in the SystemCallFilter directive.
Quoted 4 lines
It is, however, reasonable to update the example just so it can be super-explicit, though I'd change the comments to say something more direct about the whitelisting vs blacklisting, like "While this example uses whitelisting,
You mean you would want to change the example to use whitelisting? That sounds like a good idea.
Quoted 4 lines
this is how an overlapping syscall ABI
could be tested." or something. Additionally, I think it would be better to test for >= instead of & to avoid having to reload the syscall nr.Yes, sounds good.
Signature · 3 lines
Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
PATCH v2 1/2 seccomp.2: Explain blacklisting problems, expand example
In reply to Jann Horn--- man2/seccomp.2 | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 67 insertions(+), 6 deletions(-)
man2/seccomp.2 +67 -6
@@ -250,6 +250,55 @@ struct seccomp_data { .fi .in +Because the numbers of system calls vary between architectures and +some architectures (e.g. X86-64) allow user-space code to use +the calling conventions of multiple architectures, it is usually +necessary to verify the value of the +.IR arch +field. + +It is strongly recommended to use a whitelisting approach whenever +possible because such an approach is more robust and simple. +A blacklist will have to be updated whenever a potentially +dangerous syscall is added (or a dangerous flag or option if those +are blacklisted), and it is often possible to alter the +representation of a value without altering its meaning, leading to +a blacklist bypass. + +The +.IR arch +field is not unique for all calling conventions. The X86-64 ABI and +the X32 ABI both use +.BR AUDIT_ARCH_X86_64 +as +.IR arch , +and they run on the same processors. Instead, the mask +.BR __X32_SYSCALL_BIT +is used on the system call number to tell the two ABIs apart. +This means that in order to create a seccomp-based +blacklist for system calls performed through the X86-64 ABI, +it is necessary to not only check that +.IR arch +equals +.BR AUDIT_ARCH_X86_64 , +but also to explicitly reject all syscalls that contain +.BR __X32_SYSCALL_BIT +in +.IR nr . + +When checking values from +.IR args +against a blacklist, keep in mind that arguments are often +silently truncated before being processed, but after the seccomp +check. For example, this happens if the i386 ABI is used on an +X86-64 kernel: Although the kernel will normally not look beyond +the 32 lowest bits of the arguments, the values of the full +64-bit registers will be present in the seccomp data. A less +surprising example is that if the X86-64 ABI is used to perform +a syscall that takes an argument of type int, the +more-significant half of the argument register is ignored by +the syscall, but visible in the seccomp data. + A seccomp filter returns a 32-bit value consisting of two parts: the most significant 16 bits (corresponding to the mask defined by the constant
@@ -616,38 +665,50 @@ cecilia #include <linux/seccomp.h> #include <sys/prctl.h> +#define X32_SYSCALL_BIT 0x40000000 + static int install_filter(int syscall_nr, int t_arch, int f_errno) { + unsigned int upper_nr_limit = 0xffffffff; + /* assume that AUDIT_ARCH_X86_64 means the normal X86-64 ABI */ + if (t_arch == AUDIT_ARCH_X86_64) + upper_nr_limit = X32_SYSCALL_BIT - 1; + struct sock_filter filter[] = { /* [0] Load architecture from 'seccomp_data' buffer into accumulator */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, arch))), - /* [1] Jump forward 4 instructions if architecture does not + /* [1] Jump forward 5 instructions if architecture does not match 't_arch' */ - BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 4), + BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 5), /* [2] Load system call number from 'seccomp_data' buffer into accumulator */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, nr))), - /* [3] Jump forward 1 instruction if system call number + /* [3] Check ABI - only needed for X86-64 in blacklist usecases. + Use JGT instead of checking against the bitmask to avoid + having to reload the syscall number. */ + BPF_JUMP(BPF_JMP | BPF_JGT | BPF_K, upper_nr_limit, 3, 0), + + /* [4] Jump forward 1 instruction if system call number does not match 'syscall_nr' */ BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, syscall_nr, 0, 1), - /* [4] Matching architecture and system call: don't execute + /* [5] Matching architecture and system call: don't execute the system call, and return 'f_errno' in 'errno' */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | (f_errno & SECCOMP_RET_DATA)), - /* [5] Destination of system call number mismatch: allow other + /* [6] Destination of system call number mismatch: allow other system calls */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), - /* [6] Destination of architecture mismatch: kill process */ + /* [7] Destination of architecture mismatch: kill process */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL), };
Signature · 7 lines
2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] seccomp.2: Explain blacklisting problems, expand example
Hi Jann,
Thanks for the patch. I've applied it.
Cheers,
Michael
Quoted 122 lines · Jann Horn
--- man2/seccomp.2 | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 67 insertions(+), 6 deletions(-)man2/seccomp.2 +67
-6@@ -250,6 +250,55 @@ struct seccomp_data { .fi .in +Because the numbers of system calls vary between architectures and +some architectures (e.g. X86-64) allow user-space code to use +the calling conventions of multiple architectures, it is usually +necessary to verify the value of the +.IR arch +field. + +It is strongly recommended to use a whitelisting approach whenever +possible because such an approach is more robust and simple. +A blacklist will have to be updated whenever a potentially +dangerous syscall is added (or a dangerous flag or option if those +are blacklisted), and it is often possible to alter the +representation of a value without altering its meaning, leading to +a blacklist bypass. + +The +.IR arch +field is not unique for all calling conventions. The X86-64 ABI and +the X32 ABI both use +.BR AUDIT_ARCH_X86_64 +as +.IR arch , +and they run on the same processors. Instead, the mask +.BR __X32_SYSCALL_BIT +is used on the system call number to tell the two ABIs apart. +This means that in order to create a seccomp-based +blacklist for system calls performed through the X86-64 ABI, +it is necessary to not only check that +.IR arch +equals +.BR AUDIT_ARCH_X86_64 , +but also to explicitly reject all syscalls that contain +.BR __X32_SYSCALL_BIT +in +.IR nr . + +When checking values from +.IR args +against a blacklist, keep in mind that arguments are often +silently truncated before being processed, but after the seccomp +check. For example, this happens if the i386 ABI is used on an +X86-64 kernel: Although the kernel will normally not look beyond +the 32 lowest bits of the arguments, the values of the full +64-bit registers will be present in the seccomp data. A less +surprising example is that if the X86-64 ABI is used to perform +a syscall that takes an argument of type int, the +more-significant half of the argument register is ignored by +the syscall, but visible in the seccomp data. + A seccomp filter returns a 32-bit value consisting of two parts: the most significant 16 bits (corresponding to the mask defined by the constant@@ -616,38 +665,50 @@ cecilia #include <linux/seccomp.h> #include <sys/prctl.h> +#define X32_SYSCALL_BIT 0x40000000 + static int install_filter(int syscall_nr, int t_arch, int f_errno) { + unsigned int upper_nr_limit = 0xffffffff; + /* assume that AUDIT_ARCH_X86_64 means the normal X86-64 ABI */ + if (t_arch == AUDIT_ARCH_X86_64) + upper_nr_limit = X32_SYSCALL_BIT - 1; + struct sock_filter filter[] = { /* [0] Load architecture from 'seccomp_data' buffer into accumulator */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, arch))), - /* [1] Jump forward 4 instructions if architecture does not + /* [1] Jump forward 5 instructions if architecture does not match 't_arch' */ - BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 4), + BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 5), /* [2] Load system call number from 'seccomp_data' buffer into accumulator */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, nr))), - /* [3] Jump forward 1 instruction if system call number + /* [3] Check ABI - only needed for X86-64 in blacklist usecases. + Use JGT instead of checking against the bitmask to avoid + having to reload the syscall number. */ + BPF_JUMP(BPF_JMP | BPF_JGT | BPF_K, upper_nr_limit, 3, 0), + + /* [4] Jump forward 1 instruction if system call number does not match 'syscall_nr' */ BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, syscall_nr, 0, 1), - /* [4] Matching architecture and system call: don't execute + /* [5] Matching architecture and system call: don't execute the system call, and return 'f_errno' in 'errno' */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | (f_errno & SECCOMP_RET_DATA)), - /* [5] Destination of system call number mismatch: allow other + /* [6] Destination of system call number mismatch: allow other system calls */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), - /* [6] Destination of architecture mismatch: kill process */ + /* [7] Destination of architecture mismatch: kill process */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL), };
Signature · 7 lines
Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v2 2/2 syscall.2: add x32 ABI
In reply to Jann Horn[added H. Peter Anvin to CC for this patch because he seems to have contributed large parts of the X32 code]
--- man2/syscall.2 | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
man2/syscall.2 +8 -1
@@ -170,12 +170,18 @@ s390 svc 0 r1 r2 See below s390x svc 0 r1 r2 See below sparc/32 t 0x10 g1 o0 sparc/64 t 0x6d g1 o0 -x86_64 syscall rax rax +x86_64 syscall rax rax See below +x32 syscall rax rax See below .TE .PP For s390 and s390x, NR (the system call number) may be passed directly with "svc NR" if it is less than 256. +The x32 ABI uses the same instruction as the x86_64 ABI and is used on +the same processors. To differentiate between them, the bitmask +.I __X32_SYSCALL_BIT +is bitwise-ORed into the syscall number for syscalls under the x32 ABI. + On a few architectures, a register is used to indicate simple boolean failure of the system call: ia64 uses
@@ -210,6 +216,7 @@ s390x r2 r3 r4 r5 r6 r7 - sparc/32 o0 o1 o2 o3 o4 o5 - sparc/64 o0 o1 o2 o3 o4 o5 - x86_64 rdi rsi rdx r10 r8 r9 - +x32 rdi rsi rdx r10 r8 r9 - .TE .PP The mips/o32 system call convention passes
Signature · 1 line
2.1.4
Re: [PATCH v2 2/2] syscall.2: add x32 ABI
Hi Jann,
Quoted 2 lines · Jann Horn
[added H. Peter Anvin to CC for this patch because he seems to have contributed large parts of the X32 code]
It looks like I did not reply to this mail. But as you'll probably have seen from the man-pages-3.83 release announcement, I did apply this patch. Thanks!
Cheers,
Michael
Quoted 39 lines
--- man2/syscall.2 | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)man2/syscall.2 +8
-2@@ -170,12 +170,18 @@ s390 svc 0 r1 r2 See below s390x svc 0 r1 r2 See below sparc/32 t 0x10 g1 o0 sparc/64 t 0x6d g1 o0 -x86_64 syscall rax rax +x86_64 syscall rax rax See below +x32 syscall rax rax See below .TE .PP For s390 and s390x, NR (the system call number) may be passed directly with "svc NR" if it is less than 256. +The x32 ABI uses the same instruction as the x86_64 ABI and is used on +the same processors. To differentiate between them, the bitmask +.I __X32_SYSCALL_BIT +is bitwise-ORed into the syscall number for syscalls under the x32 ABI. + On a few architectures, a register is used to indicate simple boolean failure of the system call: ia64 uses@@ -210,6 +216,7 @@ s390x r2 r3 r4 r5 r6 r7 - sparc/32 o0 o1 o2 o3 o4 o5 - sparc/64 o0 o1 o2 o3 o4 o5 - x86_64 rdi rsi rdx r10 r8 r9 - +x32 rdi rsi rdx r10 r8 r9 - .TE .PP The mips/o32 system call convention passes --2.1.4
Signature · 7 lines
Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html