Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp80227imm; Tue, 7 Aug 2018 14:19:08 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyl1gHSWSt7JmA73PHJTyV0gSWTsqPDFLVaP3bOwReY+VDGaHOM6rx/V6A2WqYS1CAMJwcw X-Received: by 2002:a65:5b08:: with SMTP id y8-v6mr57968pgq.297.1533676748851; Tue, 07 Aug 2018 14:19:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533676748; cv=none; d=google.com; s=arc-20160816; b=RyIyPY3YSr+YsthRPMCFPFsPHmP2qBaBGt/mTcxoPYugxqrvyZ4kMW+i6voPw3Dkye qYA6rsPcoLlaaL/dTC1EQwzdoQ2CroCRYNMPkaQZUMhGg7f15KP/H6yTjjvjnM9GPGN7 JOv0A2K2JhuNYZtRzjw43C8q6VwLe/xBqx/2m+ZkjYwVYsZWplrzKJie9P6vw6ISo6lz 7LUsyrTRzqEooCIKYxN9OP+Am8n5Q5lvcxLYzQuggb+Fs2NFK8GpzGaT3m/n+f+MMx/5 LMRqj249fX/un2SWUaBNm6S47Eeo9VR2oVs3xL98rTMwIaUoUL/oZ8GEG2uZ8WUgkW4p S6pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=2cy9U1vTn9IA0+AqalecdRCMfJ1TM2uDfyi/7CKif+Y=; b=ItLHaHcVqFIlp/a+1aufzKJaQ+PfjRJLojMnZlws9NLxr7RM6uMubRBr+RXst9azUz qio1WsyMVdrYSD3us/3bPLT//4bUcmyIWtCsjVPfSeodTt2ijffWdeLt3LFPfA7xQ0Yp PDCoTaHjCWS2jLk22E/aHAzvdtEgWPBRdkmvnJ48EVMVjdCE/nFIXcYS1KSkMNmcokvK S+sppBqzqxIdsDpz+LN9jwGnrMrYSdz7e/jKuJDNBPe1xfkpA4+78R8XO+26vmV5x77q fuxpBTipnUrkBn7vafzn0Cpvh31DYafIOGtIGIPDliCFBPNXtq03kGQxWkwDhNF9NWil PWSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=DbBPx7xp; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e36-v6si2036444pge.507.2018.08.07.14.18.53; Tue, 07 Aug 2018 14:19:08 -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=pass header.i=@google.com header.s=20161025 header.b=DbBPx7xp; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726873AbeHGXeX (ORCPT + 99 others); Tue, 7 Aug 2018 19:34:23 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:33174 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726414AbeHGXeX (ORCPT ); Tue, 7 Aug 2018 19:34:23 -0400 Received: by mail-oi0-f67.google.com with SMTP id 8-v6so217630oip.0 for ; Tue, 07 Aug 2018 14:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2cy9U1vTn9IA0+AqalecdRCMfJ1TM2uDfyi/7CKif+Y=; b=DbBPx7xpDdPeRb/pETjFwCMBlfb+OQUli9+5NEVpjfuzdACcKXpNXsgCtbhyy/snRm zrvkQ4rKhOEDQKrVVtLS8p9PToL2xAfufcESNdoPfN7BtKKgS/IsSImfgufdpGdkRtVm 4/6NiqDsAVr6AOvB4J9vTDnysKFMmn3O9RC2w6GhbhCAsJgG2rAuX42kYhq50HjGA8l5 nd5FeXIf5pSkWpHC0LoGjNXkS7ZZtzSCtwsJ+2GomDsxJO9y0pRk/iXuiIzJ9jfErFyF 3Iknd0eA3NQyyc1Takb0kbbSXxNTULHWf5rHnWqy+1mAFZh0hIHqHG/kPRamDe+BPtcs k21A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2cy9U1vTn9IA0+AqalecdRCMfJ1TM2uDfyi/7CKif+Y=; b=j4q5fMQblQpnM62HMPPRyoY8LaDJ40jmLKp6fef5e6Pp6BaxxVoQapzxbP2cJBOzuL df45lq+Z03nKcH+dY9vpBTwzSF+arusDVgLXZI75uhP5MFFI4Dkd8Cnw3R59wzvLhYzV piq7gsz9j5pkDvck6LUMR2SaKkUaIDOHhRDV2ISOLJAJB9TXSWVBqCwbYCrqnRsb4fgB 1GiPz4EqAtLfwM1/3RWklo8mLrA4re/jRIKcVSJsPgJQozv7rhPcBenzDlsDpj819suJ bVvGeLu6HfWbwg+lbNrv8+iEurBLBtks5lqJ06GSH5QamBZHoFT8rn+07KOX0EucoUP5 3Buw== X-Gm-Message-State: AOUpUlEevqfpzBhN/oQOELCD+EJPQ0ob2mzRL9xCeHnVDZeS4XhrEXjg g0oyn3MhtK49J8o03AhZIzAh26neS9ANNUqAFlQ2eg== X-Received: by 2002:aca:180b:: with SMTP id h11-v6mr101517oih.91.1533676684002; Tue, 07 Aug 2018 14:18:04 -0700 (PDT) MIME-Version: 1.0 References: <20180807012257.20157-1-jannh@google.com> In-Reply-To: From: Jann Horn Date: Tue, 7 Aug 2018 23:17:37 +0200 Message-ID: Subject: Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses To: Andy Lutomirski Cc: Kees Cook , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , "the arch/x86 maintainers" , Kernel Hardening , kernel list , Andy Lutomirski , Dmitry Vyukov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 7, 2018 at 4:55 AM Andy Lutomirski wrote: > > On Aug 6, 2018, at 6:22 PM, Jann Horn wrote: > > > > There have been multiple kernel vulnerabilities that permitted userspac= e to > > pass completely unchecked pointers through to userspace accessors: > > > > - the waitid() bug - commit 96ca579a1ecc ("waitid(): Add missing > > access_ok() checks") > > - the sg/bsg read/write APIs > > - the infiniband read/write APIs > > > > These don't happen all that often, but when they do happen, it is hard = to > > test for them properly; and it is probably also hard to discover them w= ith > > fuzzing. Even when an unmapped kernel address is supplied to such buggy > > code, it just returns -EFAULT instead of doing a proper BUG() or at lea= st > > WARN(). > > > > This patch attempts to make such misbehaving code a bit more visible by > > WARN()ing in the pagefault handler code when a userspace accessor cause= s > > #PF on a kernel address and the current context isn't whitelisted. > > I like this a lot, and, in fact, I once wrote a patch to do something sim= ilar. It was before the fancy extable code, though, so it was a mess. Here= are some thoughts: > > - It should be three patches. One patch to add the _UA annotations, one t= o improve the info passes to the handlers, and one to change behavior. > > - You should pass the vector, the error code, and the address to the hand= ler. > > - The uaccess handler should IMO WARN if the vector is anything other tha= n #PF (which mainly means warning if it=E2=80=99s #GP). I think it should p= r_emerg() and return false if the vector is #PF and the address is too high= . What about #MC? do_machine_check() sometimes invokes fixup handlers. It looks like fixup_exception() is basically reached for anything that can't be restarted (either MCG_STATUS_RIPV isn't set or the worst severity is MCE_AR_SEVERITY), but doesn't reach MCE_PANIC_SEVERITY? In particular for "Action required: data load in error recoverable area of kernel", if I'm reading the code correctly. It seems like the code is intentionally preventing memory errors during user access from being treated as kernel memory errors? So perhaps #MC in user access should not WARN()? > - Arguably most non-uaccess fixups should at least warn for anything othe= r than #GP and #UD.