linux-kernel - Re: [PATCH 4/6] hw_breakpoint: Factor out __modify_user_hw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMmz+Ym9XSFvAL67u9R+8DsmNFmk-CMT4L0p5zc7PaEC4P0f7A@mail.gmail.com>
Date:   Mon, 27 Nov 2017 13:50:30 -0800
From:   Milind Chabbi <chabbi.milind@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Jiri Olsa <jolsa@...hat.com>, Jiri Olsa <jolsa@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        David Ahern <dsahern@...il.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Milind Chabbi <chabbi.milind@...il.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Hari Bathini <hbathini@...ux.vnet.ibm.com>,
        Jin Yao <yao.jin@...ux.intel.com>,
        Kan Liang <kan.liang@...el.com>,
        Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
        Oleg Nesterov <onestero@...hat.com>,
        Will Deacon <will.deacon@....com>
Subject: Re: [PATCH 4/6] hw_breakpoint: Factor out __modify_user_hw_breakpoint function

On Mon, Nov 27, 2017 at 1:20 PM, Peter Zijlstra <peterz@...radead.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.