1. 22 May, 2018 4 commits
  2. 25 Dec, 2017 1 commit
  3. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  4. 10 Oct, 2017 1 commit
  5. 28 Sep, 2017 1 commit
  6. 14 Aug, 2017 9 commits
    • Kees Cook's avatar
      seccomp: Implement SECCOMP_RET_KILL_PROCESS action · 0466bdb9
      Kees Cook authored
      Right now, SECCOMP_RET_KILL_THREAD (neé SECCOMP_RET_KILL) kills the
      current thread. There have been a few requests for this to kill the entire
      process (the thread group). This cannot be just changed (discovered when
      adding coredump support since coredumping kills the entire process)
      because there are userspace programs depending on the thread-kill
      behavior.
      
      Instead, implement SECCOMP_RET_KILL_PROCESS, which is 0x80000000, and can
      be processed as "-1" by the kernel, below the existing RET_KILL that is
      ABI-set to "0". For userspace, SECCOMP_RET_ACTION_FULL is added to expand
      the mask to the signed bit. Old userspace using the SECCOMP_RET_ACTION
      mask will see SECCOMP_RET_KILL_PROCESS as 0 still, but this would only
      be visible when examining the siginfo in a core dump from a RET_KILL_*,
      where it will think it was thread-killed instead of process-killed.
      
      Attempts to introduce this behavior via other ways (filter flags,
      seccomp struct flags, masked RET_DATA bits) all come with weird
      side-effects and baggage. This change preserves the central behavioral
      expectations of the seccomp filter engine without putting too great
      a burden on changes needed in userspace to use the new action.
      
      The new action is discoverable by userspace through either the new
      actions_avail sysctl or through the SECCOMP_GET_ACTION_AVAIL seccomp
      operation. If used without checking for availability, old kernels
      will treat RET_KILL_PROCESS as RET_KILL_THREAD (since the old mask
      will produce RET_KILL_THREAD).
      
      Cc: Paul Moore <paul@paul-moore.com>
      Cc: Fabricio Voznika <fvoznika@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      0466bdb9
    • Kees Cook's avatar
      seccomp: Introduce SECCOMP_RET_KILL_PROCESS · 4d3b0b05
      Kees Cook authored
      This introduces the BPF return value for SECCOMP_RET_KILL_PROCESS to kill
      an entire process. This cannot yet be reached by seccomp, but it changes
      the default-kill behavior (for unknown return values) from kill-thread to
      kill-process.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      4d3b0b05
    • Kees Cook's avatar
      seccomp: Rename SECCOMP_RET_KILL to SECCOMP_RET_KILL_THREAD · fd76875c
      Kees Cook authored
      In preparation for adding SECCOMP_RET_KILL_PROCESS, rename SECCOMP_RET_KILL
      to the more accurate SECCOMP_RET_KILL_THREAD.
      
      The existing selftest values are intentionally left as SECCOMP_RET_KILL
      just to be sure we're exercising the alias.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      fd76875c
    • Tyler Hicks's avatar
      seccomp: Action to log before allowing · 59f5cf44
      Tyler Hicks authored
      Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing
      the syscall. At the implementation level, this action is identical to
      the existing SECCOMP_RET_ALLOW action. However, it can be very useful when
      initially developing a seccomp filter for an application. The developer
      can set the default action to be SECCOMP_RET_LOG, maybe mark any
      obviously needed syscalls with SECCOMP_RET_ALLOW, and then put the
      application through its paces. A list of syscalls that triggered the
      default action (SECCOMP_RET_LOG) can be easily gleaned from the logs and
      that list can be used to build the syscall whitelist. Finally, the
      developer can change the default action to the desired value.
      
      This provides a more friendly experience than seeing the application get
      killed, then updating the filter and rebuilding the app, seeing the
      application get killed due to a different syscall, then updating the
      filter and rebuilding the app, etc.
      
      The functionality is similar to what's supported by the various LSMs.
      SELinux has permissive mode, AppArmor has complain mode, SMACK has
      bring-up mode, etc.
      
      SECCOMP_RET_LOG is given a lower value than SECCOMP_RET_ALLOW as allow
      while logging is slightly more restrictive than quietly allowing.
      
      Unfortunately, the tests added for SECCOMP_RET_LOG are not capable of
      inspecting the audit log to verify that the syscall was logged.
      
      With this patch, the logic for deciding if an action will be logged is:
      
      if action == RET_ALLOW:
        do not log
      else if action == RET_KILL && RET_KILL in actions_logged:
        log
      else if action == RET_LOG && RET_LOG in actions_logged:
        log
      else if filter-requests-logging && action in actions_logged:
        log
      else if audit_enabled && process-is-being-audited:
        log
      else:
        do not log
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      59f5cf44
    • Tyler Hicks's avatar
      seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW · e66a3997
      Tyler Hicks authored
      Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for
      all actions except for SECCOMP_RET_ALLOW for the given filter.
      
      SECCOMP_RET_KILL actions are always logged, when "kill" is in the
      actions_logged sysctl, and SECCOMP_RET_ALLOW actions are never logged,
      regardless of this flag.
      
      This flag can be used to create noisy filters that result in all
      non-allowed actions to be logged. A process may have one noisy filter,
      which is loaded with this flag, as well as a quiet filter that's not
      loaded with this flag. This allows for the actions in a set of filters
      to be selectively conveyed to the admin.
      
      Since a system could have a large number of allocated seccomp_filter
      structs, struct packing was taken in consideration. On 64 bit x86, the
      new log member takes up one byte of an existing four byte hole in the
      struct. On 32 bit x86, the new log member creates a new four byte hole
      (unavoidable) and consumes one of those bytes.
      
      Unfortunately, the tests added for SECCOMP_FILTER_FLAG_LOG are not
      capable of inspecting the audit log to verify that the actions taken in
      the filter were logged.
      
      With this patch, the logic for deciding if an action will be logged is:
      
      if action == RET_ALLOW:
        do not log
      else if action == RET_KILL && RET_KILL in actions_logged:
        log
      else if filter-requests-logging && action in actions_logged:
        log
      else if audit_enabled && process-is-being-audited:
        log
      else:
        do not log
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      e66a3997
    • Tyler Hicks's avatar
      seccomp: Sysctl to configure actions that are allowed to be logged · 0ddec0fc
      Tyler Hicks authored
      Adminstrators can write to this sysctl to set the seccomp actions that
      are allowed to be logged. Any actions not found in this sysctl will not
      be logged.
      
      For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and
      SECCOMP_RET_ERRNO actions would be loggable if "kill trap errno" were
      written to the sysctl. SECCOMP_RET_TRACE actions would not be logged
      since its string representation ("trace") wasn't present in the sysctl
      value.
      
      The path to the sysctl is:
      
       /proc/sys/kernel/seccomp/actions_logged
      
      The actions_avail sysctl can be read to discover the valid action names
      that can be written to the actions_logged sysctl with the exception of
      "allow". SECCOMP_RET_ALLOW actions cannot be configured for logging.
      
      The default setting for the sysctl is to allow all actions to be logged
      except SECCOMP_RET_ALLOW. While only SECCOMP_RET_KILL actions are
      currently logged, an upcoming patch will allow applications to request
      additional actions to be logged.
      
      There's one important exception to this sysctl. If a task is
      specifically being audited, meaning that an audit context has been
      allocated for the task, seccomp will log all actions other than
      SECCOMP_RET_ALLOW despite the value of actions_logged. This exception
      preserves the existing auditing behavior of tasks with an allocated
      audit context.
      
      With this patch, the logic for deciding if an action will be logged is:
      
      if action == RET_ALLOW:
        do not log
      else if action == RET_KILL && RET_KILL in actions_logged:
        log
      else if audit_enabled && task-is-being-audited:
        log
      else:
        do not log
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      0ddec0fc
    • Tyler Hicks's avatar
      seccomp: Operation for checking if an action is available · d612b1fd
      Tyler Hicks authored
      Userspace code that needs to check if the kernel supports a given action
      may not be able to use the /proc/sys/kernel/seccomp/actions_avail
      sysctl. The process may be running in a sandbox and, therefore,
      sufficient filesystem access may not be available. This patch adds an
      operation to the seccomp(2) syscall that allows userspace code to ask
      the kernel if a given action is available.
      
      If the action is supported by the kernel, 0 is returned. If the action
      is not supported by the kernel, -1 is returned with errno set to
      -EOPNOTSUPP. If this check is attempted on a kernel that doesn't support
      this new operation, -1 is returned with errno set to -EINVAL meaning
      that userspace code will have the ability to differentiate between the
      two error cases.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Suggested-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      d612b1fd
    • Tyler Hicks's avatar
      seccomp: Sysctl to display available actions · 8e5f1ad1
      Tyler Hicks authored
      This patch creates a read-only sysctl containing an ordered list of
      seccomp actions that the kernel supports. The ordering, from left to
      right, is the lowest action value (kill) to the highest action value
      (allow). Currently, a read of the sysctl file would return "kill trap
      errno trace allow". The contents of this sysctl file can be useful for
      userspace code as well as the system administrator.
      
      The path to the sysctl is:
      
        /proc/sys/kernel/seccomp/actions_avail
      
      libseccomp and other userspace code can easily determine which actions
      the current kernel supports. The set of actions supported by the current
      kernel may be different than the set of action macros found in kernel
      headers that were installed where the userspace code was built.
      
      In addition, this sysctl will allow system administrators to know which
      actions are supported by the kernel and make it easier to configure
      exactly what seccomp logs through the audit subsystem. Support for this
      level of logging configuration will come in a future patch.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      8e5f1ad1
    • Kees Cook's avatar
      seccomp: Provide matching filter for introspection · deb4de8b
      Kees Cook authored
      Both the upcoming logging improvements and changes to RET_KILL will need
      to know which filter a given seccomp return value originated from. In
      order to delay logic processing of result until after the seccomp loop,
      this adds a single pointer assignment on matches. This will allow both
      log and RET_KILL logic to work off the filter rather than doing more
      expensive tests inside the time-critical run_filters loop.
      
      Running tight cycles of getpid() with filters attached shows no measurable
      difference in speed.
      Suggested-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
      deb4de8b
  7. 26 Jun, 2017 2 commits
  8. 02 Mar, 2017 1 commit
  9. 22 Feb, 2017 1 commit
  10. 23 Jan, 2017 1 commit
    • Mike Frysinger's avatar
      seccomp: dump core when using SECCOMP_RET_KILL · b25e6716
      Mike Frysinger authored
      The SECCOMP_RET_KILL mode is documented as immediately killing the
      process as if a SIGSYS had been sent and not caught (similar to a
      SIGKILL).  However, a SIGSYS is documented as triggering a coredump
      which does not happen today.
      
      This has the advantage of being able to more easily debug a process
      that fails a seccomp filter.  Today, most apps need to recompile and
      change their filter in order to get detailed info out, or manually run
      things through strace, or enable detailed kernel auditing.  Now we get
      coredumps that fit into existing system-wide crash reporting setups.
      
      From a security pov, this shouldn't be a problem.  Unhandled signals
      can already be sent externally which trigger a coredump independent of
      the status of the seccomp filter.  The act of dumping core itself does
      not cause change in execution of the program.
      
      URL: https://crbug.com/676357Signed-off-by: default avatarMike Frysinger <vapier@chromium.org>
      Acked-by: default avatarJorge Lucangeli Obes <jorgelo@chromium.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      b25e6716
  11. 28 Nov, 2016 1 commit
  12. 01 Nov, 2016 1 commit
  13. 30 Aug, 2016 1 commit
  14. 04 Aug, 2016 1 commit
    • Masahiro Yamada's avatar
      tree-wide: replace config_enabled() with IS_ENABLED() · 97f2645f
      Masahiro Yamada authored
      The use of config_enabled() against config options is ambiguous.  In
      practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the
      author might have used it for the meaning of IS_ENABLED().  Using
      IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc.  makes the intention
      clearer.
      
      This commit replaces config_enabled() with IS_ENABLED() where possible.
      This commit is only touching bool config options.
      
      I noticed two cases where config_enabled() is used against a tristate
      option:
      
       - config_enabled(CONFIG_HWMON)
        [ drivers/net/wireless/ath/ath10k/thermal.c ]
      
       - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
        [ drivers/gpu/drm/gma500/opregion.c ]
      
      I did not touch them because they should be converted to IS_BUILTIN()
      in order to keep the logic, but I was not sure it was the authors'
      intention.
      
      Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Stas Sergeev <stsp@list.ru>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: "Dmitry V. Levin" <ldv@altlinux.org>
      Cc: yu-cheng yu <yu-cheng.yu@intel.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Nikolay Martynov <mar.kolya@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Rafal Milecki <zajec5@gmail.com>
      Cc: James Cowgill <James.Cowgill@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Alex Smith <alex.smith@imgtec.com>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Tony Wu <tung7970@gmail.com>
      Cc: Huaitong Han <huaitong.han@intel.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andrea Gelmini <andrea.gelmini@gelma.net>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Rabin Vincent <rabin@rab.in>
      Cc: "Maciej W. Rozycki" <macro@imgtec.com>
      Cc: David Daney <david.daney@cavium.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      97f2645f
  15. 14 Jun, 2016 3 commits
  16. 13 May, 2016 2 commits
  17. 04 May, 2016 1 commit
  18. 22 Mar, 2016 1 commit
  19. 27 Jan, 2016 1 commit
  20. 28 Oct, 2015 1 commit
    • Tycho Andersen's avatar
      seccomp, ptrace: add support for dumping seccomp filters · f8e529ed
      Tycho Andersen authored
      This patch adds support for dumping a process' (classic BPF) seccomp
      filters via ptrace.
      
      PTRACE_SECCOMP_GET_FILTER allows the tracer to dump the user's classic BPF
      seccomp filters. addr should be an integer which represents the ith seccomp
      filter (0 is the most recently installed filter). data should be a struct
      sock_filter * with enough room for the ith filter, or NULL, in which case
      the filter is not saved. The return value for this command is the number of
      BPF instructions the program represents, or negative in the case of errors.
      Command specific errors are ENOENT: which indicates that there is no ith
      filter in this seccomp tree, and EMEDIUMTYPE, which indicates that the ith
      filter was not installed as a classic BPF filter.
      
      A caveat with this approach is that there is no way to get explicitly at
      the heirarchy of seccomp filters, and users need to memcmp() filters to
      decide which are inherited. This means that a task which installs two of
      the same filter can potentially confuse users of this interface.
      
      v2: * make save_orig const
          * check that the orig_prog exists (not necessary right now, but when
             grows eBPF support it will be)
          * s/n/filter_off and 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
      
      v4: * don't copy to userspace while holding spinlocks
      
      v5: * add another condition to WARN_ON
      
      v6: * rebase on net-next
      Signed-off-by: default avatarTycho Andersen <tycho.andersen@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      CC: Will Drewry <wad@chromium.org>
      Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
      CC: Andy Lutomirski <luto@amacapital.net>
      CC: Pavel Emelyanov <xemul@parallels.com>
      CC: Serge E. Hallyn <serge.hallyn@ubuntu.com>
      CC: Alexei Starovoitov <ast@kernel.org>
      CC: Daniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f8e529ed
  21. 05 Oct, 2015 1 commit
    • Daniel Borkmann's avatar
      bpf, seccomp: prepare for upcoming criu support · bab18991
      Daniel Borkmann authored
      The current ongoing effort to dump existing cBPF seccomp filters back
      to user space requires to hold the pre-transformed instructions like
      we do in case of socket filters from sk_attach_filter() side, so they
      can be reloaded in original form at a later point in time by utilities
      such as criu.
      
      To prepare for this, simply extend the bpf_prog_create_from_user()
      API to hold a flag that tells whether we should store the original
      or not. Also, fanout filters could make use of that in future for
      things like diag. While fanout filters already use bpf_prog_destroy(),
      move seccomp over to them as well to handle original programs when
      present.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Tycho Andersen <tycho.andersen@canonical.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Tested-by: default avatarTycho Andersen <tycho.andersen@canonical.com>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bab18991
  22. 15 Jul, 2015 3 commits
    • Kees Cook's avatar
      seccomp: swap hard-coded zeros to defined name · 221272f9
      Kees Cook authored
      For clarity, if CONFIG_SECCOMP isn't defined, seccomp_mode() is returning
      "disabled". This makes that more clear, along with another 0-use, and
      results in no operational change.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      221272f9
    • Tycho Andersen's avatar
      seccomp: add ptrace options for suspend/resume · 13c4a901
      Tycho Andersen authored
      This patch is the first step in enabling checkpoint/restore of processes
      with seccomp enabled.
      
      One of the things CRIU does while dumping tasks is inject code into them
      via ptrace to collect information that is only available to the process
      itself. However, if we are in a seccomp mode where these processes are
      prohibited from making these syscalls, then what CRIU does kills the task.
      
      This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
      a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
      filters to disable (and re-enable) seccomp filters for another task so that
      they can be successfully dumped (and restored). We restrict the set of
      processes that can disable seccomp through ptrace because although today
      ptrace can be used to bypass seccomp, there is some discussion of closing
      this loophole in the future and we would like this patch to not depend on
      that behavior and be future proofed for when it is removed.
      
      Note that seccomp can be suspended before any filters are actually
      installed; this behavior is useful on criu restore, so that we can suspend
      seccomp, restore the filters, unmap our restore code from the restored
      process' address space, and then resume the task by detaching and have the
      filters resumed as well.
      
      v2 changes:
      
      * require that the tracer have no seccomp filters installed
      * drop TIF_NOTSC manipulation from the patch
      * change from ptrace command to a ptrace option and use this ptrace option
        as the flag to check. This means that as soon as the tracer
        detaches/dies, seccomp is re-enabled and as a corrollary that one can not
        disable seccomp across PTRACE_ATTACHs.
      
      v3 changes:
      
      * get rid of various #ifdefs everywhere
      * report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
        used
      
      v4 changes:
      
      * get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
        directly
      
      v5 changes:
      
      * check that seccomp is not enabled (or suspended) on the tracer
      Signed-off-by: default avatarTycho Andersen <tycho.andersen@canonical.com>
      CC: Will Drewry <wad@chromium.org>
      CC: Roland McGrath <roland@hack.frob.com>
      CC: Pavel Emelyanov <xemul@parallels.com>
      CC: Serge E. Hallyn <serge.hallyn@ubuntu.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      [kees: access seccomp.mode through seccomp_mode() instead]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      13c4a901
    • Pranith Kumar's avatar
      seccomp: Replace smp_read_barrier_depends() with lockless_dereference() · 8225d385
      Pranith Kumar authored
      Recently lockless_dereference() was added which can be used in place of
      hard-coding smp_read_barrier_depends(). The following PATCH makes the change.
      Signed-off-by: default avatarPranith Kumar <bobby.prani@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      8225d385
  23. 09 May, 2015 1 commit
    • Daniel Borkmann's avatar
      seccomp, filter: add and use bpf_prog_create_from_user from seccomp · ac67eb2c
      Daniel Borkmann authored
      Seccomp has always been a special candidate when it comes to preparation
      of its filters in seccomp_prepare_filter(). Due to the extra checks and
      filter rewrite it partially duplicates code and has BPF internals exposed.
      
      This patch adds a generic API inside the BPF code code that seccomp can use
      and thus keep it's filter preparation code minimal and better maintainable.
      The other side-effect is that now classic JITs can add seccomp support as
      well by only providing a BPF_LDX | BPF_W | BPF_ABS translation.
      
      Tested with seccomp and BPF test suites.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Nicolas Schichan <nschichan@freebox.fr>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Kees Cook <keescook@chromium.org>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac67eb2c