lkml.org 
[lkml]   [2017]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 4/6] hw_breakpoint: Factor out __modify_user_hw_breakpoint function
On Mon, Nov 27, 2017 at 1:20 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Nov 27, 2017 at 06:34:17PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 27, 2017 at 06:25:32PM +0100, Jiri Olsa wrote:
> > > On Mon, Nov 27, 2017 at 06:12:03PM +0100, Peter Zijlstra wrote:
> > > > But what validates the input attr is the same as the event attr, aside
> > > > from those fields?
> > >
> > > we don't.. the attr serves as a holder to carry those fields
> > > into the function
> >
> > Then that's a straight up bug.
> >
> > > the current kernel interface does not check anything else
> >
> > Not enough, if the new attr would fail perf_event_open() it should also
> > fail this modify thing.
>
>
> On IRC you asked:
>
> <jolsa> peterz, I dont follow.. why should we check fields that we dont use?
>
> Suppose someone does:
>
> attr = malloc(sizeof(*attr)); // uninitialized memory
> attr->type = BP;
> attr->bp_addr = new_addr;
> attr->bp_type = bp_type;
> attr->bp_len = bp_len;
> ioctl(fd, PERF_IOC_MOD_ATTR, &attr);
>
> And feeds absolute shite for the rest of the fields.
>
> Then we later want to extend IOC_MOD_ATTR to allow changing
> attr::sample_type but we can't, because that would break the above
> application.
>
> Therefore we must be very strict to check only the fields we can change
> have changed.

The possible checks is infinite and checking against what was used in
perf_event_open will further complicate matters.
The original objective was very simple: allow bp_addr, bp_type, and
bp_len to be modified without the rest of the baggage.

\
 
 \ /
  Last update: 2017-11-27 22:51    [W:0.074 / U:4.988 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site