From: Dan Aloni <dan@kernelim.com>
To: linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com
Cc: Dan Aloni <dan@kernelim.com>
Subject: [PATCH 0/5] RFC: Public key encryption of dmesg by the kernel
Date: Sat, 30 Dec 2017 19:57:59 +0200 [thread overview]
Message-ID: <20171230175804.7354-1-alonid@gmail.com> (raw)
From: Dan Aloni <dan@kernelim.com>
Hi All,
There has been a lot of progress in recent times regarding the removal
of sensitive information from dmesg (pointers, etc.), so I figured - why
not encrypt it all? However, I have not found any existing discussions
or references regarding this technical direction.
I am not sure that desktop and power users would like to have their
kernel message encrypted, but there are scenarios such as in mobile
devices, where only the developers, makers of devices, may actually
benefit from access to kernel prints messages, and the users may be
more protected from exploits.
In its present form, it is an RFC, so that before investing more time
developing it further, I would receive comments regarding its viability
and suggestions for design.
Dan Aloni (5):
crypto: fix memory leak in rsa-kcs1pad encryption
certs: allow in-kernel access of trusted keys
kernel/printk: allow kmsg to be encrypted using public key encryption
tools: add dmesg decryption program
docs: add dmesg encryption doc
Documentation/admin-guide/dmesg-encryption.rst | 77 +++++
certs/system_keyring.c | 56 +++-
crypto/rsa-pkcs1pad.c | 9 -
include/keys/system_keyring.h | 3 +
include/uapi/linux/kmsg.h | 18 ++
init/Kconfig | 10 +
kernel/printk/printk.c | 422 +++++++++++++++++++++++++
tools/Makefile | 5 +-
tools/kmsg/.gitignore | 1 +
tools/kmsg/Makefile | 14 +
tools/kmsg/dmesg-decipher.c | 316 ++++++++++++++++++
11 files changed, 920 insertions(+), 11 deletions(-)
create mode 100644 Documentation/admin-guide/dmesg-encryption.rst
create mode 100644 include/uapi/linux/kmsg.h
create mode 100644 tools/kmsg/.gitignore
create mode 100644 tools/kmsg/Makefile
create mode 100644 tools/kmsg/dmesg-decipher.c
--
2.13.6
next reply other threads:[~2017-12-30 17:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-30 17:57 Dan Aloni [this message]
2017-12-30 17:58 ` [PATCH 1/5] crypto: fix memory leak in rsa-kcs1pad encryption Dan Aloni
2017-12-30 17:58 ` [PATCH 2/5] certs: allow in-kernel access of trusted keys Dan Aloni
2017-12-30 18:52 ` Randy Dunlap
2017-12-30 17:58 ` [PATCH 3/5] kernel/printk: allow kmsg to be encrypted using public key encryption Dan Aloni
2017-12-30 20:39 ` Randy Dunlap
2017-12-30 17:58 ` [PATCH 4/5] tools: add dmesg decryption program Dan Aloni
2017-12-30 20:20 ` Randy Dunlap
2017-12-30 17:58 ` [PATCH 5/5] docs: add dmesg encryption doc Dan Aloni
2017-12-30 19:14 ` [kernel-hardening] " Boris Lukashev
2017-12-30 19:40 ` Randy Dunlap
2018-01-03 20:21 ` Dan Aloni
2018-01-03 20:45 ` Randy Dunlap
2017-12-30 21:42 ` [kernel-hardening] [PATCH 0/5] RFC: Public key encryption of dmesg by the kernel Jann Horn
2018-01-03 20:41 ` Dan Aloni
2018-01-18 21:57 ` [kernel-hardening] " Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171230175804.7354-1-alonid@gmail.com \
--to=dan@kernelim.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox