Commit Graph

25 Commits

Author SHA1 Message Date
David Woodhouse 770f2b9876 modsign: Use extract-cert to process CONFIG_SYSTEM_TRUSTED_KEYS
Fix up the dependencies somewhat too, while we're at it.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: David Howells <dhowells@redhat.com>
2015-08-12 17:01:01 +01:00
David Woodhouse 1329e8cc69 modsign: Extract signing cert from CONFIG_MODULE_SIG_KEY if needed
Where an external PEM file or PKCS#11 URI is given, we can get the cert
from it for ourselves instead of making the user drop signing_key.x509
in place for us.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: David Howells <dhowells@redhat.com>
2015-08-07 16:26:14 +01:00
David Howells 3f1e1bea34 MODSIGN: Use PKCS#7 messages as module signatures
Move to using PKCS#7 messages as module signatures because:

 (1) We have to be able to support the use of X.509 certificates that don't
     have a subjKeyId set.  We're currently relying on this to look up the
     X.509 certificate in the trusted keyring list.

 (2) PKCS#7 message signed information blocks have a field that supplies the
     data required to match with the X.509 certificate that signed it.

 (3) The PKCS#7 certificate carries fields that specify the digest algorithm
     used to generate the signature in a standardised way and the X.509
     certificates specify the public key algorithm in a standardised way - so
     we don't need our own methods of specifying these.

 (4) We now have PKCS#7 message support in the kernel for signed kexec purposes
     and we can make use of this.

To make this work, the old sign-file script has been replaced with a program
that needs compiling in a previous patch.  The rules to build it are added
here.

Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Vivek Goyal <vgoyal@redhat.com>
2015-08-07 16:26:13 +01:00
Jan Kiszka 3ee7b3fa2c scripts/gdb: add infrastructure
This provides the basic infrastructure to load kernel-specific python
helper scripts when debugging the kernel in gdb.

The loading mechanism is based on gdb loading for <objfile>-gdb.py when
opening <objfile>.  Therefore, this places a corresponding link to the
main helper script into the output directory that contains vmlinux.

The main scripts will pull in submodules containing Linux specific gdb
commands and functions.  To avoid polluting the source directory with
compiled python modules, we link to them from the object directory.

Due to gdb.parse_and_eval and string redirection for gdb.execute, we
depend on gdb >= 7.2.

This feature is enabled via CONFIG_GDB_SCRIPTS.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Michal Marek <mmarek@suse.cz>		[kbuild stuff]
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-02-17 14:34:53 -08:00
Vivek Goyal 8370edea81 bin2c: move bin2c in scripts/basic
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: Vivek 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-08-08 15:57:32 -07:00
Masahiro Yamada c43cecadb0 kbuild: do not add "selinux" to subdir- twice
scripts/Makefile adds "selinux" to subdir-y or subdir- twice.

  subdir-$(CONFIG_MODVERSIONS) += genksyms
  subdir-y                     += mod
  subdir-$(CONFIG_SECURITY_SELINUX) += selinux    <--- here
  subdir-$(CONFIG_DTC)         += dtc

  # Let clean descend into subdirs
  subdir- += basic kconfig package selinux        <--- again

The latter is redundant.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2014-06-09 23:24:59 +02:00
Masahiro Yamada bfdfaeae50 kbuild: specify build_docproc as a phony target
PHONY target is more suitable for "build_docproc" target.

Because PHONY targets are always executed, they do not
have to take FORCE as a prerequisite.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2014-03-14 17:44:17 +01:00
David Howells 4520c6a49a X.509: Add simple ASN.1 grammar compiler
Add a simple ASN.1 grammar compiler.  This produces a bytecode output that can
be fed to a decoder to inform the decoder how to interpret the ASN.1 stream it
is trying to parse.

Action functions can be specified in the grammar by interpolating:

	({ foo })

after a type, for example:

	SubjectPublicKeyInfo ::= SEQUENCE {
		algorithm		AlgorithmIdentifier,
		subjectPublicKey	BIT STRING ({ do_key_data })
		}

The decoder is expected to call these after matching this type and parsing the
contents if it is a constructed type.

The grammar compiler does not currently support the SET type (though it does
support SET OF) as I can't see a good way of tracking which members have been
encountered yet without using up extra stack space.

