> -----Original Message----- > From: KP Singh <kpsingh@xxxxxxxxxxxx> > Sent: 05 November 2020 11:21 > To: Kevin Sheldrake <Kevin.Sheldrake@xxxxxxxxxxxxx> > Cc: bpf@xxxxxxxxxxxxxxx; Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx>; KP > Singh <kpsingh@xxxxxxxxxx> > Subject: [EXTERNAL] Re: [PATCH bpf-next] Update perf ring buffer to > prevent corruption > > On Thu, Nov 5, 2020 at 11:41 AM Kevin Sheldrake > <Kevin.Sheldrake@xxxxxxxxxxxxx> wrote: > > > > From 8425426d0fb256acf7c2e50f0aa642450adc366a Mon Sep 17 00:00:00 > 2001 > > From: Kevin Sheldrake <kevin.sheldrake@xxxxxxxxxxxxx> > > Date: Wed, 4 Nov 2020 15:42:54 +0000 > > Subject: [PATCH] Update perf ring buffer to prevent corruption from > > bpf_perf_output_event() > > > > The bpf_perf_output_event() helper takes a sample size parameter of > u64, but > > the underlying perf ring buffer uses a u16 internally. This 64KB maximum > size > > has to also accommodate a variable sized header. Failure to observe this > > restriction can result in corruption of the perf ring buffer as samples > > overlap. > > > > Truncate the raw sample type used by EBPF so that the total size of the > > sample is < U16_MAX. The size parameter of the received sample will > match the > > size of the truncated sample, so users can be confident about how much > data > > was received. > > > > I don't think truncation without any indication to the user is a good > idea and can lead to other surprising problems > (especially when the userspace expects the data to be in a certain format, > which it almost always does). > > I think the complete sample should be discarded if the size is too big and an > E2BIG / or some error should be returned. I'm happy to do either; I'll make an alternative that just returns an error. Thanks Kev
