linux-kernel - Re: [PATCH v6 1/4] x86: Clean up extable entry format (and free up a bit)

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:	Mon, 4 Jan 2016 11:05:14 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Tony Luck <tony.luck@...il.com>
Cc:	Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Dan Williams <dan.j.williams@...el.com>,
	Robert <elliott@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	linux-nvdimm <linux-nvdimm@...1.01.org>, X86-ML <x86@...nel.org>
Subject: Re: [PATCH v6 1/4] x86: Clean up extable entry format (and free up a bit)

On Mon, Jan 4, 2016 at 10:59 AM, Tony Luck <tony.luck@...il.com> wrote:
>> ----- begin comment -----
>>
>> The offset to the fixup is signed, and we're trying to use the high
>> bits for a different purpose.  In C, we could just do:
>>
>> u32 class_and_offset = ((target - here) & 0x3fffffff) | class;
>>
>> Then, to decode it, we'd mask off the class and sign-extend to recover
>> the offset.
>>
>> In asm, we can't do that, because this all gets laundered through the
>> linker, and there's no relocation type that supports this chicanery.
>> Instead we cheat a bit.  We first add a large number to the offset
>> (0x20000000).  The result is still nominally signed, but now it's
>> always positive, and the two high bits are always clear.  We can then
>> set high bits by ordinary addition or subtraction instead of using
>> bitwise operations.  As far as the linker is concerned, all we're
>> doing is adding a large constant to the difference between here (".")
>> and the target, and that's a valid relocation type.
>>
>> In the C code, we just mask off the class bits and subtract 0x20000000
>> to get the offset.
>>
>> ----- end comment -----
>
> But presumably those constants get folded together, so the linker
> is dealing with only one offset.  It doesn't (I assume) know that our
> source code added 0x20000000 and then added/subtracted some
> more.

Yes, indeed.

>
> It looks like we could just use:
> class0: +0x40000000
> class1: +0x80000000 (or subtract ... whatever doesn't make the linker cranky)
> class2: -0x40000000
> class3: don't add/subtract anything
>
> ex_class() stays the same (just looks at bit31/bit30)
> ex_fixup_addr() has to use ex_class() to decide what to add/subtract
> (if anything).
>
> Would that work?  Would it be more or less confusing?

That probably works, but to me, at least, it's a bit more confusing.
It also means that you need a table or some branches to compute the
offset, whereas the "mask top two bits and add a constant" approach is
straightforward, short, and fast.

Also, I'm not 100% convinced that the 0x80000000 case can ever work
reliably.  I don't know exactly what the condition that triggers the
warning is, but the logical one would be to warn if the actual offset
plus or minus the addend, as appropriate, overflows in a signed sense.
Whether it overflows depends on the sign of the offset, and *that*
depends on the actual layout of all the sections.

Mine avoids this issue by being shifted by 0x20000000, so nothing ends
up right on the edge.

--Andy



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/