netdev - Re: [RFC PATCH v2 bpf-next 0/2] verifier liveness simplification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f5fc398f-2dca-645a-c465-cba64236e807@solarflare.com>
Date:   Thu, 4 Oct 2018 18:35:45 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Jiong Wang <jiong.wang@...ronome.com>, <ast@...nel.org>,
        <daniel@...earbox.net>
CC:     <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH v2 bpf-next 0/2] verifier liveness simplification

On 03/10/18 16:36, Jiong Wang wrote:
> On 28/09/2018 14:36, Edward Cree wrote:
> > But what you've described sounds interesting; perhaps it would also
> >  help later with loop-variable handling?
>
> Haven't considered how to use this for loop-variable handling, guess you mean
> applying what I have described to your previous loop detection RFC? I will look
> into your RFC later.

Tbh I was thinking more of John Fastabend's version (I'm not sure if he ever
 got round to posting patches, but he discussed the design towards the end of
 https://www.mail-archive.com/netdev@vger.kernel.org/msg216285.html ) which
 is building 'proper compiler data structures' and thus might be interested
 in proper use-def chains.  (Or it might not; I'm not really a compiler-guru
 so it's not immediately obvious to me.)

My approach was much less interested in the 'provenance' of the induction
 variable, just that it was increasing appropriately, so use-def chains are
 not really relevant to it.

-Ed