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]

Date:	Wed, 12 Mar 2014 08:46:30 -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 7:41 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Nobody has even explained why we want this at all, and why we want
> this headache. Nobody has explained why the solution is not to "just
> don't do that then". Instead, people are piling up *more* complexity
> because the patch had a problem.
>
> That's a technical issue, Stefani. And the threat to not apply patches
> is a technical solution, and I'm getting more and more convinced is
> the *right* technical solution.

.. which is not to say that there aren't possible ways forward.

But quite frankly, I do *not* believe that the way forward is "let's
pile on more complexity to hide the problems this patch caused".

And I absolutely do *not* believe that it is a good idea to make big
fundamental changes to x86-32 that may have lots of legacy users (and
potential embedded future users), but that new installations and
developers have largely left behind.

So I'd very strongly suggest that people go back to square one, and
look at the original patch that caused the problem. There's two
issues:

 - the fact that it grows the code sufficiently that our single-page
approach doesn't work under certain (unusual) configurations

   This is the obvious problem and the thing that people seem to have
worked most on. I don't think it's right to be so eager to work around
the problem, when presumably it should be straightforward to make the
damn code smaller in the first place.

 - the patch really is ugly, and already adds random stuff to map the
vvar/hpet pages into user memory, using absolutely disgusting code.

So quite frankly, if I had looked at that patch *before* hearing of
the size issues, I would personally still have NAK'ed it. The games it
plays are just nasty.

Having looked at it a bit more, I think the correct solution is:

 - leave the legacy compat-vdso FIXMAP entry at a single page

 - do *not* add the HPET/VVAR page games to the legacy case. Get rid
of the remap_pfn_pages() games entirely.

 - do the new thing only for the non-compat case, where we can just
use the "vdso_pages[]" array and not play any games.

IOW, just cut the cord. Separate out the legacy one-page FIXMAP case.
Get rid of the magic pfn_remap stuff entirely. It was ugly and it was
a mistake.

Hmm? That way, people can use the vdso and it really looks the same
between x86-32 and -64, and we can leave the legacy fixmap case alone.
Don't touch it.

But I think that "x86, vdso: Add 32 bit VDSO time support for 32 bit
kernel" patch needs to die. And the helper patches building up to it
(just because that patch used [io_]remap_pfn_range()) should die too.
Why weren't those pages in the vdso*_pages[] array anyway?

              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/