From: Mike Rapoport <rppt@linux.ibm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: linux-kernel@vger.kernel.org,
Alexandre Chartre <alexandre.chartre@oracle.com>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Jonathan Adams <jwadams@google.com>,
Kees Cook <keescook@chromium.org>, Paul Turner <pjt@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-mm@kvack.org, linux-security-module@vger.kernel.org,
x86@kernel.org
Subject: Re: [RFC PATCH 0/7] x86: introduce system calls addess space isolation
Date: Sun, 28 Apr 2019 09:08:27 +0300 [thread overview]
Message-ID: <20190428060826.GF14896@rapoport-lnx> (raw)
In-Reply-To: <1c12e195-1286-0136-eae5-4b392d9fe4c0@intel.com>
On Fri, Apr 26, 2019 at 07:41:09AM -0700, Dave Hansen wrote:
> On 4/25/19 2:45 PM, Mike Rapoport wrote:
> > The idea behind the prevention is that if we fault in pages in the
> > execution path, we can compare target address against the kernel symbol
> > table. So if we're in a function, we allow local jumps (and simply falling
> > of the end of a page) but if we're jumping to a new function it must be to
> > an external label in the symbol table. Since ROP attacks are all about
> > jumping to gadget code which is effectively in the middle of real
> > functions, the jumps they induce are to code that doesn't have an external
> > symbol, so it should mostly detect when they happen.
>
> This turns the problem from: "attackers can leverage any data/code that
> the kernel has mapped (anything)" to "attackers can leverage any
> code/data that the current syscall has faulted in".
>
> That seems like a pretty restrictive change.
>
> > At this time we are not suggesting any API that will enable the system
> > calls isolation. Because of the overhead required for this, it should only
> > be activated for processes or containers we know should be untrusted. We
> > still have no actual numbers, but surely forcing page faults during system
> > call execution will not come for free.
>
> What's the minimum number of faults that have to occur to handle the
> simplest dummy fault?
For the current implementation it's 3.
Here is the example trace of #PF's produced by a dummy get_answer
system call from patch 7:
[ 12.012906] #PF: DATA: do_syscall_64+0x26b/0x4c0 fault at 0xffffffff82000bb8
[ 12.012918] #PF: INSN: __x86_indirect_thunk_rax+0x0/0x20 fault at __x86_indirect_thunk_rax+0x0/0x20
[ 12.012929] #PF: INSN: __x64_sys_get_answer+0x0/0x10 fault at__x64_sys_get_answer+0x0/0x10
For the sci_write_dmesg syscall that does copy_from_user() and printk() its
between 35 and 60 depending on console and /proc/sys/kernel/printk values.
This includes both code and data accesses. The data page faults can be
avoided if we pre-populate SCI page tables with data.
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2019-04-28 6:08 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-25 21:45 [RFC PATCH 0/7] x86: introduce system calls addess space isolation Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 1/7] x86/cpufeatures: add X86_FEATURE_SCI Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation Mike Rapoport
2019-04-26 7:49 ` Peter Zijlstra
2019-04-28 5:45 ` Mike Rapoport
2019-04-26 8:31 ` Ingo Molnar
2019-04-26 9:58 ` Ingo Molnar
2019-04-26 21:26 ` Andy Lutomirski
2019-04-27 8:47 ` Ingo Molnar
2019-04-27 10:46 ` Ingo Molnar
2019-04-29 18:26 ` James Morris
2019-04-29 18:43 ` Andy Lutomirski
2019-04-29 18:46 ` Andy Lutomirski
2019-04-30 5:03 ` Ingo Molnar
2019-04-30 9:38 ` Peter Zijlstra
2019-04-30 11:05 ` Ingo Molnar
2019-05-02 11:35 ` Robert O'Callahan
2019-05-02 15:20 ` Ingo Molnar
2019-05-02 21:07 ` Robert O'Callahan
2019-04-26 14:44 ` James Bottomley
2019-04-26 14:46 ` Dave Hansen
2019-04-26 14:57 ` James Bottomley
2019-04-26 15:07 ` Andy Lutomirski
2019-04-26 15:19 ` James Bottomley
2019-04-26 17:40 ` Andy Lutomirski
2019-04-26 18:49 ` James Bottomley
2019-04-26 19:22 ` Andy Lutomirski
2019-04-25 21:45 ` [RFC PATCH 3/7] x86/entry/64: add infrastructure for switching to isolated syscall context Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 4/7] x86/sci: hook up isolated system call entry and exit Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 5/7] x86/mm/fault: hook up SCI verification Mike Rapoport
2019-04-26 7:42 ` Peter Zijlstra
2019-04-28 5:47 ` Mike Rapoport
2019-04-30 16:44 ` Andy Lutomirski
2019-05-01 5:39 ` Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 6/7] security: enable system call isolation in kernel config Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 7/7] sci: add example system calls to exercse SCI Mike Rapoport
2019-04-26 0:30 ` [RFC PATCH 0/7] x86: introduce system calls addess space isolation Andy Lutomirski
2019-04-26 8:07 ` Jiri Kosina
2019-04-28 6:01 ` Mike Rapoport
2019-04-26 14:41 ` Dave Hansen
2019-04-28 6:08 ` Mike Rapoport [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-07-01 14:05 黄金海
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=20190428060826.GF14896@rapoport-lnx \
--to=rppt@linux.ibm.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alexandre.chartre@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jwadams@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 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.