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: <CALCETrUjSDEejWmD9UC=Wp=bFFd8M03tAQajSJo2bpusBDzzbQ@mail.gmail.com>
Date:	Wed, 12 Mar 2014 09:18:22 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Stefani Seibold <stefani@...bold.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:
> On Wed, Mar 12, 2014 at 7:41 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>
> 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.

If I understand your suggestion right, I you're saying that we
should have two cases:

1. CONFIG_COMPAT_VDSO or vdso32=2: Use a one-page vdso in the fixmap.

2. !CONFIG_COMPAT_VDSO or vdso32=1: Use a multiple-page vdso + vvar
area in a vma (or maybe a couple of vmas).

The current 32-bit vdso is actually three separate .so files, selected
at boot time.  So now we'd need six.  (Yes, this can be reduced to
two.  But still.)  I think I'd prefer:

1. CONFIG_COMPAT_VDSO or vdso32=2: No vdso at all

2. !CONFIG_COMPAT_VDSO or vdso32=1: Use a multiple-page vdso + vvar
area in a vma (or maybe a couple of vmas).

This variant is a *lot* less code, and it avoids the need to generate
a further combinatorial blowup in the number of vdso images that the
kernel builds.  (This is more or less the same thing as my
thoroughly-nakked patch, except with the default flipped.)

The only downside that I can think of is that people who are using
CONFIG_COMPAT_VDSO unnecessarily take a small performance hit.

IOW, I don't think that anyone really wants to support two
implementations of a non-trivial 32-bit vdso.

Re: leaving the hpet and such in the fixmap unconditionally, I'm not
sure I see the advantage.  For one thing, it can't support the compat
case, it's not really clear to me how it fits in with x32, and it
prevents future improvements that involve adjusting those mappings per
process.  Doing it with vmas is IMO not so bad.  (Doing with with vmas
or with fixmaps depending on kernel configuration, on the other hand,
is a mess.)

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