[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202203161242.E778E35E8@keescook>
Date: Wed, 16 Mar 2022 12:43:27 -0700
From: Kees Cook <keescook@...omium.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"Luck, Tony" <tony.luck@...el.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
"Brown, Len" <len.brown@...el.com>
Subject: Re: [PATCH 1/3] x86: Separate out x86_regset for 32 and 64 bit
On Wed, Mar 16, 2022 at 07:06:48PM +0000, Edgecombe, Rick P wrote:
> 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.
Right, that's fine: the instructions should be the same, just with
various different offsets.
--
Kees Cook
Powered by blists - more mailing lists