From: Eddie Kovsky <ewk@edkovsky.org> To: jeyu@redhat.com, rusty@rustcorp.com.au, keescook@chromium.org Cc: linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: [PATCH v5 0/2] provide check for ro_after_init memory sections Date: Wed, 5 Apr 2017 21:35:48 -0600 [thread overview] Message-ID: <20170406033550.32525-1-ewk@edkovsky.org> (raw) Provide a mechanism for other functions to verify that their arguments are read-only. This implements the first half of a suggestion made by Kees Cook for the Kernel Self Protection Project: - provide mechanism to check for ro_after_init memory areas, and reject structures not marked ro_after_init in vmbus_register() http://www.openwall.com/lists/kernel-hardening/2017/02/04/1 The idea is to prevent structures (including modules) that are not read-only from being passed to functions. It builds upon the functions in kernel/extable.c that test if an address is in the text section. A build failure on the Blackfin architecture led to the discovery of an incomplete definition of the RO_DATA macro used in this series. The fixes are in linux-next: commit 906f2a51c941 ("mm: fix section name for .data..ro_after_init") commit 939897e2d736 ("vmlinux.lds: add missing VMLINUX_SYMBOL macros") The latest version of this series uses new symbols provided in these fixes. The series now cross compiles on Blackfin without errors. I have also test compiled this series on next-20170405 for x86. I have dropped the third patch that uses these features to check the arguments to vmbus_register() because the maintainers have not been receptive to using it. My goal right now is to get the API right. Eddie Kovsky (2): module: verify address is read-only extable: verify address is read-only include/linux/kernel.h | 2 ++ include/linux/module.h | 12 ++++++++++++ kernel/extable.c | 29 +++++++++++++++++++++++++++ kernel/module.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 96 insertions(+) -- 2.12.2
WARNING: multiple messages have this Message-ID (diff)
From: Eddie Kovsky <ewk@edkovsky.org> To: jeyu@redhat.com, rusty@rustcorp.com.au, keescook@chromium.org Cc: linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com Subject: [kernel-hardening] [PATCH v5 0/2] provide check for ro_after_init memory sections Date: Wed, 5 Apr 2017 21:35:48 -0600 [thread overview] Message-ID: <20170406033550.32525-1-ewk@edkovsky.org> (raw) Provide a mechanism for other functions to verify that their arguments are read-only. This implements the first half of a suggestion made by Kees Cook for the Kernel Self Protection Project: - provide mechanism to check for ro_after_init memory areas, and reject structures not marked ro_after_init in vmbus_register() http://www.openwall.com/lists/kernel-hardening/2017/02/04/1 The idea is to prevent structures (including modules) that are not read-only from being passed to functions. It builds upon the functions in kernel/extable.c that test if an address is in the text section. A build failure on the Blackfin architecture led to the discovery of an incomplete definition of the RO_DATA macro used in this series. The fixes are in linux-next: commit 906f2a51c941 ("mm: fix section name for .data..ro_after_init") commit 939897e2d736 ("vmlinux.lds: add missing VMLINUX_SYMBOL macros") The latest version of this series uses new symbols provided in these fixes. The series now cross compiles on Blackfin without errors. I have also test compiled this series on next-20170405 for x86. I have dropped the third patch that uses these features to check the arguments to vmbus_register() because the maintainers have not been receptive to using it. My goal right now is to get the API right. Eddie Kovsky (2): module: verify address is read-only extable: verify address is read-only include/linux/kernel.h | 2 ++ include/linux/module.h | 12 ++++++++++++ kernel/extable.c | 29 +++++++++++++++++++++++++++ kernel/module.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 96 insertions(+) -- 2.12.2
next reply other threads:[~2017-04-06 3:36 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-06 3:35 Eddie Kovsky [this message] 2017-04-06 3:35 ` [kernel-hardening] [PATCH v5 0/2] provide check for ro_after_init memory sections Eddie Kovsky 2017-04-06 3:35 ` [PATCH v5 1/2] module: verify address is read-only Eddie Kovsky 2017-04-06 3:35 ` [kernel-hardening] " Eddie Kovsky 2017-04-07 1:58 ` Jessica Yu 2017-04-07 1:58 ` [kernel-hardening] " Jessica Yu 2017-04-07 20:46 ` Kees Cook 2017-04-07 20:46 ` [kernel-hardening] " Kees Cook 2017-04-06 3:35 ` [PATCH v5 2/2] extable: " Eddie Kovsky 2017-04-06 3:35 ` [kernel-hardening] " Eddie Kovsky 2017-04-06 17:20 ` kbuild test robot 2017-04-06 17:20 ` [kernel-hardening] " kbuild test robot 2017-04-06 17:41 ` kbuild test robot 2017-04-06 17:41 ` [kernel-hardening] " kbuild test robot 2017-04-07 19:29 ` Eddie Kovsky 2017-04-07 19:29 ` [kernel-hardening] " Eddie Kovsky 2017-04-07 20:45 ` Kees Cook 2017-04-07 20:45 ` [kernel-hardening] " Kees Cook 2017-04-07 21:53 ` [PATCH v5 0/2] provide check for ro_after_init memory sections Kees Cook 2017-04-07 21:53 ` [kernel-hardening] " Kees Cook 2017-04-07 22:12 ` Andrew Morton 2017-04-07 22:12 ` [kernel-hardening] " Andrew Morton 2017-04-07 22:15 ` Kees Cook 2017-04-07 22:15 ` [kernel-hardening] " Kees Cook 2017-04-07 22:23 ` Andrew Morton 2017-04-07 22:23 ` [kernel-hardening] " Andrew Morton 2017-04-07 22:47 ` Kees Cook 2017-04-07 22:47 ` [kernel-hardening] " Kees Cook
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=20170406033550.32525-1-ewk@edkovsky.org \ --to=ewk@edkovsky.org \ --cc=jeyu@redhat.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=rusty@rustcorp.com.au \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.