linux-kernel - Re: [PATCH 7/8] Add 32 bit VDSO time support for 32 bit kernel

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: <CALCETrX2K6DeGO7v+8Qed03xbKd0dcsoWVPg6fp6+KNGHnC+eA@mail.gmail.com>
Date:	Sun, 2 Feb 2014 16:12:44 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	John Stultz <john.stultz@...aro.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	andriy.shevchenko@...ux.intel.com, Martin.Runge@...de-schwarz.com,
	Andreas.Brief@...de-schwarz.com
Subject: Re: [PATCH 7/8] Add 32 bit VDSO time support for 32 bit kernel

On Sun, Feb 2, 2014 at 1:39 PM, Stefani Seibold <stefani@...bold.net> wrote:
> Am Sonntag, den 02.02.2014, 08:46 -0800 schrieb Andy Lutomirski:
>> On Sun, Feb 2, 2014 at 3:27 AM,  <stefani@...bold.net> wrote:
>> > From: Stefani Seibold <stefani@...bold.net>
>> >
>> > This patch add the time support for 32 bit a VDSO to a 32 bit kernel.
>>
>> [...]
>>
>> Can you address the review comments from last time around?  For
>> example, this still seems to have redundant vvar and hpet mappings, it
>> doesn't use the VVAR macro, it moves the 32-bit compat vDSO, etc.
>>
>
> I will address the compat VDSO issue.
>
> But the VVAR macro will be not a part of this patch set. If you depend
> on this, feel free to create one. From my point of view this is not
> feasible without a macro hacking, because the address accessing the vvar
> area differs in kernel and VDSO user mode.

Sorry, but "I will make the code messier for no apparent reason and I
will not offer to fix it in the same series" gets my NAK.

Hint: I'm talking about two or three lines of code in vvar.h.

>
> I also see no redundant mapping. There are two modes, one is the map of
> the kernel area the other maps the VDSO into the user space area. This
> is exactly the behaviour of the origin VDSO implementation.

No.

In your series there are *three* mappings.  There are:

 - The linear mapping that the kernel loader sets up (the writable
mapping used in the kernel).  This is implicit and, of course, fine.
 - There's the fixmap page, which aliases the normal kernel mapping at
a fixed address with the user, ro, and nx attributes.  The 64-bit vDSO
uses that mapping.  See vdso.h -- it's all arranged pretty clearly.
Your code, for no discernible reason, sets up a fixmap entry on
*32-bit* kernels.
 - The vma that you're setting up adjacent to the actual vdso text.
This is what you are using.

Please choose *one* user-readable mapping for the 32-bit vdso and
stick with it.  If the 64-bit vdso can use it to and userspace doesn't
break, even better.  But a pointless set of extra fixmap entries is
not okay.

hpa's right about the symbol versions, BTW -- those are ABI and will
probably break (at least) every new-enough Go binary.

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