> -----Original Message----- > From: Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> > Sent: 30 October 2020 18:20 > To: Kevin Sheldrake <Kevin.Sheldrake@xxxxxxxxxxxxx> > Cc: bpf@xxxxxxxxxxxxxxx; KP Singh <kpsingh@xxxxxxxxxx> > Subject: [EXTERNAL] Re: [PATCH bpf-next] bpf: update verifier to stop perf > ring buffer corruption > [...] > See [0] for some guidelines. I use git format-patch and git send-email for my > patch workflow. And please make sure your email client/editor wraps the > lines, it's hard to reply if the entire paragraph is one long line. Thank you for the references. Hopefully my newly submitted patch (with a new/appropriate subject line) addresses these issues. [...] > So -24 should have been a clue that something fishy is going on. Look at > perf_prepare_sample() in kernel/events/core.c. header->size (which is u16) > contains the entire size of the data in the perf event. This includes raw data > that you send with bpf_perf_event_output(), but it can also have tons of > other stuff (e.g., call stacks, LBR data, etc). > What gets added to the perf sample depends on how the perf event was > configured in the first place. And it happens automatically on each perf event > output. > > So, all that means that there could be no reliable static check in the verifier > which would prevent the corruption. It has to be checked by > perf_prepare_sample() in runtime based on the actual size of the sample. > We can do an extra check in verifier, but I wouldn't bother because it's never > going to be 100% correct. > Thank you again; I've built a check into perf_prepare_sample(). [...]
