From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <25bf3c63-c54c-f7ea-bec1-996a2c05d997@gmail.com> In-Reply-To: From: "igor.stoppa@gmail.com" Date: Tue, 12 Feb 2019 05:08:03 +0400 Message-ID: Subject: Re: [RFC PATCH v4 00/12] hardening: statically allocated protected memory Content-Type: multipart/alternative; boundary="00000000000058dc140581a80fc2" To: Kees Cook Cc: Igor Stoppa , Ahmed Soliman , linux-integrity , Kernel Hardening , Linux-MM , Linux Kernel Mailing List List-ID: --00000000000058dc140581a80fc2 Content-Type: text/plain; charset="UTF-8" On Tue, 12 Feb 2019, 4.47 Kees Cook On Mon, Feb 11, 2019 at 4:37 PM Igor Stoppa wrote: > > > > > > > > On 12/02/2019 02:09, Kees Cook wrote: > > > On Mon, Feb 11, 2019 at 3:28 PM Igor Stoppa > 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?) > I had similar thoughts, but this answer [1] deflated my hopes (if I understood it correctly). It seems that each arch needs to be massaged in separately. -- igor [1] https://www.openwall.com/lists/kernel-hardening/2018/12/12/15 > --00000000000058dc140581a80fc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Tue, 12 Feb 2019, 4.47 Kees Cook <keescook@chromium.org wrote:
On Mon, Feb 11, 2019 at 4:37 PM Igor Stoppa <igor.stoppa@gmail.co= m> wrote:
>
>
>
> On 12/02/2019 02:09, Kees Cook wrote:
> > On Mon, Feb 11, 2019 at 3:28 PM Igor Stoppa <igor.stoppa@gm= ail.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<= br> > > inefficient put_user() loop instead? That would eliminate the nee= d 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 no= t
> want to add code without a use case.
>
> Probably both arm and x86 32 bit could do, but I would like to first g= et
> 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?)

I had = similar thoughts, but this answer [1] deflated my hopes (if I understood it= correctly).
It seems that each arch needs to be mas= saged in separately.=C2=A0

--
igor


--00000000000058dc140581a80fc2--