On Tue, 2022-03-15 at 19:48 -0700, Kees Cook wrote: > On Tue, Mar 15, 2022 at 09:53:13PM +0000, Edgecombe, Rick P wrote: > > On Tue, 2022-03-15 at 13:41 -0700, Kees Cook wrote: > > > Have you verified there's no binary difference in machine code > > > output? > > > > There actually was a different in the binaries. I investigated a > > bit, > > and it seemed at least part of it was due to the line numbers > > changing > > the WARN_ON()s. But otherwise, I assumed some compiler optimization > > must have been bumped. > > Right, you can ignore all the debugging line number changes. > "diffoscope" should help see the difference by section. As long as > the > actual object code isn't changing, you should be good. What I did originally was objdump -D ptrace.o and diff that. Then I slowly reduced changes to see what was generating the difference. When I maintained the line numbers from the original version, and simply converted the enum to defines, it still generated slightly different code in places that didn't seem to connected to the changes. So I figured the compiler was doing something, and relied on checking that the actual constants didn't change in value. This morning I tried again to figure out what was causing the difference. If I strip debug symbols, remove the BUILD_BUG_ON()s and reformat the enums such that the line numbers are the same below the enums then the objdump output is identical. I think what is happening in this debug stripped test, is that in the call's to put_user(), it calls might_fault(), which has a __LINE__. But even adding a comment to the base file has surprisingly wide effects. It caused the __bug_table section table to get code generated with different instructions, not just line numbers constants changing. So I think there should be no functional change, but the binaries are not identical.