Currently, the grammar compiler will fail if more than 256 bytes of bytecode
would be produced or more than 256 actions have been specified as it uses
8-bit jump values and action indices to keep space usage down.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-10-08 13:50:19 +10:30
Linus Torvalds 269af9a1a0 Merge branch 'x86-extable-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull exception table generation updates from Ingo Molnar:
 "The biggest change here is to allow the build-time sorting of the
  exception table, to speed up booting.  This is achieved by the
  architecture enabling BUILDTIME_EXTABLE_SORT.  This option is enabled
  for x86 and MIPS currently.

  On x86 a number of fixes and changes were needed to allow build-time
  sorting of the exception table, in particular a relocation invariant
  exception table format was needed.  This required the abstracting out
  of exception table protocol and the removal of 20 years of accumulated
  assumptions about the x86 exception table format.

  While at it, this tree also cleans up various other aspects of
  exception handling, such as early(er) exception handling for
  rdmsr_safe() et al.

  All in one, as the result of these changes the x86 exception code is
  now pretty nice and modern.  As an added bonus any regressions in this
  code will be early and violent crashes, so if you see any of those,
  you'll know whom to blame!"

Fix up trivial conflicts in arch/{mips,x86}/Kconfig files due to nearby
modifications of other core architecture options.

* 'x86-extable-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (35 commits)
  Revert "x86, extable: Disable presorted exception table for now"
  scripts/sortextable: Handle relative entries, and other cleanups
  x86, extable: Switch to relative exception table entries
  x86, extable: Disable presorted exception table for now
  x86, extable: Add _ASM_EXTABLE_EX() macro
  x86, extable: Remove open-coded exception table entries in arch/x86/ia32/ia32entry.S
  x86, extable: Remove open-coded exception table entries in arch/x86/include/asm/xsave.h
  x86, extable: Remove open-coded exception table entries in arch/x86/include/asm/kvm_host.h
  x86, extable: Remove the now-unused __ASM_EX_SEC macros
  x86, extable: Remove open-coded exception table entries in arch/x86/xen/xen-asm_32.S
  x86, extable: Remove open-coded exception table entries in arch/x86/um/checksum_32.S
  x86, extable: Remove open-coded exception table entries in arch/x86/lib/usercopy_32.c
  x86, extable: Remove open-coded exception table entries in arch/x86/lib/putuser.S
  x86, extable: Remove open-coded exception table entries in arch/x86/lib/getuser.S
  x86, extable: Remove open-coded exception table entries in arch/x86/lib/csum-copy_64.S
  x86, extable: Remove open-coded exception table entries in arch/x86/lib/copy_user_nocache_64.S
  x86, extable: Remove open-coded exception table entries in arch/x86/lib/copy_user_64.S
  x86, extable: Remove open-coded exception table entries in arch/x86/lib/checksum_32.S
  x86, extable: Remove open-coded exception table entries in arch/x86/kernel/test_rodata.c
  x86, extable: Remove open-coded exception table entries in arch/x86/kernel/entry_64.S
  ...
2012-05-23 10:44:35 -07:00
H. Peter Anvin 6520fe5564 x86, realmode: 16-bit real-mode code support for relocs tool
A new option is added to the relocs tool called '--realmode'.
This option causes the generation of 16-bit segment relocations
and 32-bit linear relocations for the real-mode code. When
the real-mode code is moved to the low-memory during kernel
initialization, these relocation entries can be used to
relocate the code properly.

In the assembly code 16-bit segment relocations must be relative
to the 'real_mode_seg' absolute symbol. Linear relocations must be
relative to a symbol prefixed with 'pa_'.

16-bit segment relocation is used to load cs:ip in 16-bit code.
Linear relocations are used in the 32-bit code for relocatable
data references. They are declared in the linker script of the
real-mode code.

The relocs tool is moved to arch/x86/tools/relocs.c, and added new
target archscripts that can be used to build scripts needed building
an architecture.  be compiled before building the arch/x86 tree.

[ hpa: accelerating this because it detects invalid absolute
  relocations, a serious bug in binutils 2.22.52.0.x which currently
  produces bad kernels. ]

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.com
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org>
2012-05-18 19:49:40 -07:00
David Daney d59a16836d scripts/sortextable: Handle relative entries, and other cleanups
x86 is now using relative rather than absolute addresses in its
exception table, so we add a sorter for these.  If there are
relocations on the __ex_table section, they are redundant and probably
incorrect after the sort, so they are zeroed out leaving them valid
and consistent.

Also use the unaligned safe accessors from tools/{be,le}_byteshift.h

Signed-off-by: David Daney <david.daney@cavium.com>
Link: http://lkml.kernel.org/r/1335291795-26693-2-git-send-email-ddaney.cavm@gmail.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2012-04-24 11:42:20 -07:00
David Daney a79f248b9b scripts: Add sortextable to sort the kernel's exception table.
Using this build-time sort saves time booting as we don't have to burn
cycles sorting the exception table.

