Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp632673ybj; Tue, 5 May 2020 05:14:24 -0700 (PDT) X-Google-Smtp-Source: APiQypKuMHjd0SZRbsM9fu/k2nPFxOtehSuRgedbReVEiVd/Y6or/To43EuP14Z2OJX/CJ5R8abe X-Received: by 2002:a50:ea87:: with SMTP id d7mr2232336edo.48.1588680864787; Tue, 05 May 2020 05:14:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588680864; cv=none; d=google.com; s=arc-20160816; b=sQxE/QKE+lZ4rrxmlExx1o7nEsI5BE9QP9WZlwyd805352/p/TFhsPV32vMoCh7wK0 oKLDRCvAPL3yLjSsyvRBZd6+FcxZ/2XOsWNeDOp245A1ls+ltlWZoTmvs4dHp/szLTr/ WUMIdHkLP6vVBE6Yp0BIXSwVpyik97gOxnufDk6+UjXFZJi9+MQ30qfogXd660MJCe4a 5RbwEEuQrkBu4M+iiWPKOtXcz1RHl2pjDgcXLpGqMObEhBuuMH8aI9Udyt2SHEa0z2WU tVF9X/6TuW6wP28zeUgk3Fsx18jR0IuCR9GMa0NEfb+VtizH/RQXYraO9NZgIBFt89jT 1ilg== 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 :in-reply-to:references:mime-version:dkim-signature; bh=HMlQVlmeGXEReM1yut17rciX4AB+fLsrubK71t43Crw=; b=YMBAhHU2ND1yyZT43q8kXnIoIsrMppnEBE5ZMUJmt9bNEDZnIqh1c8GnH+5tPGD0y5 0fGTvjyXwA/J3z0+/Ma4UBdLDuTJhyXoDohfTjTr7B6HEAriDESa+SREtMziH8cyGVvm e0kxKBL3g3WvkbsvAa6vjE+xDtcp3Zb4qGp+PCcG/T+65O5AmxjuPK8I5jKv3tjsOKrp /5bOcRZLrx6e45CBPuuJO1ph6zQErsD9EnfnkCwnsjvRbpKDuCcvmF5tdruwe1F5q+wp gxuKeuYLMx9i5rGdriPpnbmlf54ihBwq4HJUHKqYYJZAFdy/ReeW7E5Jq4/3dsW4CgKi g3sQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=by3szt0l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id z21si1167380edq.21.2020.05.05.05.14.01; Tue, 05 May 2020 05:14:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=by3szt0l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728914AbgEEMMU (ORCPT + 99 others); Tue, 5 May 2020 08:12:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727090AbgEEMMU (ORCPT ); Tue, 5 May 2020 08:12:20 -0400 Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9B35C061A0F for ; Tue, 5 May 2020 05:12:19 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id a21so1331692ljb.9 for ; Tue, 05 May 2020 05:12:19 -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; bh=HMlQVlmeGXEReM1yut17rciX4AB+fLsrubK71t43Crw=; b=by3szt0lWsRCqGRiMrxe/DgyNqYcEB22A1vW7AGwPkpIAuTE8oTuowy/tHPlyU+7Hr zYnWeZRfy5tq+4ogzarERxS6xYJVm19GSgbX8tCVHhxBJ+SXzTKDp6UOEj+g8ZYD6maI 5zC94pX1b6XXgSs+iK/KYtRP0lrbaJNqa+b17nx/Jh2t8Bj2w4nwY0gznMIe3O85N/5L ZWkvbqczD9hQBD0yFVF+8CZnAG0B3c4Ufu9iJA61VnJGsVPAdILBJOy7VoA9Bza4pCOC k8EAwrX3zVhivffKg6X3aIVE2IrZjmKTacUz1hFTq5dnfV/aj9L1vZXyRf0GMC//S2I2 VqYA== 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; bh=HMlQVlmeGXEReM1yut17rciX4AB+fLsrubK71t43Crw=; b=pqBNudw0inH0Cx6njfmelkJhPtYfxft+KDO9a1pik6XLo3hJaJy1NK42G+xThkMWbo AgkZWLgIXBXLIgIjuKq1QO+4VUlX57XzHvN0QTkGbyzHii67swL/azy6JPLHYoMZmGYc 5bblzqL9p9QdOqkc3Zcx5B4BXFHC9IROtDgQDvwQnrZcg9Ig16o/WYpzSGTqMe6264Dl G2boBN2ulvYcM1vVvETkcx9tUnQcvy6Wyu0TIvI5Catg4PKmgIjnqWgv7RpVqm1bxgq6 p9CTLF5aS7z6Uwus5wzDxXsl0cWFvp+Jw4NBYAXXVV/wOqd9iAd1jzXiOXjYm7CHOcAS dyug== X-Gm-Message-State: AGi0PubWTiPWUo6RCDZhz5fgRrJoCczZuJCuVR8cTGoTOhMsyhYngPBv oqHQ6u5hpbGlHszP3DJC3paaoSspY38tc5jXWQQzZg== X-Received: by 2002:a2e:b249:: with SMTP id n9mr1688630ljm.221.1588680737938; Tue, 05 May 2020 05:12:17 -0700 (PDT) MIME-Version: 1.0 References: <20200429214954.44866-1-jannh@google.com> <20200429214954.44866-5-jannh@google.com> <20200505110358.GC17400@lst.de> In-Reply-To: <20200505110358.GC17400@lst.de> From: Jann Horn Date: Tue, 5 May 2020 14:11:51 +0200 Message-ID: Subject: Re: [PATCH v2 4/5] binfmt_elf, binfmt_elf_fdpic: Use a VMA list snapshot To: Christoph Hellwig Cc: Andrew Morton , Linus Torvalds , kernel list , Linux-MM , linux-fsdevel , Alexander Viro , "Eric W . Biederman" , Oleg Nesterov , Russell King , Linux ARM , Mark Salter , Aurelien Jacquiot , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Rich Felker , Linux-sh list 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, May 5, 2020 at 1:04 PM Christoph Hellwig wrote: > On Wed, Apr 29, 2020 at 11:49:53PM +0200, Jann Horn wrote: > > In both binfmt_elf and binfmt_elf_fdpic, use a new helper > > dump_vma_snapshot() to take a snapshot of the VMA list (including the gate > > VMA, if we have one) while protected by the mmap_sem, and then use that > > snapshot instead of walking the VMA list without locking. [...] > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > > index fb36469848323..dffe9dc8497ca 100644 > > --- a/fs/binfmt_elf.c > > +++ b/fs/binfmt_elf.c > > @@ -1292,8 +1292,12 @@ static bool always_dump_vma(struct vm_area_struct *vma) > > return false; > > } > > > > +#define DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER 1 > > + > > /* > > * Decide what to dump of a segment, part, all or none. > > + * The result must be fixed up via vma_dump_size_fixup() once we're in a context > > + * that's allowed to sleep arbitrarily long. > > */ > > static unsigned long vma_dump_size(struct vm_area_struct *vma, > > unsigned long mm_flags) > > @@ -1348,30 +1352,15 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma, > > > > /* > > * If this looks like the beginning of a DSO or executable mapping, > > - * check for an ELF header. If we find one, dump the first page to > > - * aid in determining what was mapped here. > > + * we'll check for an ELF header. If we find one, we'll dump the first > > + * page to aid in determining what was mapped here. > > + * However, we shouldn't sleep on userspace reads while holding the > > + * mmap_sem, so we just return a placeholder for now that will be fixed > > + * up later in vma_dump_size_fixup(). > > */ > > if (FILTER(ELF_HEADERS) && > > - vma->vm_pgoff == 0 && (vma->vm_flags & VM_READ)) { > > - u32 __user *header = (u32 __user *) vma->vm_start; > > - u32 word; > > - /* > > - * Doing it this way gets the constant folded by GCC. > > - */ > > - union { > > - u32 cmp; > > - char elfmag[SELFMAG]; > > - } magic; > > - BUILD_BUG_ON(SELFMAG != sizeof word); > > - magic.elfmag[EI_MAG0] = ELFMAG0; > > - magic.elfmag[EI_MAG1] = ELFMAG1; > > - magic.elfmag[EI_MAG2] = ELFMAG2; > > - magic.elfmag[EI_MAG3] = ELFMAG3; > > - if (unlikely(get_user(word, header))) > > - word = 0; > > - if (word == magic.cmp) > > - return PAGE_SIZE; > > - } > > + vma->vm_pgoff == 0 && (vma->vm_flags & VM_READ)) > > + return DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER; > > > > #undef FILTER > > > > @@ -1381,6 +1370,22 @@ static unsigned long vma_dump_size(struct vm_area_struct *vma, > > return vma->vm_end - vma->vm_start; > > } > > > > +/* Fix up the result from vma_dump_size(), now that we're allowed to sleep. */ > > +static void vma_dump_size_fixup(struct core_vma_metadata *meta) > > +{ > > + char elfmag[SELFMAG]; > > + > > + if (meta->dump_size != DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER) > > + return; > > + > > + if (copy_from_user(elfmag, (void __user *)meta->start, SELFMAG)) { > > + meta->dump_size = 0; > > + return; > > + } > > + meta->dump_size = > > + (memcmp(elfmag, ELFMAG, SELFMAG) == 0) ? PAGE_SIZE : 0; > > +} > > While this code looks entirely correct, it took me way too long to > follow. I'd take te DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER into the caller, > and then have a simple function like this: > > static void vma_dump_size_fixup(struct core_vma_metadata *meta) > { > char elfmag[SELFMAG]; > > if (copy_from_user(elfmag, (void __user *)meta->start, SELFMAG) || > memcmp(elfmag, ELFMAG, sizeof(elfmag)) != 0) > meta->dump_size = 0; > else > meta->dump_size = PAGE_SIZE; > } I guess I can make that change, even if I personally think it's less clear if parts of the fixup logic spill over into the caller instead of being handled locally here. :P > Also a few comments explaining why we do this fixup would help readers > of the code. > > > - if (vma->vm_flags & VM_WRITE) > > - phdr.p_flags |= PF_W; > > - if (vma->vm_flags & VM_EXEC) > > - phdr.p_flags |= PF_X; > > + phdr.p_flags = meta->flags & VM_READ ? PF_R : 0; > > + phdr.p_flags |= meta->flags & VM_WRITE ? PF_W : 0; > > + phdr.p_flags |= meta->flags & VM_EXEC ? PF_X : 0; > > Sorry for another nitpick, but I find the spelled out version with the > if a lot easier to read. Huh... I find it easier to scan if it is three lines with the same pattern, but I'm not too attached to it. In that case, I guess I should change it like this? The old code had a ternary for VM_READ and branches for the other two, which didn't seem very pretty to me. phdr.p_flags = 0; if (meta->flags & VM_READ) phdr.p_flags |= PF_R; if (meta->flags & VM_WRITE) phdr.p_flags |= PF_W; if (meta->flags & VM_EXEC) phdr.p_flags |= PF_X; > > +int dump_vma_snapshot(struct coredump_params *cprm, int *vma_count, > > + struct core_vma_metadata **vma_meta, > > + unsigned long (*dump_size_cb)(struct vm_area_struct *, unsigned long)) > > Plase don't use single tabs for indentating parameter continuations > (we actually have two styles - either two tabs or aligned after the > opening brace, pick your poison :)) I did that because if I use either one of those styles, I'll have to either move the callback type into a typedef or add line breaks in the parameters of the callback type. I guess I can write it like this... int dump_vma_snapshot(struct coredump_params *cprm, int *vma_count, struct core_vma_metadata **vma_meta, unsigned long (*dump_size_cb)(struct vm_area_struct *, unsigned long)); but if you also dislike that, let me know and I'll add a typedef instead. :P > > + *vma_meta = kvmalloc_array(*vma_count, sizeof(**vma_meta), GFP_KERNEL); > > + if (!*vma_meta) { > > + up_read(&mm->mmap_sem); > > + return -ENOMEM; > > + } > > + > > + for (i = 0, vma = first_vma(current, gate_vma); vma != NULL; > > + vma = next_vma(vma, gate_vma)) { > > + (*vma_meta)[i++] = (struct core_vma_metadata) { > > + .start = vma->vm_start, > > + .end = vma->vm_end, > > + .flags = vma->vm_flags, > > + .dump_size = dump_size_cb(vma, cprm->mm_flags) > > + }; > > This looks a little weird. Why not kcalloc + just initialize the four > fields we actually fill out here? Yeah, I can just change the syntax here to normal member writes if you want. I just thought C99-style initialization looked nicer, but I guess that's unusual in the kernel... (And I just noticed that that "filesize" member of that struct core_vma_metadata I'm defining is entirely unused... I'll have to remove that in the next iteration.)