From: Alexei Starovoitov <alexei.starovoitov@gmail.com> To: Andy Lutomirski <luto@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net>, Song Liu <songliubraving@fb.com>, Kees Cook <keescook@chromium.org>, Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>, Kernel Team <Kernel-team@fb.com>, Lorenz Bauer <lmb@cloudflare.com>, Jann Horn <jannh@google.com>, Greg KH <gregkh@linuxfoundation.org>, Linux API <linux-api@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, Chenbo Feng <chenbofeng.kernel@gmail.com> Subject: Re: RFC: very rough draft of a bpf permission model Date: Mon, 26 Aug 2019 17:34:29 -0700 Message-ID: <20190827003427.hcvrobr23uhqwmq5@ast-mbp> (raw) In-Reply-To: <CALCETrUARqcn8EmjcgMc8KP=4O5nZDMh=tcruEYvUgSzMKJUBw@mail.gmail.com> On Mon, Aug 26, 2019 at 05:05:58PM -0700, Andy Lutomirski wrote: > >> > >> The BPF verifier and interpreter, taken in isolation, may be extremely > >> safe, but attaching BPF programs to various hooks can easily take down > >> the system, deliberately or by accident. A handler, especially if it > >> can access user memory or otherwise fault, will explode if attached to > >> an inappropriate kprobe, hw_breakpoint, or function entry trace event. > > > > absolutely not true. > > This is not a constructive way to have a conversation. When you get > an email that contains a statement you disagree with, perhaps you > could try to give some argument as to why you disagree rather than > just saying "absolutely not true". Especially when you are talking to > one of the maintainers of the affected system who has a > not-yet-finished branch that addresses some of the bugs that you claim > absolutely don't exist. If it's really truly necessary, I can go and > write an example that will crash an x86 kernel, but I feel like it > would be a waste of everyone's time. Please do write an example and prove your earlier sensational statement that "can _easily_ take down the system" by attaching bpf to kprobe. Most of the functions where kprobes are not allowed are already marked by 'nokprobe'. All of them marked? Probably not. There could be places where kprobe will blow the system, but 1. it's not easy to do. unlike your claim 2. that issue has nothing to do with bpf safety guarantees. > How confident are you that the BPF program that calls bpf_probe_read() > on an MMIO address has well-defined semantics? How confident are you > that the system will still work if such a program runs? bpf_probe_read is a wrapper of probe_read. Nothing more. I'm confident that probe_read maintainers are doing good job. All of the bpf tracing is relying on existing kernel mechanisms like kprobe, uprobe, perf, probe_read, etc. bpf verifier cannot make them safer. If reading mmio via bpf_probe_read will trigger undesired hw behavior there is nothing bpf verifier can do about it.
next prev parent reply index Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20190627201923.2589391-1-songliubraving@fb.com> [not found] ` <20190627201923.2589391-2-songliubraving@fb.com> [not found] ` <21894f45-70d8-dfca-8c02-044f776c5e05@kernel.org> [not found] ` <3C595328-3ABE-4421-9772-8D41094A4F57@fb.com> [not found] ` <CALCETrWBnH4Q43POU8cQ7YMjb9LioK28FDEQf7aHZbdf1eBZWg@mail.gmail.com> [not found] ` <0DE7F23E-9CD2-4F03-82B5-835506B59056@fb.com> [not found] ` <CALCETrWBWbNFJvsTCeUchu3BZJ3SH3dvtXLUB2EhnPrzFfsLNA@mail.gmail.com> [not found] ` <201907021115.DCD56BBABB@keescook> [not found] ` <CALCETrXTta26CTtEDnzvtd03-WOGdXcnsAogP8JjLkcj4-mHvg@mail.gmail.com> [not found] ` <4A7A225A-6C23-4C0F-9A95-7C6C56B281ED@fb.com> [not found] ` <CALCETrX2bMnwC6_t4b_G-hzJSfMPrkK4YKs5ebcecv2LJ0rt3w@mail.gmail.com> [not found] ` <514D5453-0AEE-420F-AEB6-3F4F58C62E7E@fb.com> [not found] ` <1DE886F3-3982-45DE-B545-67AD6A4871AB@amacapital.net> [not found] ` <7F51F8B8-CF4C-4D82-AAE1-F0F28951DB7F@fb.com> [not found] ` <77354A95-4107-41A7-8936-D144F01C3CA4@fb.com> [not found] ` <369476A8-4CE1-43DA-9239-06437C0384C7@fb.com> 2019-07-30 20:24 ` [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf Andy Lutomirski 2019-07-31 8:10 ` Song Liu 2019-07-31 19:09 ` Andy Lutomirski 2019-08-02 7:21 ` Song Liu 2019-08-04 22:16 ` Andy Lutomirski 2019-08-05 0:08 ` Andy Lutomirski 2019-08-05 5:47 ` Andy Lutomirski 2019-08-05 7:36 ` Song Liu 2019-08-05 17:23 ` Andy Lutomirski 2019-08-05 19:21 ` Alexei Starovoitov 2019-08-05 21:25 ` Andy Lutomirski 2019-08-05 22:21 ` Andy Lutomirski 2019-08-06 1:11 ` Alexei Starovoitov 2019-08-07 5:24 ` Andy Lutomirski 2019-08-07 9:03 ` Lorenz Bauer 2019-08-07 13:52 ` Andy Lutomirski 2019-08-13 21:58 ` Alexei Starovoitov 2019-08-13 22:26 ` Daniel Colascione 2019-08-13 23:24 ` Andy Lutomirski 2019-08-13 23:06 ` Andy Lutomirski 2019-08-14 0:57 ` Alexei Starovoitov 2019-08-14 17:51 ` Andy Lutomirski 2019-08-14 22:05 ` Alexei Starovoitov 2019-08-14 22:30 ` Andy Lutomirski 2019-08-14 23:33 ` Alexei Starovoitov 2019-08-14 23:59 ` Andy Lutomirski 2019-08-15 0:36 ` Alexei Starovoitov 2019-08-15 11:24 ` Jordan Glover 2019-08-15 17:28 ` Alexei Starovoitov 2019-08-15 18:36 ` Andy Lutomirski 2019-08-15 23:08 ` Alexei Starovoitov 2019-08-16 9:34 ` Jordan Glover 2019-08-16 9:59 ` Thomas Gleixner 2019-08-16 11:33 ` Jordan Glover 2019-08-16 19:52 ` Alexei Starovoitov 2019-08-16 20:28 ` Thomas Gleixner 2019-08-17 15:02 ` Alexei Starovoitov 2019-08-17 15:44 ` Andy Lutomirski 2019-08-19 9:15 ` Thomas Gleixner 2019-08-19 17:27 ` Alexei Starovoitov 2019-08-19 17:38 ` Andy Lutomirski 2019-08-15 18:43 ` Jordan Glover 2019-08-15 19:46 ` Kees Cook 2019-08-15 23:46 ` Alexei Starovoitov 2019-08-16 0:54 ` Andy Lutomirski 2019-08-16 5:56 ` Song Liu 2019-08-16 21:45 ` Alexei Starovoitov 2019-08-16 22:22 ` Christian Brauner 2019-08-17 15:08 ` Alexei Starovoitov 2019-08-17 15:16 ` Christian Brauner 2019-08-17 15:36 ` Alexei Starovoitov 2019-08-17 15:42 ` Christian Brauner 2019-08-22 14:17 ` Daniel Borkmann 2019-08-22 15:16 ` Andy Lutomirski 2019-08-22 15:17 ` RFC: very rough draft of a bpf permission model Andy Lutomirski 2019-08-22 23:26 ` Alexei Starovoitov 2019-08-23 23:09 ` Andy Lutomirski 2019-08-26 22:36 ` Alexei Starovoitov 2019-08-27 0:05 ` Andy Lutomirski 2019-08-27 0:34 ` Alexei Starovoitov [this message] 2019-08-22 22:48 ` [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf Alexei Starovoitov
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=20190827003427.hcvrobr23uhqwmq5@ast-mbp \ --to=alexei.starovoitov@gmail.com \ --cc=Kernel-team@fb.com \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=chenbofeng.kernel@gmail.com \ --cc=daniel@iogearbox.net \ --cc=gregkh@linuxfoundation.org \ --cc=jannh@google.com \ --cc=keescook@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=lmb@cloudflare.com \ --cc=luto@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=songliubraving@fb.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
Linux-Security-Module Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \ linux-security-module@vger.kernel.org public-inbox-index linux-security-module Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module AGPL code for this site: git clone https://public-inbox.org/public-inbox.git