Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 1/2] bpf: add a bpf_override_function helper
To:     Ingo Molnar <mingo@kernel.org>, Josef Bacik <josef@toxicpanda.com>
References: <1510086523-8859-1-git-send-email-josef@toxicpanda.com>
 <1510086523-8859-2-git-send-email-josef@toxicpanda.com>
 <20171110093459.w2pvo3ntkwbmgnha@gmail.com>
 <20171110171428.hrw5cpxy4sgzf7mn@destiny>
 <20171111081455.qx4rodxldofbzypb@gmail.com>
CC:     <rostedt@goodmis.org>, <mingo@redhat.com>, <davem@davemloft.net>,
        <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <ast@kernel.org>, <kernel-team@fb.com>, <daniel@iogearbox.net>,
        Josef Bacik <jbacik@fb.com>
From:   Alexei Starovoitov <ast@fb.com>
Message-ID: <23fd1b7a-5c7d-8b11-adc5-7e6679b6e61e@fb.com>
Date:   Sun, 12 Nov 2017 14:49:22 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20171111081455.qx4rodxldofbzypb@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2017 06:49:35.3156 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7762d912-6b4c-4de4-3597-08d529998af2
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR15MB0974
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-12_02:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 11/11/17 4:14 PM, Ingo Molnar wrote:
>
> * Josef Bacik <josef@toxicpanda.com> wrote:
>
>> On Fri, Nov 10, 2017 at 10:34:59AM +0100, Ingo Molnar wrote:
>>>
>>> * Josef Bacik <josef@toxicpanda.com> wrote:
>>>
>>>> @@ -551,6 +578,10 @@ static const struct bpf_func_proto *kprobe_prog_func_proto(enum bpf_func_id func
>>>>  		return &bpf_get_stackid_proto;
>>>>  	case BPF_FUNC_perf_event_read_value:
>>>>  		return &bpf_perf_event_read_value_proto;
>>>> +	case BPF_FUNC_override_return:
>>>> +		pr_warn_ratelimited("%s[%d] is installing a program with bpf_override_return helper that may cause unexpected behavior!",
>>>> +				    current->comm, task_pid_nr(current));
>>>> +		return &bpf_override_return_proto;
>>>
>>> So if this new functionality is used we'll always print this into the syslog?
>>>
>>> The warning is also a bit passive aggressive about informing the user: what
>>> unexpected behavior can happen, what is the worst case?
>>>
>>
>> It's modeled after the other warnings bpf will spit out, but with this feature
>> you are skipping a function and instead returning some arbitrary value, so
>> anything could go wrong if you mess something up.  For instance I screwed up my
>> initial test case and made every IO submitted return an error instead of just on
>> the one file system I was attempting to test, so all sorts of hilarity ensued.
>
> Ok, then for the x86 bits:
>
>   NAK-ed-by: Ingo Molnar <mingo@kernel.org>
>
> One of the major advantages of having an in-kernel BPF sandbox is to never crash
> the kernel - and allowing BPF programs to just randomly modify the return value of
> kernel functions sounds immensely broken to me.
>
> (And yes, I realize that kprobes are used here as a vehicle, but the point
> remains.)

yeah. modifying arbitrary function return pushes bpf outside of
its safety guarantees and in that sense doing the same
override_return could be done from a kernel module if kernel
provides the x64 side of the facility introduced by this patch.
On the other side adding parts of this feature to the kernel only
to be used by external kernel module is quite ugly too and not
something that was ever done before.
How about we restrict this bpf_override_return() only to the functions
which callers expect to handle errors ?
We can add something similar to NOKPROBE_SYMBOL(). Like
ALLOW_RETURN_OVERRIDE() and on btrfs side mark the functions
we're going to test with this feature.
Then 'not crashing kernel' requirement will be preserved.
btrfs or whatever else we will be testing with override_return
will be functioning in 'stress test' mode and if bpf program
is not careful and returns error all the time then one particular
subsystem (like btrfs) will not be functional, but the kernel
will not be crashing.
Thoughts?


From 1583770416719769419@xxx Sat Nov 11 11:52:49 +0000 2017
X-GM-THRID: 1583463755336960738
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread