From: Igor Stoppa <igor.stoppa@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Igor Stoppa <igor.stoppa@huawei.com>,
Andy Lutomirski <luto@amacapital.net>,
Nadav Amit <nadav.amit@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
Kees Cook <keescook@chromium.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Thiago Jung Bauermann <bauerman@linux.ibm.com>,
Ahmed Soliman <ahmedsoliman@mena.vt.edu>,
linux-integrity@vger.kernel.org,
kernel-hardening@lists.openwall.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v5 03/12] __wr_after_init: Core and default arch
Date: Fri, 15 Feb 2019 01:10:33 +0200 [thread overview]
Message-ID: <6e9ec71c-ee75-9b1e-9ff8-a3210030e85d@gmail.com> (raw)
In-Reply-To: <20190214112849.GM32494@hirez.programming.kicks-ass.net>
On 14/02/2019 13:28, Peter Zijlstra wrote:
> On Thu, Feb 14, 2019 at 12:41:32AM +0200, Igor Stoppa wrote:
[...]
>> +#define wr_rcu_assign_pointer(p, v) ({ \
>> + smp_mb(); \
>> + wr_assign(p, v); \
>> + p; \
>> +})
>
> This requires that wr_memcpy() (through wr_assign) is single-copy-atomic
> for native types. There is not a comment in sight that states this.
Right, I kinda expected native-aligned <-> atomic, but it's not
necessarily true. It should be confirmed when enabling write rare on a
new architecture. I'll add the comment.
> Also, is this true of x86/arm64 memcpy ?
For x86_64:
https://elixir.bootlin.com/linux/v5.0-rc6/source/arch/x86/include/asm/uaccess.h#L462
the mov"itype" part should deal with atomic copy of native, aligned
types.
For arm64:
https://elixir.bootlin.com/linux/v5.0-rc6/source/arch/arm64/lib/copy_template.S#L110
.Ltiny15 deals with copying less than 16 bytes, which includes pointers.
When the data is aligned, the copy of a pointer should be atomic.
--
igor
next prev parent reply other threads:[~2019-02-14 23:10 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 22:41 [RFC PATCH v5 00/12] hardening: statically allocated protected memory Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 02/12] __wr_after_init: linker section and attribute Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 03/12] __wr_after_init: Core and default arch Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-14 11:28 ` Peter Zijlstra
2019-02-14 23:10 ` Igor Stoppa [this message]
2019-02-15 8:57 ` Peter Zijlstra
2019-02-16 15:15 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 04/12] __wr_after_init: x86_64: randomize mapping offset Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 05/12] __wr_after_init: x86_64: enable Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 06/12] __wr_after_init: arm64: enable Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 07/12] __wr_after_init: Documentation: self-protection Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 08/12] __wr_after_init: lkdtm test Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 09/12] __wr_after_init: rodata_test: refactor tests Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 10/12] __wr_after_init: rodata_test: test __wr_after_init Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 11/12] __wr_after_init: test write rare functionality Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
2019-02-13 22:41 ` [RFC PATCH v5 12/12] IMA: turn ima_policy_flags into __wr_after_init Igor Stoppa
2019-02-13 22:41 ` Igor Stoppa
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=6e9ec71c-ee75-9b1e-9ff8-a3210030e85d@gmail.com \
--to=igor.stoppa@gmail.com \
--cc=ahmedsoliman@mena.vt.edu \
--cc=bauerman@linux.ibm.com \
--cc=dave.hansen@linux.intel.com \
--cc=igor.stoppa@huawei.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=nadav.amit@gmail.com \
--cc=peterz@infradead.org \
--cc=willy@infradead.org \
--cc=zohar@linux.vnet.ibm.com \
/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 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.