linux-kernel - Re: [PATCH v2] x86: Remove compat vdso support

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: <CA+55aFyhS5jCWcxuK4bXKEPh+8HWbPE+gy1m4N9B-2HyT48+QA@mail.gmail.com>
Date:	Wed, 12 Mar 2014 12:41:52 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	Andy Lutomirski <luto@...capital.net>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Dave Jones <davej@...hat.com>,
	Martin Runge <Martin.Runge@...de-schwarz.com>,
	Andreas Brief <Andreas.Brief@...de-schwarz.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v2] x86: Remove compat vdso support

On Wed, Mar 12, 2014 at 8:46 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>  - do *not* add the HPET/VVAR page games to the legacy case. Get rid
> of the remap_pfn_pages() games entirely.

.. actually, another approach would be to do the HPET/VVAR page games,
but make them non-legacy.

The reason I hate seeing those remap_pfn_range() things is because
it's nasty code for a legacy case that I think shouldn't have new code
written for it, especially when it won't get testing by developers.

So my reaction was "don't do that".

But people pointing out that we can't do what x86-64 does made me
think: we could avoid the whole "nasty code for a legacy case" by
making it the *non*-legacy case. We could get rid of the fixmap
HPET/VVAR entirely - on x86-64 (which can use those addresses) a
PC-relative addressing is probably actually better anyway, so mapping
them together with the vdso code shouldn't hurt.

That would remove my objections to doing all this stuff for a case
that developers won't see and use (the whole "It's dead, Jim"
objection) . And it would unify the 32-bit and 64-bit cases.

Together with Andy's "remove legacy 32-bit fixmap vdso", I'd feel that
this is actually an _improvement_ to the current situation.

Would something like that be more acceptable to everybody?

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