linux-kernel - Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

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]

Message-ID: <20140310222528.Horde.tMG70UcHgBuz9DV3W9_aaA1@webmail.your-server.de>
Date:	Mon, 10 Mar 2014 22:25:28 +0100
From:	stefani@...bold.net
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Andy Lutomirski <luto@...capital.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andreas Brief <Andreas.Brief@...de-schwarz.com>,
	Martin Runge <Martin.Runge@...de-schwarz.com>
Subject: Re: [x86, vdso] BUG: unable to handle kernel paging request at
 d34bd000


Zitat von Linus Torvalds <torvalds@...ux-foundation.org>:

> On Mon, Mar 10, 2014 at 1:06 PM, H. Peter Anvin <hpa@...ux.intel.com> wrote:
>>
>> The quick way to get something working is simply to reserve more than
>> one page (two should presumably be enough) in the fixmap and adjust the
>> link address of the VDSO accordingly.  This is not where we want to go
>> in the long term, but it doesn't seem to make sense to try to do
>> everything all at once -- we are already starting to push way too close
>> to the 3.15 merge window.
>
> If the only immediate problem is the code generation size, then Andy
> already had a (simpler) hack-around:
>
>   #undef CONFIG_OPTIMIZE_INLINING
>   #undef CONFIG_X86_PPRO_FENCE
>
> in vclock_gettime.c.
>

This was discovered by me.

> I think we could make it a bit less hacky by just restricting the
> inlining of the paravirt case, since that's presumably the crap code
> that causes things to grow too large. Or find out what in there it is
> that explodes in size, and just try to de-crapify the code enough that
> it no longer does that.
>

The two options above makes the code grow. The x86 pro fence make add
alternatives which increase the code by 600 bytes and the optimize
inlining will add another 500 bytes.

But this is not a real solution, at least when vcpu function support
will be added, then the code size will exceed the page size. Reserving
two pages for the VDSO is a good option.

- Stefani



--
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/