linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Igor Stoppa <igor.stoppa@gmail.com>
To: Matthew Wilcox <willy@infradead.org>, Nadav Amit <nadav.amit@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	igor.stoppa@huawei.com, Kees Cook <keescook@chromium.org>,
	linux-integrity@vger.kernel.org,
	kernel-hardening@lists.openwall.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 03/12] __wr_after_init: generic header
Date: Sun, 23 Dec 2018 04:28:59 +0200	[thread overview]
Message-ID: <6562ebd3-e97d-41c4-261a-9f4b863118eb@gmail.com> (raw)
In-Reply-To: <20181221194547.GI10600@bombadil.infradead.org>



On 21/12/2018 21:45, Matthew Wilcox wrote:
> On Fri, Dec 21, 2018 at 11:38:16AM -0800, Nadav Amit wrote:
>>> On Dec 19, 2018, at 1:33 PM, Igor Stoppa <igor.stoppa@gmail.com> wrote:
>>>
>>> +static inline void *wr_memset(void *p, int c, __kernel_size_t len)
>>> +{
>>> +	return __wr_op((unsigned long)p, (unsigned long)c, len, WR_MEMSET);
>>> +}
>>
>> What do you think about doing something like:
>>
>> #define __wr          __attribute__((address_space(5)))
>>
>> And then make all the pointers to write-rarely memory to use this attribute?
>> It might require more changes to the code, but can prevent bugs.
> 
> I like this idea.  It was something I was considering suggesting.

I have been thinking about this sort of problem, although from a bit 
different angle:

1) enforcing alignment for pointers
This can be implemented in similar way, by creating a multi-attribute 
that would define section, address space, like said here, and alignment.
However I'm not sure if it's possible to do anything to enforce the 
alignment of a pointer field within a structure. I haven't had time to 
look into this yet.

2) validation of the correctness of the actual value
Inside the kernel code, a function is not supposed to sanitize its 
arguments, as long as they come from some other trusted part of the 
kernel, rather than say from userspace or from some HW interface.
However,ROP/JOP should be considered.

I am aware of various efforts to make it harder to exploit these 
techniques, like signed pointers, CFI plugins, LTO.

But they are not necessarily available on every platform and mostly, 
afaik, they focus on specific type of attacks.


LTO can help with global optimizations, for example inlining functions 
across different objects.

CFI can detect jumps in the middle of a function, rather than proper 
function invocation, from its natural entry point.

Signed pointers can prevent data-based attacks to the execution flow, 
and they might have a role in preventing the attack I have in mind, but 
they are not available on all platforms.

What I'd like to do, is to verify, at runtime, that the pointer belongs 
to the type that the receiving function is meant for.

Ex: a legitimate __wr_after_init data must exist between 
__start_wr_after_init and __end_wr_after_init

That is easier and cleaner to test, imho.

But dynamically allocated memory doesn't have any such constraint.
If it was possible to introduce, for example, a flag to pass to vmalloc, 
to get the vmap_area from within a specific address range, it would 
reduce the attack surface.

In the implementation I have right now, I'm using extra flags for the 
pmalloc pages, which means the metadata is the new target for an attack.

But with adding the constraint that a dynamically allocated protected 
memory page must be within a range, then the attacker must change the 
underlying PTE. And if a region of PTEs are all part of protected 
memory, it is possible to make the PMD write rare.

--
igor

  reply	other threads:[~2018-12-23  2:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-19 21:33 [RFC v2 PATCH 0/12] hardening: statically allocated protected memory Igor Stoppa
2018-12-19 21:33 ` [PATCH 01/12] x86_64: memset_user() Igor Stoppa
2018-12-19 21:33 ` [PATCH 02/12] __wr_after_init: linker section and label Igor Stoppa
2018-12-19 21:33 ` [PATCH 03/12] __wr_after_init: generic header Igor Stoppa
2018-12-21 19:38   ` Nadav Amit
2018-12-21 19:45     ` Matthew Wilcox
2018-12-23  2:28       ` Igor Stoppa [this message]
2018-12-19 21:33 ` [PATCH 04/12] __wr_after_init: x86_64: __wr_op Igor Stoppa
2018-12-20 16:53   ` Igor Stoppa
2018-12-20 17:20   ` Thiago Jung Bauermann
2018-12-20 17:46     ` Igor Stoppa
2018-12-20 18:49   ` Matthew Wilcox
2018-12-20 19:19     ` Igor Stoppa
2018-12-20 19:27       ` Matthew Wilcox
2018-12-21 17:23       ` Andy Lutomirski
2018-12-21 17:42         ` Igor Stoppa
2018-12-19 21:33 ` [PATCH 05/12] __wr_after_init: x86_64: debug writes Igor Stoppa
2018-12-19 21:33 ` [PATCH 06/12] __wr_after_init: Documentation: self-protection Igor Stoppa
2018-12-19 21:33 ` [PATCH 07/12] __wr_after_init: lkdtm test Igor Stoppa
2018-12-19 21:33 ` [PATCH 08/12] rodata_test: refactor tests Igor Stoppa
2018-12-19 21:33 ` [PATCH 09/12] rodata_test: add verification for __wr_after_init Igor Stoppa
2018-12-19 21:33 ` [PATCH 10/12] __wr_after_init: test write rare functionality Igor Stoppa
2018-12-19 21:33 ` [PATCH 11/12] IMA: turn ima_policy_flags into __wr_after_init Igor Stoppa
2018-12-20 17:30   ` Thiago Jung Bauermann
2018-12-20 17:49     ` Igor Stoppa
2018-12-19 21:33 ` [PATCH 12/12] x86_64: __clear_user as case of __memset_user 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=6562ebd3-e97d-41c4-261a-9f4b863118eb@gmail.com \
    --to=igor.stoppa@gmail.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 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).