linux-kernel - Re: [GIT PULL] x86 trampoline rework for 3.5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 May 2012 20:07:42 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Borislav Petkov <bp@...en8.de>,
	"H.J. Lu" <hjl.tools@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Ingo Molnar <mingo@...nel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@...el.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Len Brown <len.brown@...el.com>, Len Brown <lenb@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg@...hat.com>,
	Michal Marek <mmarek@...e.cz>,
	Paolo Bonzini <pbonzini@...hat.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Sam Ravnborg <sam@...nborg.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] x86 trampoline rework for 3.5

On 05/29/2012 07:37 PM, Linus Torvalds wrote:
> 
> but in your branch that "^pa_" pattern is duplicated for S_REL:
> 
>  /*
>   * These symbols are known to be relative, even if the linker marks them
>   * as absolute (typically defined outside any section in the linker script.)
>   */
>         [S_REL] =
>         "^pa_",
> 
>  /*
>   * These are 16-bit segment symbols when compiling 16-bit code.
>   */
>         [S_SEG] =
>         "^real_mode_seg$",
> 
>  /*
>   * These are offsets belonging to segments, as opposed to linear addresses,
>   * when compiling 16-bit code.
>   */
>         [S_LIN] =
>         "^pa_",
> 
> which looks odd.
> 
> But that case with three patterns is the one you selected in your
> merge - *not* the current state of relocs.c that you claim should be
> selected.
> 

Sorry, you're right.  The version with three patterns is correct.  The
"^pa_" patterns are linear addresses which should be treated as
relative, and so belong both to S_REL and S_LIN.  This didn't surface as
a conflict, so I forgot to flag it.

> So I'm not pulling or merging anything until I understand what's going
> on. Should I take the two-pattern one (which is what I have now, and
> that seems sensible), or should that "^pa_" pattern really be merged
> for two different cases (doesn't that just mean that the last one will
> effectively override the first one)?
> 
> Also, your branch adds an "x86-relocs" thing to the scripts/.gitignore
> file that you seem to have removed in the merge. What was going on
> there?

That line should have been removed in checkin f2604c14 but wasn't; since
that was one of the checkins that got folded up into 6520fe55 I cleaned
it up at that time.

	-hpa
-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/