Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140627232056.GZ32514@n2100.arm.linux.org.uk>
Date: Sat, 28 Jun 2014 00:20:57 +0100
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Andy Lutomirski <luto@...capital.net>
Cc: musl@...ts.openwall.com, linux-arm-kernel@...ts.infradead.org,
	Kees Cook <keescook@...omium.org>
Subject: Re: Thread pointer changes

Right, I'm done on this thread for the weekend - I will not be answering
another message on this subject until next week.  In summary:

I've shown that this isn't as big a problem as first thought, because
there's ways that a libc can trivially detect the CPU that it is running
on, and from that know what instructions are available to it.

I've indicated that the kuser helpers are always provided when there
is no hardware TLS support, which corresponds with a minimum ARM
architecture of version 6K, and v6k has the atomic instructions.

I've said that we're not going to move kuser helpers to a randomised
address, and given strong reasons why not.

I've indicated where the CPU architecture can be retrieved from, and
used to determine the availability of other instructions.

I've indicated that the ELF HWCAPs can be used to further refine the
available instruction information.

That should be sufficient to answer all the questions raised.  Please
wait until next week before asking further questions, thanks.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.