From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58BD8C43331 for ; Thu, 2 Apr 2020 14:39:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 257242073B for ; Thu, 2 Apr 2020 14:39:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="J9/iYRl4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729166AbgDBOjL (ORCPT ); Thu, 2 Apr 2020 10:39:11 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:41267 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732263AbgDBOjL (ORCPT ); Thu, 2 Apr 2020 10:39:11 -0400 Received: by mail-lf1-f65.google.com with SMTP id z23so2922523lfh.8 for ; Thu, 02 Apr 2020 07:39:09 -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=JWhv97rUkQ55GmpwguZZwsTI0ItFj9NJgEzeV7LWnGI=; b=J9/iYRl4yr/VeWgdT9NFvLQFjlwy5H9vpo6LQ2yn7l9woZDLdH0VYw/hVM/4ANrn0F kJlOo2C0eE1S/9MDJ/4OX9d74rOy3Xn7kpCNfTVBDnCtg+5C/cILyA99qv5Yk6E3e5go h598w3yPPMo8N05VZsydb7aGq/THBedVIruVgYI6Ltnu3sodFXYrajv+fqUOWNr6s+Kk HHFrMavEIF5CjAjskyfNTyam/7cYIIGL4AW7nHPfFKtKDrXeC9a1Czjn1Ht345tJ399o UhsbKsY6V55vw0FXGxqGLfxc3MMmWNsXOl71Gx0afAhOqOOYaa87lDfgnsfRwScTP3J6 9ctw== 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=JWhv97rUkQ55GmpwguZZwsTI0ItFj9NJgEzeV7LWnGI=; b=XBc0kGHgROVOrkwxFagUx1ReoBlPl2viWg1hiuNxm9lX+5fOAalveZ5eJFxfQR2heR 1idLPDDI4azqU+4BLDpENjDHJq3Eyh/6Bo3nD8pIil+mShmOLobtjheOVY69gOnI8R/J cPLDEHHrFGNt3GSee8E+Q4151bAKlasw4CQevAtQMKXHIfCcrVdxw7nluhRv50Q2DAr2 Uf3WiPg3StB2SiJ0fNVzEI1/CaPQcmyMk8hGNdSqkOQ1Yn3eEq71YjzuC7nHBW5Cgi9h cVWRH0CtsFHET6BoUOUv/P9rUcu0CgeGRcnUMNE6RweKOyvI/beByTUNJaYvCvfYj+Ok dEDQ== X-Gm-Message-State: AGi0Pua1yqWvfGUjv2Sg9WK/vmxjn80o9na+Z/FudMTGgEPKmRMSSvPN qWN0bk9NIU/rFTzvE2yKJFu/qC1D27n59SqkhySkRw== X-Google-Smtp-Source: APiQypKvCB2g4vVvIsuKTkjOiQsdbBiCN3hvgOmqDS9wl2fjZsNKW/7GM9acoWuCI7FCCNZ2qr/Q1Vaonslz9+/Ckzc= X-Received: by 2002:a19:700a:: with SMTP id h10mr2478353lfc.184.1585838348128; Thu, 02 Apr 2020 07:39:08 -0700 (PDT) MIME-Version: 1.0 References: <20200329004356.27286-1-kpsingh@chromium.org> <20200329004356.27286-8-kpsingh@chromium.org> <20200402040357.GA217889@google.com> <20200402043037.ltgyptxsf7jaaudu@ast-mbp> <20200402115306.GA100892@google.com> In-Reply-To: <20200402115306.GA100892@google.com> From: Jann Horn Date: Thu, 2 Apr 2020 16:38:41 +0200 Message-ID: Subject: Re: [PATCH bpf-next v9 7/8] bpf: lsm: Add selftests for BPF_PROG_TYPE_LSM To: KP Singh Cc: Alexei Starovoitov , bpf , Andrii Nakryiko , Brendan Jackman , Florent Revest , Thomas Garnier , Daniel Borkmann , Kees Cook , Paul Turner , Florent Revest , Brendan Jackman Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Apr 2, 2020 at 1:53 PM KP Singh wrote: > On 02-Apr 07:15, Jann Horn wrote: [...] > > I suspect that you're using different versions of libc, or something's > > different in the memory layout, or something like that. The brk region > > is used for memory allocations using brk(), but memory allocations > > using mmap() land outside it. At least some versions of libc try to > > allocate memory for malloc() with brk(), then fall back to mmap() if > > that fails because there's something else behind the current end of > > the brk region; but I think there might also be versions of libc that > > directly use mmap() and don't even try to use brk(). > > Yeah missed this that heap can also be allocated using mmap: [...] > I updated my test case to check for mmaps on the stack instead: [...] > + is_stack = (vma->vm_start <= vma->vm_mm->start_stack && > + vma->vm_end >= vma->vm_mm->start_stack); > > - if (is_heap && monitored_pid == pid) { > + if (is_stack && monitored_pid == pid) { > mprotect_count++; > ret = -EPERM; > } > > and the the logic seems to work for me. Do you think we could use > this instead? Yeah, I think that should work. (Just keep in mind that a successful mprotect() operation will split the VMA into three VMAs - but that shouldn't be a problem here, since you only do it once per process, and since you're denying the operation, it won't go through anyway.)