[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Oct 2018 22:01:22 +0200
From: Igor Stoppa <igor.stoppa@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>, Kees Cook <keescook@...omium.org>,
Matthew Wilcox <willy@...radead.org>, Dave Chinner <david@...morbit.com>,
James Morris <jmorris@...ei.org>, Michal Hocko <mhocko@...nel.org>,
kernel-hardening@...ts.openwall.com, linux-integrity@...r.kernel.org,
linux-security-module@...r.kernel.org, igor.stoppa@...wei.com,
Dave Hansen <dave.hansen@...ux.intel.com>, Jonathan Corbet <corbet@....net>,
Laura Abbott <labbott@...hat.com>, Vlastimil Babka <vbabka@...e.cz>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Pavel Tatashin <pasha.tatashin@...cle.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/17] prmem: write rare for static allocation
On 26/10/2018 10:41, Peter Zijlstra wrote:
> On Wed, Oct 24, 2018 at 12:34:49AM +0300, Igor Stoppa wrote:
>> +static __always_inline
>
> That's far too large for inline.
The reason for it is that it's supposed to minimize the presence of
gadgets that might be used in JOP attacks.
I am ready to stand corrected, if I'm wrong, but this is the reason why
I did it.
Regarding the function being too large, yes, I would not normally choose
it for inlining.
Actually, I would not normally use "__always_inline" and instead I would
limit myself to plain "inline", at most.
>
>> +bool wr_memset(const void *dst, const int c, size_t n_bytes)
>> +{
>> + size_t size;
>> + unsigned long flags;
>> + uintptr_t d = (uintptr_t)dst;
>> +
>> + if (WARN(!__is_wr_after_init(dst, n_bytes), WR_ERR_RANGE_MSG))
>> + return false;
>> + while (n_bytes) {
>> + struct page *page;
>> + uintptr_t base;
>> + uintptr_t offset;
>> + uintptr_t offset_complement;
>> +
>> + local_irq_save(flags);
>> + page = virt_to_page(d);
>> + offset = d & ~PAGE_MASK;
>> + offset_complement = PAGE_SIZE - offset;
>> + size = min(n_bytes, offset_complement);
>> + base = (uintptr_t)vmap(&page, 1, VM_MAP, PAGE_KERNEL);
>> + if (WARN(!base, WR_ERR_PAGE_MSG)) {
>> + local_irq_restore(flags);
>> + return false;
>> + }
>> + memset((void *)(base + offset), c, size);
>> + vunmap((void *)base);
>
> BUG
yes, somehow I managed to drop this debug configuration from the debug
builds I made.
[...]
> Also, I see an amount of duplication here that shows you're not nearly
> lazy enough.
I did notice a certain amount of duplication, but I didn't know how to
exploit it.
--
igor
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
