1. 11 12月, 2014 1 次提交
  2. 28 10月, 2014 1 次提交
    • A
      bpf: split eBPF out of NET · f89b7755
      Alexei Starovoitov 提交于
      introduce two configs:
      - hidden CONFIG_BPF to select eBPF interpreter that classic socket filters
        depend on
      - visible CONFIG_BPF_SYSCALL (default off) that tracing and sockets can use
      
      that solves several problems:
      - tracing and others that wish to use eBPF don't need to depend on NET.
        They can use BPF_SYSCALL to allow loading from userspace or select BPF
        to use it directly from kernel in NET-less configs.
      - in 3.18 programs cannot be attached to events yet, so don't force it on
      - when the rest of eBPF infra is there in 3.19+, it's still useful to
        switch it off to minimize kernel size
      
      bloat-o-meter on x64 shows:
      add/remove: 0/60 grow/shrink: 0/2 up/down: 0/-15601 (-15601)
      
      tested with many different config combinations. Hopefully didn't miss anything.
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Acked-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f89b7755
  3. 09 8月, 2014 1 次提交
    • V
      bin2c: move bin2c in scripts/basic · 8370edea
      Vivek Goyal 提交于
      This patch series does not do kernel signature verification yet.  I plan
      to post another patch series for that.  Now distributions are already
      signing PE/COFF bzImage with PKCS7 signature I plan to parse and verify
      those signatures.
      
      Primary goal of this patchset is to prepare groundwork so that kernel
      image can be signed and signatures be verified during kexec load.  This
      should help with two things.
      
      - It should allow kexec/kdump on secureboot enabled machines.
      
      - In general it can help even without secureboot. By being able to verify
        kernel image signature in kexec, it should help with avoiding module
        signing restrictions. Matthew Garret showed how to boot into a custom
        kernel, modify first kernel's memory and then jump back to old kernel and
        bypass any policy one wants to.
      
      This patch (of 15):
      
      Kexec wants to use bin2c and it wants to use it really early in the build
      process. See arch/x86/purgatory/ code in later patches.
      
      So move bin2c in scripts/basic so that it can be built very early and
      be usable by arch/x86/purgatory/
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: WANG Chao <chaowang@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8370edea
  4. 24 7月, 2014 1 次提交
  5. 23 6月, 2014 1 次提交
  6. 24 2月, 2014 1 次提交
  7. 14 2月, 2014 1 次提交
  8. 11 2月, 2014 1 次提交
  9. 13 12月, 2013 2 次提交
    • K
      KEYS: Remove files generated when SYSTEM_TRUSTED_KEYRING=y · f46a3cbb
      Kirill Tkhai 提交于
      Always remove generated SYSTEM_TRUSTED_KEYRING files while doing make mrproper.
      Signed-off-by: NKirill Tkhai <tkhai@yandex.ru>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f46a3cbb
    • D
      X.509: Fix certificate gathering · d7ec435f
      David Howells 提交于
      Fix the gathering of certificates from both the source tree and the build tree
      to correctly calculate the pathnames of all the certificates.
      
      The problem was that if the default generated cert, signing_key.x509, didn't
      exist then it would not have a path attached and if it did, it would have a
      path attached.
      
      This means that the contents of kernel/.x509.list would change between the
      first compilation in a directory and the second.  After the second it would
      remain stable because the signing_key.x509 file exists.
      
      The consequence was that the kernel would get relinked unconditionally on the
      second recompilation.  The second recompilation would also show something like
      this:
      
         X.509 certificate list changed
           CERTS   kernel/x509_certificate_list
           - Including cert /home/torvalds/v2.6/linux/signing_key.x509
           AS      kernel/system_certificates.o
           LD      kernel/built-in.o
      
      which is why the relink would happen.
      
      
      Unfortunately, it isn't a simple matter of just sticking a path on the front
      of the filename of the certificate in the build directory as make can't then
      work out how to build it.
      
      So the path has to be prepended to the name for sorting and duplicate
      elimination and then removed for the make rule if it is in the build tree.
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      d7ec435f
  10. 06 11月, 2013 8 次提交
  11. 16 10月, 2013 1 次提交
  12. 26 9月, 2013 3 次提交
  13. 13 9月, 2013 1 次提交
  14. 01 8月, 2013 1 次提交
  15. 10 7月, 2013 1 次提交
  16. 11 4月, 2013 1 次提交
    • D
      MODSIGN: do not send garbage to stderr when enabling modules signature · 07c449bb
      David Cohen 提交于
      When compiling kernel with -jN (N > 1), all warning/error messages
      printed while openssl is generating key pair may get mixed dots and
      other symbols openssl sends to stderr. This patch makes sure openssl
      logs go to default stdout.
      
      Example of the garbage on stderr:
      
      crypto/anubis.c:581: warning: ‘inter’ is used uninitialized in this function
      Generating a 4096 bit RSA private key
      .........
      drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen6_ggtt_insert_entries’:
      drivers/gpu/drm/i915/i915_gem_gtt.c:440: warning: ‘addr’ may be used uninitialized in this function
      .net/mac80211/tx.c: In function ‘ieee80211_subif_start_xmit’:
      net/mac80211/tx.c:1780: warning: ‘chanctx_conf’ may be used uninitialized in this function
      ..drivers/isdn/hardware/mISDN/hfcpci.c: In function ‘hfcpci_softirq’:
      .....drivers/isdn/hardware/mISDN/hfcpci.c:2298: warning: ignoring return value of ‘driver_for_each_device’, declared with attribute warn_unused_result
      Signed-off-by: NDavid Cohen <david.a.cohen@intel.com>
      Reviewed-by: Nmark gross <mark.gross@intel.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      07c449bb
  17. 08 4月, 2013 1 次提交
  18. 28 2月, 2013 2 次提交
  19. 17 2月, 2013 1 次提交
    • H
      kernel: Replace timeconst.pl with a bc script · 70730bca
      H. Peter Anvin 提交于
      bc is the standard tool for multi-precision arithmetic.  We switched
      to Perl because akpm reported a hard-to-reproduce build hang, which
      was very odd because affected and unaffected machines were all running
      the same version of GNU bc.
      
      Unfortunately switching to Perl required a really ugly "canning"
      mechanism to support Perl < 5.8 installations lacking the Math::BigInt
      module.
      
      It was recently pointed out to me that some very old versions of GNU
      make had problems with pipes in subshells, which was indeed the
      construct used in the Makefile rules in that version of the patch;
      Perl didn't need it so switching to Perl fixed the problem for
      unrelated reasons.  With the problem (hopefully) root-caused, we can
      switch back to bc and do the arbitrary-precision arithmetic naturally.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      70730bca
  20. 25 1月, 2013 1 次提交
  21. 14 12月, 2012 2 次提交
  22. 01 12月, 2012 1 次提交
    • F
      context_tracking: New context tracking susbsystem · 91d1aa43
      Frederic Weisbecker 提交于
      Create a new subsystem that probes on kernel boundaries
      to keep track of the transitions between level contexts
      with two basic initial contexts: user or kernel.
      
      This is an abstraction of some RCU code that use such tracking
      to implement its userspace extended quiescent state.
      
      We need to pull this up from RCU into this new level of indirection
      because this tracking is also going to be used to implement an "on
      demand" generic virtual cputime accounting. A necessary step to
      shutdown the tick while still accounting the cputime.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Gilad Ben-Yossef <gilad@benyossef.com>
      Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
      [ paulmck: fix whitespace error and email address. ]
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      91d1aa43
  23. 26 10月, 2012 1 次提交
    • H
      Makefile: Documentation for external tool should be correct · 2008713c
      H. Peter Anvin 提交于
      If one includes documentation for an external tool, it should be
      correct.  This is not:
      
      1. Overriding the input to rngd should typically be neither
         necessary nor desired.  This is especially so since newer
         versions of rngd support a number of different *types* of sources.
      2. The default kernel-exported device is called /dev/hwrng not
         /dev/hwrandom nor /dev/hw_random (both of which were used in the
         past; however, kernel and udev seem to have converged on
         /dev/hwrng.)
      
      Overall it is better if the documentation for rngd is kept with rngd
      rather than in a kernel Makefile.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Garzik <jgarzik@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2008713c
  24. 10 10月, 2012 5 次提交
    • R
      MODSIGN: Make mrproper should remove generated files. · d5b71936
      Rusty Russell 提交于
      It doesn't, because the clean targets don't include kernel/Makefile, and
      because two files were missing from the list.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      d5b71936
    • D
      MODSIGN: Use utf8 strings in signer's name in autogenerated X.509 certs · e7d113bc
      David Howells 提交于
      Place an indication that the certificate should use utf8 strings into the
      x509.genkey template generated by kernel/Makefile.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      e7d113bc
    • D
      MODSIGN: Use the same digest for the autogen key sig as for the module sig · 5e8cb1e4
      David Howells 提交于
      Use the same digest type for the autogenerated key signature as for the module
      signature so that the hash algorithm is guaranteed to be present in the kernel.
      
      Without this, the X.509 certificate loader may reject the X.509 certificate so
      generated because it was self-signed and the signature will be checked against
      itself - but this won't work if the digest algorithm must be loaded as a
      module.
      
      The symptom is that the key fails to load with the following message emitted
      into the kernel log:
      
      	MODSIGN: Problem loading in-kernel X.509 certificate (-65)
      
      the error in brackets being -ENOPKG.  What you should see is something like:
      
      	MODSIGN: Loaded cert 'Magarathea: Glacier signing key: 9588321144239a119d3406d4c4cf1fbae1836fa0'
      
      Note that this doesn't apply to certificates that are not self-signed as we
      don't check those currently as they require the parent CA certificate to be
      available.
      Reported-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      5e8cb1e4
    • D
      MODSIGN: Provide module signing public keys to the kernel · 631cc66e
      David Howells 提交于
      Include a PGP keyring containing the public keys required to perform module
      verification in the kernel image during build and create a special keyring
      during boot which is then populated with keys of crypto type holding the public
      keys found in the PGP keyring.
      
      These can be seen by root:
      
      [root@andromeda ~]# cat /proc/keys
      07ad4ee0 I-----     1 perm 3f010000     0     0 crypto    modsign.0: RSA 87b9b3bd []
      15c7f8c3 I-----     1 perm 1f030000     0     0 keyring   .module_sign: 1/4
      ...
      
      It is probably worth permitting root to invalidate these keys, resulting in
      their removal and preventing further modules from being loaded with that key.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      631cc66e
    • D
      MODSIGN: Automatically generate module signing keys if missing · d441108c
      David Howells 提交于
      Automatically generate keys for module signing if they're absent so that
      allyesconfig doesn't break.  The builder should consider generating their own
      key and certificate, however, so that the keys are appropriately named.
      
      The private key for the module signer should be placed in signing_key.priv
      (unencrypted!) and the public key in an X.509 certificate as signing_key.x509.
      
      If a transient key is desired for signing the modules, a config file for
      'openssl req' can be placed in x509.genkey, looking something like the
      following:
      
      	[ req ]
      	default_bits = 4096
      	distinguished_name = req_distinguished_name
      	prompt = no
      	x509_extensions = myexts
      
      	[ req_distinguished_name ]
      	O = Magarathea
      	CN = Glacier signing key
      	emailAddress = slartibartfast@magrathea.h2g2
      
      	[ myexts ]
      	basicConstraints=critical,CA:FALSE
      	keyUsage=digitalSignature
      	subjectKeyIdentifier=hash
      	authorityKeyIdentifier=hash
      
      The build process will use this to configure:
      
      	openssl req -new -nodes -utf8 -sha1 -days 36500 -batch \
      		-x509 -config x509.genkey \
      		-outform DER -out signing_key.x509 \
      		-keyout signing_key.priv
      
      to generate the key.
      
      Note that it is required that the X.509 certificate have a subjectKeyIdentifier
      and an authorityKeyIdentifier.  Without those, the certificate will be
      rejected.  These can be used to check the validity of a certificate.
      
      Note that 'make distclean' will remove signing_key.{priv,x509} and x509.genkey,
      whether or not they were generated automatically.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      d441108c