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=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=unavailable 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 127F2C10F05 for ; Tue, 26 Mar 2019 20:51:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D7C622087C for ; Tue, 26 Mar 2019 20:51:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="HSKraqn3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732512AbfCZUvF (ORCPT ); Tue, 26 Mar 2019 16:51:05 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:37625 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731940AbfCZUvE (ORCPT ); Tue, 26 Mar 2019 16:51:04 -0400 Received: by mail-wm1-f68.google.com with SMTP id v14so14464653wmf.2 for ; Tue, 26 Mar 2019 13:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=WUWufCSMYpcuZ1Q8U5VJuhgr37Yg/XhDeh/+r3Sv10M=; b=HSKraqn3SZcHLNFUJkumuEPmblFSGz8wVcgZaFj14FYIDpe651/GsNjhlUoVgug/Y7 L+AabMM7klnrVboYWvQgp89MBCMCCxdrJ5g68wLkOQGxdTtct1sHKVBh9+CJCT+rGTlW xNnmGPgev9UKCIXaOgoZiTe8StH7PJFUqVMkvHZtyc2Lc6ZD1TgLmaeZRJ+A4tGXumOS Wa6QRgwGAVCK9S7W48+NSh0nFOPK0kpmD+7DBEmS6hGFFadvT/yOJLaEdUfIhpZdzrZQ u6IrlXICeonoQyKDG3EosK+Yuq04p43b/OnpCxJq89ke286oGER9zADR0f4vfasq/G/p hgLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=WUWufCSMYpcuZ1Q8U5VJuhgr37Yg/XhDeh/+r3Sv10M=; b=hVaPpKflu0oxj2MnXwtzL2uUYImxYdKQcwwlKMZxOVXdUxEySCyWzUTTnPUUTym1oM 7B/ZQWawIqepULZfhFBSeW0z7u7VkNJ16UjqO5ejDrq2e0WF+BT/ckoRMS+Lu/k0WvNb G9I+IhUXiAXlNMpgJOMn1lije7dX2E76fdyn0jLrN9DhSMQ6GgvMJeFeKfHQzQKhOxqL lb8nOebSL7/F/F0b4LInbHM5AKgiftPE/6pGx2aJovzT90lsXQ6eeGfE98W1r6p6Sago gxXBhBaEdkL8KJxMOEqpY8tfSxwhKrTkiJuAOqTNsBiUZctek2VGkinV/0JTCoGG5Lbm OH9g== X-Gm-Message-State: APjAAAUotCYy/8BSov1z69bA3b8VjI1WG5plMD8jPplmW96lDXMrEDid ngR0S/5BPVozfg8ZE5QOcO/cuw== X-Google-Smtp-Source: APXvYqyma+psEB1bMfpQ/yy+FKsL2GSXCDjid46x7kVdsWH3vpbzl6lXaGmhi9VGGPMPOTdssfJZDA== X-Received: by 2002:a1c:c4cd:: with SMTP id u196mr9962254wmf.70.1553633462992; Tue, 26 Mar 2019 13:51:02 -0700 (PDT) Received: from LAPTOP-V3S7NLPL (cpc1-cmbg19-2-0-cust104.5-4.cable.virginm.net. [82.27.180.105]) by smtp.gmail.com with ESMTPSA id b204sm33714808wmh.29.2019.03.26.13.51.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 26 Mar 2019 13:51:02 -0700 (PDT) References: <1553623539-15474-1-git-send-email-jiong.wang@netronome.com> <1553623539-15474-4-git-send-email-jiong.wang@netronome.com> User-agent: mu4e 0.9.18; emacs 25.2.2 From: Jiong Wang To: Jann Horn Cc: Jiong Wang , Alexei Starovoitov , Daniel Borkmann , bpf@vger.kernel.org, Network Development , oss-drivers@netronome.com Subject: Re: [PATCH/RFC bpf-next 03/16] bpf: split read liveness into REG_LIVE_READ64 and REG_LIVE_READ32 In-reply-to: Date: Tue, 26 Mar 2019 20:50:58 +0000 Message-ID: <87lg114ax9.fsf@netronome.com> MIME-Version: 1.0 Content-Type: text/plain Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jann Horn writes: > On Tue, Mar 26, 2019 at 7:06 PM Jiong Wang wrote: >> >> In previous patch, we have split register arg type for sub-register read, >> but haven't touch read liveness. >> >> This patch further split read liveness into REG_LIVE_READ64 and >> REG_LIVE_READ32. Liveness propagation code are updated accordingly. >> >> After this split, customized actions could be defined when propagating full >> register read (REG_LIVE_READ64) or sub-register read (REG_LIVE_READ32). >> >> Signed-off-by: Jiong Wang > [...] >> @@ -1374,7 +1374,8 @@ static int check_stack_read(struct bpf_verifier_env *env, >> return -EACCES; >> } >> mark_reg_read(env, ®_state->stack[spi].spilled_ptr, >> - reg_state->stack[spi].spilled_ptr.parent); >> + reg_state->stack[spi].spilled_ptr.parent, >> + size == BPF_REG_SIZE); > > Isn't it possible to use a 4-byte read on the upper half of an 8-byte > stack slot? I think that's fine, and is irrelevant with zero-extension on register. If it is a 8-byte stack slot comes from spill of register, then the definition of the register should have been marked as needing zero-extension if that register was generated by sub-register write. Regards, Jiong > >> if (value_regno >= 0) { >> if (zeros == size) { >> /* any size read into register is zero extended, >> @@ -2220,7 +2221,8 @@ static int check_stack_boundary(struct bpf_verifier_env *env, int regno, >> * the whole slot to be marked as 'read' >> */ >> mark_reg_read(env, &state->stack[spi].spilled_ptr, >> - state->stack[spi].spilled_ptr.parent); >> + state->stack[spi].spilled_ptr.parent, >> + access_size == BPF_REG_SIZE); > > Same thing as above. > >> } >> return update_stack_depth(env, state, off); >> } > [...]