Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5815992imm; Tue, 26 Jun 2018 19:24:25 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJj9GnQTMxXuHJjDo5IxUOj//K2EafPak4dbaX9fTWP+l53+F7haGzPeX55nuwuYh0M6hGK X-Received: by 2002:a63:7f4e:: with SMTP id p14-v6mr3422651pgn.27.1530066264993; Tue, 26 Jun 2018 19:24:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530066264; cv=none; d=google.com; s=arc-20160816; b=p2CnkZrqq75j9uVDagJPfjL1Bp+XDpsoKXXeohvTi3OxpiFA2VUXs46MRgXW5uN/vK swd/93HyKhg+kDvBAVozokgoVDWXE9xVOw9m675As1MQmq1rcQUj2CqIDXSHKTeLAaEO DIUtfVmEW7UsLNo7fRw3i8S/wx0HS19T5UtwRndlUkA3Jerzr9nA8wtljtIWB53ssxpJ FPlIns148vvYqkON9wz1rBd7CxJ02xuOxDg5Qc/jF9F4eXOofAD/OV0c3yys+2H1Vlmz 0T05Zs+EVeqYPSrdeG7MidM9H3pF8ZklYJaNBSPWJeEqF7uHb943vVU1immoi2/LIRkr WneQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=y6lxYohc24doOq4uCkFytsJeC9N6NKtK8Luo156ZlQ0=; b=PpTEoAHpALvtOPv9p0V1YcycdnOBfWgIEUAzOSPYS3NV8si2yKohyWlO2KEDdxeeF3 MNYNrhmzFAIsXKC83fbxy+0wQ7iZxVe1vUOWudq8k4dyDtZi5Ux+qRmFK11H7bSnoIFY /YUlPYG0TKJYQDWPz8oC9SSzu5Ak49JiDzYGUR3Jzebi9GcbbS9z1BoIlS52+LkGaK8d 7j7V5QnJIOIv4n+NNDeOWmwkN/5nfQRBfOGyroP+piyb/A3/5gCJCAkC3jZ8y2vBXOQ2 k7N1NKIj4JOjKPb0nmklscZb6OqfQEF96qpP2elImvTG96n8YH5hj8syuD/G4OEkHadw 54Sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=mBIszP4d; dkim=fail header.i=@chromium.org header.s=google header.b=MleXalUt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si2695196plv.16.2018.06.26.19.24.09; Tue, 26 Jun 2018 19:24:24 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=mBIszP4d; dkim=fail header.i=@chromium.org header.s=google header.b=MleXalUt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754636AbeF0A0F (ORCPT + 99 others); Tue, 26 Jun 2018 20:26:05 -0400 Received: from mail-yb0-f176.google.com ([209.85.213.176]:39671 "EHLO mail-yb0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751680AbeF0A0D (ORCPT ); Tue, 26 Jun 2018 20:26:03 -0400 Received: by mail-yb0-f176.google.com with SMTP id k127-v6so96495ybk.6 for ; Tue, 26 Jun 2018 17:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=y6lxYohc24doOq4uCkFytsJeC9N6NKtK8Luo156ZlQ0=; b=mBIszP4dfvNY8YK8SUJrC92fNtdAH1+Sr0PK0/JQnDQI/iXx3XFomQXpVJwN9eweDw dBA+xboRASJR14dCZ//moefaROLjE5/J3jJwAFp/r3fvzeBICPKPIkpXGyVgYjLLzYbA 0N/LtkE/ghMUm21gcWbi/TH87YZ/YDrGxweBb3mHE0QxkyvemwQY6uBSbGKUC7/TTN6D RQDLi0s5Pp4/hgJmc5dG19xo8DMo7d7SlcOtMjV/jsfEFaZZyvYSYKK3qsrxqzcVlfXT r830EH0UceMsckbRfPjyxiAANG/nlGDfBVphrWb+1EoY/z5dk2NxJ0hLsbXxGo3Z6H6n y6sw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=y6lxYohc24doOq4uCkFytsJeC9N6NKtK8Luo156ZlQ0=; b=MleXalUtu5Hc7JohQMDaxkCe9QEdM08MMEkrSkZz8SU1PDGWmZHG2/kflaz3omYFEF HD467HX+Q+Ih2HkcmfWuPV/dMQHLqQKlvIWstrPxww6vvMgZHJNmohEc5v9WQSb4pJXq 6t/OC7Sb/eyk/5hKp8MI64HKXe0b6bjchIGcA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=y6lxYohc24doOq4uCkFytsJeC9N6NKtK8Luo156ZlQ0=; b=UoaVBgwN7QkgayW0OwQqqAjkLr+M3H7IxnCIDddjA1eh2kmZeKFH7+knyBZS+6TZ8z LLTlX+Hn+JhldaLi/70MfxxmtrDJ3QVKI9DghBeVjxz9uOB2BFiW9j2NNpVaI4kE9HLL WBw2sgidghRFVRaAgr2EapOohEBC3H+nVgUnV+8UhOcL65LOYvhQdyMAOnazNOMrLa2a 5FbUzyRQE1NqMjGhBVfdFm3Z9Yy2jgDQIqn9FhWl5ewDydJtGki6JQ66gJN2Mfuy+whT Em+NRjgrcRPJJxywifIjPIhwgH0GmYfyzZ4lxluFL3J3rcQkO1QHYlL8j7M6er/A67uF nveg== X-Gm-Message-State: APt69E3fAuCbZdbv9zdd192721M/zUy/A4SxkrbRR5jElG5/PG0Ot6n7 EKQnHN9pcyPYPu56GFojuPQSRuPbf34lozlW3mMIcg== X-Received: by 2002:a25:be4e:: with SMTP id d14-v6mr1918092ybm.309.1530059162260; Tue, 26 Jun 2018 17:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:5f51:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 17:26:01 -0700 (PDT) In-Reply-To: References: <000000000000d48c8e056f5b6c67@google.com> <20180624.161411.1560796210597132716.davem@davemloft.net> <20180624100249.GA9493@gmail.com> From: Kees Cook Date: Tue, 26 Jun 2018 17:26:01 -0700 X-Google-Sender-Auth: NCQUYs85eWcEg5IrG5CBinj2OYA Message-ID: Subject: Re: set_memory_* (was: Re: BUG: unable to handle kernel paging request in bpf_int_jit_compile) To: Daniel Borkmann Cc: Ingo Molnar , David Miller , Thomas Gleixner , syzbot+a4eb8c7766952a1ca872@syzkaller.appspotmail.com, Alexei Starovoitov , "H. Peter Anvin" , Alexey Kuznetsov , LKML , Ingo Molnar , Network Development , syzkaller-bugs@googlegroups.com, X86 ML , Hideaki YOSHIFUJI , Peter Zijlstra , Laura Abbott , Linus Torvalds , Eric Dumazet , Rik van Riel , Ard Biesheuvel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 26, 2018 at 3:53 PM, Daniel Borkmann wrote: > In any case, for pairs like set_memory_ro() + set_memory_rw() that are also used > outside of bpf e.g. STRICT_MODULE_RWX and friends which are mostly default these > days for some archs, is the choice to not check errors from there by design or from > historical context that it originated from 'debugging code' in that sense (DEBUG_RODATA / > DEBUG_SET_MODULE_RONX) earlier? Also if no-one checks for errors (and if that would > infact be the recommendation it is agreed upon) should the API be changed to void, > or generally should actual error checking occur on these + potential rollback; but > then question is what about restoring part from prior set_memory_ro() via set_memory_rw()? > Kees/others, do you happen to have some more context on recommended use around this > by any chance? (Would probably also help if we add some doc around assumptions into > include/linux/set_memory.h for future users.) If set_memory_* can fail, I think it needs to be __must_check, and all the callers need to deal with it gracefully. Those markings aren't "advisory": they're expected to actually do what they say. -Kees -- Kees Cook Pixel Security