On 11/5/20 12:21 PM, KP Singh wrote:
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).
+1
I think the complete sample should be discarded if the size is too big and an
E2BIG / or some error should be returned.
Right, just let the helper bail out early and then BPF prog would be able to react to
E2BIG exception internally (e.g. shrinking sample size, logging error, etc).
Thanks,
Daniel
