linux-kernel - Re: [GIT pull] x86 vdso updates

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:	Sun, 29 May 2011 11:51:20 +0200
From:	richard -rw- weinberger <richard.weinberger@...il.com>
To:	Andrew Lutomirski <luto@....edu>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT pull] x86 vdso updates

On Fri, May 27, 2011 at 5:05 PM, Andrew Lutomirski <luto@....edu> wrote:
> On Fri, May 27, 2011 at 10:59 AM, richard -rw- weinberger
> <richard.weinberger@...il.com> wrote:
>> On Fri, May 27, 2011 at 2:10 PM, Andrew Lutomirski <luto@....edu> wrote:
>>> On Fri, May 27, 2011 at 7:59 AM, richard -rw- weinberger
>>> If this is considered enough of a regression, then I guess we can
>>> leave vsyscall64 around for awhile, but it will require extra work in
>>> the soon-to-be syscall emulation hack to make sure that UML can still
>>> trap the syscall.
>>
>> As long the time within UML is synchronous with the host everything is
>> fine, right?
>
> I think so.  I haven't used UML in a long time.
>
>> So, as _last_ choice we could disable the ability to change the time within UML.
>>
>> IMHO it's not a big deal when getcpu() returns a wrong CPU layout on UML.
>>
>>> The real solution is to fix glibc to use the vDSO which should avoid
>>> this problem entirely.
>>

Yesterday I had a closer look at 64bit UML.
Glibc is always using vsyscalls because 64bit UML does not support the vDSO.

On 32bit UML simply scans the ELF auxiliary vector provided by the host to
get the address of the vDSO.
How can I get this address on a 64bit host?

-- 
Thanks,
//richard
--
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/