Signed-off-by: David Daney <david.daney@cavium.com>
Link: http://lkml.kernel.org/r/1334872799-14589-2-git-send-email-ddaney.cavm@gmail.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2012-04-19 15:06:55 -07:00
Peter Foley bffd2020a9 kbuild: move scripts/basic/docproc.c to scripts/docproc.c
Move docproc from scripts/basic to scripts so it is only built for *doc
targets instead of every time the kernel is built.
2011-05-02 22:48:03 +02:00
Mike Waychison e1b702cf22 KBuild: silence "'scripts/unifdef' is up to date."
While changing our build system over to use the headers_install target
as part of our klibc build, the following message started showing up in
our logs:

make[2]: `scripts/unifdef' is up to date.

It turns out that the build blindly invokes a recursive make on this
target, which causes make to emit this message when the target is
already up to date.  This isn't seen for most targets as the rest of the
build relies primarily on the default target and on PHONY targets when
invoking make recursively.

Silence the above message when building unifdef as part of
headers_install by hiding it behind a new PHONY target called
"build_unifdef" that has an empty recipe.

Signed-off-by: Mike Waychison <mikew@google.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2011-03-17 12:29:20 +01:00
Steven Rostedt 72441cb1fd ftrace/x86: Add support for C version of recordmcount
This patch adds the support for the C version of recordmcount and
compile times show ~ 12% improvement.

After verifying this works, other archs can add:

 HAVE_C_MCOUNT_RECORD

in its Kconfig and it will use the C version of recordmcount
instead of the perl version.

Cc: <linux-arch@vger.kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kbuild@vger.kernel.org
Cc: John Reiser <jreiser@bitwagon.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2010-10-14 16:52:41 -04:00
David S. Miller 09d3f3f0e0 sparc: Kill PROM console driver.
Many years ago when this driver was written, it had a use, but these
days it's nothing but trouble and distributions should not enable it
in any situation.

Pretty much every console device a sparc machine could see has a
bonafide real driver, making the PROM console hack unnecessary.

If any new device shows up, we should write a driver instead of
depending upon this crutch to save us.  We've been able to take care
of this even when no chip documentation exists (sunxvr500, sunxvr2500)
so there are no excuses.

Signed-off-by: David S. Miller <davem@davemloft.net>
2009-09-15 17:04:38 -07:00
David Gibson 9fffb55f66 Move dtc and libfdt sources from arch/powerpc/boot to scripts/dtc
The powerpc kernel always requires an Open Firmware like device tree
to supply device information.  On systems without OF, this comes from
a flattened device tree blob.  This blob is usually generated by dtc,
a tool which compiles a text description of the device tree into the
flattened format used by the kernel.  Sometimes, the bootwrapper makes
small changes to the pre-compiled device tree blob (e.g. filling in
the size of RAM).  To do this it uses the libfdt library.

Because these are only used on powerpc, the code for both these tools
is included under arch/powerpc/boot (these were imported and are
periodically updated from the upstream dtc tree).

However, the microblaze architecture, currently being prepared for
merging to mainline also uses dtc to produce device tree blobs.  A few
other archs have also mentioned some interest in using dtc.
Therefore, this patch moves dtc and libfdt from arch/powerpc into
scripts, where it can be used by any architecture.

The vast bulk of this patch is a literal move, the rest is adjusting
the various Makefiles to use dtc and libfdt correctly from their new
locations.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-02 16:52:26 -07:00
David Woodhouse 556b0f58bb Revert "fix modules_install via NFS"
This reverts commit 8b249b6856.

This 'fix' is not necessary; we just need to undo the damage caused
accidentally by Igor/Mauro in 4b29631db3
("V4L/DVB (9533): cx88: Add support for TurboSight TBS8910 DVB-S PCI card")

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-04-06 14:27:17 -07:00
Sam Ravnborg 8b249b6856 fix modules_install via NFS
Rafael reported:

I get the following error from 'make modules_install' on my test boxes:

  HOSTCC  firmware/ihex2fw
/home/rafael/src/linux-2.6/firmware/ihex2fw.c:268: fatal error: opening dependency file firmware/.ihex2fw.d: Read-only file system
compilation terminated.
make[3]: *** [firmware/ihex2fw] Error 1
make[2]: *** [_modinst_post] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2

where the configuration is that the kernel is compiled on a build box
with 'make O=<destdir> -j5' and then <destdir> is mounted over NFS read-only by
each test box (full path to this directory is the same on the build box and on
the test boxes).  Then, I cd into <destdir>, run 'make modules_install' and get
the error above.

The issue turns out to be that we when we install firmware pick
up the list of firmware blobs from firmware/Makefile.
And this triggers the Makefile rules to update ihex2fw.

There were two solutions for this issue:
1) Move the list of firmware blobs to a separate file
2) Avoid ihex2fw rebuild by moving it to scripts

As I seriously beleive that the list of firmware blobs should be
done in a fundamental different way solution 2) was selected.

Reported-and-tested-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: David Woodhouse <dwmw2@infradead.org>
2009-01-07 21:44:20 +01:00
Serge E. Hallyn 93c06cbbf9 selinux: add support for installing a dummy policy (v2)
In August 2006 I posted a patch generating a minimal SELinux policy.  This
week, David P. Quigley posted an updated version of that as a patch against
the kernel.  It also had nice logic for auto-installing the policy.

Following is David's original patch intro (preserved especially
bc it has stats on the generated policies):

se interested in the changes there were only two significant
changes. The first is that the iteration through the list of classes
used NULL as a sentinel value. The problem with this is that the
class_to_string array actually has NULL entries in its table as place
holders for the user space object classes.

The second change was that it would seem at some point the initial sids
table was NULL terminated. This is no longer the case so that iteration
has to be done on array length instead of looking for NULL.

Some statistics on the policy that it generates:

The policy consists of 523 lines which contain no blank lines. Of those
523 lines 453 of them are class, permission, and initial sid
definitions. These lines are usually little to no concern to the policy
developer since they will not be adding object classes or permissions.
Of the remaining 70 lines there is one type, one role, and one user
statement. The remaining lines are broken into three portions. The first
group are TE allow rules which make up 29 of the remaining lines, the
second is assignment of labels to the initial sids which consist of 27
lines, and file system labeling statements which are the remaining 11.

In addition to the policy.conf generated there is a single file_contexts
file containing two lines which labels the entire system with base_t.

This policy generates a policy.23 binary that is 7920 bytes.

(then a few versions later...):

The new policy is 587 lines (stripped of blank lines) with 476 of those
lines being the boilerplate that I mentioned last time. The remaining
111 lines have the 3 lines for type, user, and role, 70 lines for the
allow rules (one for each object class including user space object
classes), 27 lines to assign types to the initial sids, and 11 lines for
file system labeling. The policy binary is 9194 bytes.

Changelog:

	Aug 26: Added Documentation/SELinux.txt
	Aug 26: Incorporated a set of comments by Stephen Smalley:
		1. auto-setup SELINUXTYPE=dummy
		2. don't auto-install if selinux is enabled with
			non-dummy policy
		3. don't re-compute policy version
		4. /sbin/setfiles not /usr/sbin/setfiles
	Aug 22: As per JMorris comments, made sure make distclean
		cleans up the mdp directory.
		Removed a check for file_contexts which is now
		created in the same file as the check, making it
		superfluous.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: David Quigley <dpquigl@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
2008-08-27 08:54:08 +10:00
Ross Biro f2443ab6c4 [PATCH] allow /proc/config.gz to be built as a module
The driver for /proc/config.gz consumes rather a lot of memory and it is in
fact possible to build it as a module.

In some ways this is a bit risky, because the .config which is used for
compiling kernel/configs.c isn't necessarily the same as the .config which was
used to build vmlinux.

But OTOH the potential memory savings are decent, and it'd be fairly dumb to
build your configs.o with a different .config.

Signed-off-by: Andrew Morton <akpm@google.com>
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-01 00:39:20 -07:00
Sam Ravnborg 12715d20af kbuild: modpost on vmlinux regardless of CONFIG_MODULES
Based on patch from: Magnus Damm <magnus@valinux.co.jp>
This has the advantage that all section mismatch checks are run regardless
of modules being enabled or not.

When running modpost on vmlinux output:
MODPOST vmlinux

When running modpost on modules output count of modules like this:
MODPOST 5 modules

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-09-25 09:01:49 +02:00
Sam Ravnborg 07aea3a71f kbuild: use in-kernel unifdef
Let headers_install use in-kernel unifdef

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-09-25 09:00:01 +02:00
Sam Ravnborg 6f6046cff2 kconfig: move lxdialog to scripts/kconfig/lxdialog
The only lxdialog user i kconfig - for menuconfig.
So move it to reflect this.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-12-16 21:35:19 +01:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00