On 02/06/2020 18:32, Alexei Starovoitov wrote:
> The target for bpf codegen is JITs.
> bpf interpreter is simulating hw.
> For now if you want UB fuzzer running in your environment please add
> _out_of_tree_ patch that inits all interpreter registers to zero.
+1 to all the above.
Also, note that y
On Tue, Jun 02, 2020 at 03:31:40PM +0200, Alexander Potapenko wrote:
>
> So we're back to the question how much people care about the
> interpreter performance.
No. The question is whether people care about UB fuzzing.
>
> > > I don't have evidence that such a transformation is currently possib
On 29/05/2020 13:28, Alexander Potapenko wrote:> If the performance is really
critical here, perhaps a better
> alternative is to introduce a BPF instruction (which could be an alias
> of BPF_XOR REG, REG) for zeroing out a register? Then different
> architectures may choose more efficient impleme
On 29/05/2020 07:14, Dmitry Vyukov wrote:
>> (In C99 it gets subtler because an 'indeterminate value' is
>> defined to be 'either a valid value or a trap representation',
>> so arguably the compiler can only do this stuff if it _has_
>> trap representations for the type in question.)
> Interesti
On 28/05/2020 17:00, Alexei Starovoitov wrote:
> xoring of two identical values is undefined in standard?
I believe it is in this case, yes; even without the complication
of array references that happen to alias, Alexander's foo1() is
undefined behaviour under C89 (and also C99 which handles the
On Thu, May 28, 2020 at 2:54 AM Alexander Potapenko wrote:
>
> On Wed, May 27, 2020 at 7:15 PM Alexei Starovoitov
> wrote:
> >
> > On Wed, May 27, 2020 at 10:12 AM Alexander Potapenko
> > wrote:
> > >
> > > On Wed, May 27, 2020 at 6:58 PM Alexei Starovoitov
> > > wrote:
> > > >
> > > > On Wed,
On Wed, May 27, 2020 at 10:12 AM Alexander Potapenko wrote:
>
> On Wed, May 27, 2020 at 6:58 PM Alexei Starovoitov
> wrote:
> >
> > On Wed, May 27, 2020 at 8:52 AM Alexander Potapenko
> > wrote:
> > >
> > > This basically means that BPF's output register was uninitialized when
> > > ___bpf_prog
On Wed, May 27, 2020 at 6:58 PM Alexei Starovoitov
wrote:
>
> On Wed, May 27, 2020 at 8:52 AM Alexander Potapenko wrote:
> >
> > This basically means that BPF's output register was uninitialized when
> > ___bpf_prog_run() returned.
> >
> > When I replace the lines initializing registers A and X i
On Wed, May 27, 2020 at 8:52 AM Alexander Potapenko wrote:
>
> This basically means that BPF's output register was uninitialized when
> ___bpf_prog_run() returned.
>
> When I replace the lines initializing registers A and X in net/core/filter.c:
>
> - *new_insn++ = BPF_ALU32_REG(BPF_
On Tue, Dec 18, 2018 at 3:36 PM Alexander Potapenko wrote:
>
> On Thu, Dec 13, 2018 at 3:54 PM Daniel Borkmann wrote:
> >
> > On 12/13/2018 02:18 PM, Daniel Borkmann wrote:
> > > On 12/13/2018 01:24 PM, Alexander Potapenko wrote:
> > >> On Thu, Dec 13, 2018 at 1:20 PM Michal Kubecek wrote:
> > >
On Thu, Dec 13, 2018 at 3:54 PM Daniel Borkmann wrote:
>
> On 12/13/2018 02:18 PM, Daniel Borkmann wrote:
> > On 12/13/2018 01:24 PM, Alexander Potapenko wrote:
> >> On Thu, Dec 13, 2018 at 1:20 PM Michal Kubecek wrote:
> >>> On Thu, Dec 13, 2018 at 12:59:36PM +0100, Michal Kubecek wrote:
>
On Thu, Dec 13, 2018 at 2:18 PM Daniel Borkmann wrote:
>
> On 12/13/2018 01:24 PM, Alexander Potapenko wrote:
> > On Thu, Dec 13, 2018 at 1:20 PM Michal Kubecek wrote:
> >> On Thu, Dec 13, 2018 at 12:59:36PM +0100, Michal Kubecek wrote:
> >>> On Thu, Dec 13, 2018 at 12:00:59PM +0100, Alexander Po
On 12/13/2018 02:18 PM, Daniel Borkmann wrote:
> On 12/13/2018 01:24 PM, Alexander Potapenko wrote:
>> On Thu, Dec 13, 2018 at 1:20 PM Michal Kubecek wrote:
>>> On Thu, Dec 13, 2018 at 12:59:36PM +0100, Michal Kubecek wrote:
On Thu, Dec 13, 2018 at 12:00:59PM +0100, Alexander Potapenko wrote:
On 12/13/2018 01:24 PM, Alexander Potapenko wrote:
> On Thu, Dec 13, 2018 at 1:20 PM Michal Kubecek wrote:
>> On Thu, Dec 13, 2018 at 12:59:36PM +0100, Michal Kubecek wrote:
>>> On Thu, Dec 13, 2018 at 12:00:59PM +0100, Alexander Potapenko wrote:
Hi BPF maintainers,
some time ago KM
On Thu, Dec 13, 2018 at 1:20 PM Michal Kubecek wrote:
>
> On Thu, Dec 13, 2018 at 12:59:36PM +0100, Michal Kubecek wrote:
> > On Thu, Dec 13, 2018 at 12:00:59PM +0100, Alexander Potapenko wrote:
> > > Hi BPF maintainers,
> > >
> > > some time ago KMSAN found an issue in BPF code which we decided t
On Thu, Dec 13, 2018 at 12:59:36PM +0100, Michal Kubecek wrote:
> On Thu, Dec 13, 2018 at 12:00:59PM +0100, Alexander Potapenko wrote:
> > Hi BPF maintainers,
> >
> > some time ago KMSAN found an issue in BPF code which we decided to
> > suppress at that point, but now I'd like to bring it to your
On Thu, Dec 13, 2018 at 12:00:59PM +0100, Alexander Potapenko wrote:
> Hi BPF maintainers,
>
> some time ago KMSAN found an issue in BPF code which we decided to
> suppress at that point, but now I'd like to bring it to your
> attention.
> Namely, some BPF programs may contain instructions that XO
On Thu, Dec 13, 2018 at 12:06 PM Eric Dumazet wrote:
>
>
>
> On 12/13/2018 03:00 AM, Alexander Potapenko wrote:
> > Hi BPF maintainers,
> >
> > some time ago KMSAN found an issue in BPF code which we decided to
> > suppress at that point, but now I'd like to bring it to your
> > attention.
> > Nam
On 12/13/2018 03:00 AM, Alexander Potapenko wrote:
> Hi BPF maintainers,
>
> some time ago KMSAN found an issue in BPF code which we decided to
> suppress at that point, but now I'd like to bring it to your
> attention.
> Namely, some BPF programs may contain instructions that XOR a register
>
Hi BPF maintainers,
some time ago KMSAN found an issue in BPF code which we decided to
suppress at that point, but now I'd like to bring it to your
attention.
Namely, some BPF programs may contain instructions that XOR a register
with itself.
This effectively results in the following C code:
reg
20 matches
Mail list logo
