From: Oscar Carter <oscar.carter@gmx.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Oscar Carter <oscar.carter@gmx.com>,
Ingo Molnar <mingo@redhat.com>, Kees Cook <keescook@chromium.org>,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com, Jann Horn <jannh@google.com>
Subject: Re: [PATCH v2 2/2] kernel/trace: Remove function callback casts
Date: Fri, 24 Jul 2020 19:24:03 +0200 [thread overview]
Message-ID: <20200724172403.GC3123@ubuntu> (raw)
In-Reply-To: <20200724171418.GB3123@ubuntu>
Hi Steven,
On Fri, Jul 24, 2020 at 07:14:18PM +0200, Oscar Carter wrote:
> On Fri, Jul 24, 2020 at 12:35:28PM -0400, Steven Rostedt wrote:
> > On Fri, 24 Jul 2020 18:19:21 +0200
> > Oscar Carter <oscar.carter@gmx.com> wrote:
> >
> > > > The linker trick is far less intrusive, and I believe less error prone.
> > >
> > > If we use the linker trick, the warning -Wcast-function-type dissapears,
> > > but in a way that makes impossible to the compiler to get the necessary
> > > info about function prototypes to insert the commented check. As far I
> > > know, this linker trick (redirection of a function) is hidden for the
> > > CFI build.
> > >
> > > So, in my opinion, the linker trick is not suitable if we want to protect
> > > the function pointers of the ftrace subsystem against an attack that
> > > modifiy the normal flow of the kernel.
> >
> > The linker trick should only affect architectures that don't implement
> > the needed features. I can make it so the linker trick is only applied
> > to those archs, and other archs that want more protection only need to
> > add these features to their architectures.
> >
> > It's much less intrusive than this patch.
>
> Sorry, but I don't understand your proposal. What features an arch need to
> add if want the CFI protection?
Typo correction.
Sorry, but I don't understand your proposal. What features does an arch need
to add if want the CFI protection?
>
> >
> > -- Steve
>
Thanks,
Oscar Carter
next prev parent reply other threads:[~2020-07-24 17:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-19 15:50 [PATCH v2 0/2] kernel/trace: Remove function callback casts Oscar Carter
2020-07-19 15:50 ` [PATCH v2 1/2] kernel/trace: Prepare to remove " Oscar Carter
2020-07-19 15:50 ` [PATCH v2 2/2] kernel/trace: Remove " Oscar Carter
2020-07-21 18:05 ` Steven Rostedt
2020-07-24 16:19 ` Oscar Carter
2020-07-24 16:35 ` Steven Rostedt
2020-07-24 17:14 ` Oscar Carter
2020-07-24 17:24 ` Oscar Carter [this message]
2020-07-24 17:36 ` Steven Rostedt
2020-07-24 17:40 ` Steven Rostedt
2020-07-24 17:48 ` Steven Rostedt
2020-07-24 17:55 ` Oscar Carter
2020-07-24 18:34 ` Steven Rostedt
2020-07-25 15:09 ` Oscar Carter
2020-07-25 15:19 ` Oscar Carter
2020-07-26 15:52 ` Oscar Carter
2020-07-27 13:53 ` Steven Rostedt
2020-07-31 14:41 ` Oscar Carter
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=20200724172403.GC3123@ubuntu \
--to=oscar.carter@gmx.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.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.