From: Kees Cook <keescook@chromium.org>
To: Igor Stoppa <igor.stoppa@gmail.com>
Cc: Igor Stoppa <igor.stoppa@huawei.com>,
Ahmed Soliman <ahmedsoliman@mena.vt.edu>,
linux-integrity <linux-integrity@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v4 00/12] hardening: statically allocated protected memory
Date: Mon, 11 Feb 2019 16:46:56 -0800 [thread overview]
Message-ID: <CAGXu5jLqmYRUVLb7-jPsN4onO5UNH+D6qOF=9TOiVjJa-=DnZQ@mail.gmail.com> (raw)
In-Reply-To: <25bf3c63-c54c-f7ea-bec1-996a2c05d997@gmail.com>
On Mon, Feb 11, 2019 at 4:37 PM Igor Stoppa <igor.stoppa@gmail.com> wrote:
>
>
>
> On 12/02/2019 02:09, Kees Cook wrote:
> > On Mon, Feb 11, 2019 at 3:28 PM Igor Stoppa <igor.stoppa@gmail.com> wrote:
> > It looked like only the memset() needed architecture support. Is there
> > a reason for not being able to implement memset() in terms of an
> > inefficient put_user() loop instead? That would eliminate the need for
> > per-arch support, yes?
>
> So far, yes, however from previous discussion about power arch, I
> understood this implementation would not be so easy to adapt.
> Lacking other examples where the extra mapping could be used, I did not
> want to add code without a use case.
>
> Probably both arm and x86 32 bit could do, but I would like to first get
> to the bitter end with memory protection (the other 2 thirds).
>
> Mostly, I hated having just one arch and I also really wanted to have arm64.
Right, I meant, if you implemented the _memset() case with put_user()
in this version, you could drop the arch-specific _memset() and shrink
the patch series. Then you could also enable this across all the
architectures in one patch. (Would you even need the Kconfig patches,
i.e. won't this "Just Work" on everything with an MMU?)
--
Kees Cook
next prev parent reply other threads:[~2019-02-12 0:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 23:27 [RFC PATCH v4 00/12] hardening: statically allocated protected memory Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 01/12] __wr_after_init: Core and default arch Igor Stoppa
2019-02-12 2:39 ` Matthew Wilcox
2019-02-12 7:20 ` Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 02/12] __wr_after_init: x86_64: memset_user() Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 03/12] __wr_after_init: x86_64: randomize mapping offset Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 04/12] __wr_after_init: x86_64: enable Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 05/12] __wr_after_init: arm64: memset_user() Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 06/12] __wr_after_init: arm64: enable Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 07/12] __wr_after_init: Documentation: self-protection Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 08/12] __wr_after_init: lkdtm test Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 09/12] __wr_after_init: rodata_test: refactor tests Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 10/12] __wr_after_init: rodata_test: test __wr_after_init Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 11/12] __wr_after_init: test write rare functionality Igor Stoppa
2019-02-11 23:27 ` [RFC PATCH v4 12/12] IMA: turn ima_policy_flags into __wr_after_init Igor Stoppa
2019-02-12 0:09 ` [RFC PATCH v4 00/12] hardening: statically allocated protected memory Kees Cook
2019-02-12 0:37 ` Igor Stoppa
2019-02-12 0:46 ` Kees Cook [this message]
2019-02-12 1:08 ` igor.stoppa
2019-02-12 1:26 ` Kees Cook
2019-02-12 7:09 ` Igor Stoppa
2019-02-12 22:39 ` 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='CAGXu5jLqmYRUVLb7-jPsN4onO5UNH+D6qOF=9TOiVjJa-=DnZQ@mail.gmail.com' \
--to=keescook@chromium.org \
--cc=ahmedsoliman@mena.vt.edu \
--cc=igor.stoppa@gmail.com \
--cc=igor.stoppa@huawei.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).