linux-kernel - Re: [PATCH 0/5] x86-64: Remove syscall instructions at fixed addresses

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: <BANLkTi=Gi_0Uyj+dA6GjriRU9fCzKuLU=g@mail.gmail.com>
Date:	Tue, 31 May 2011 08:27:12 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Jan Beulich <JBeulich@...ell.com>
Subject: Re: [PATCH 0/5] x86-64: Remove syscall instructions at fixed addresses

On Tue, May 31, 2011 at 4:07 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Andrew Lutomirski <luto@....edu> wrote:
>
>> On Sun, May 29, 2011 at 3:19 PM, Ingo Molnar <mingo@...e.hu> wrote:
>> > Btw., do you know CONFIG_X86_PTDUMP=y and /debug/kernel_page_tables?
>> > You could use that to double check that after your patches all
>> > executable (and fixed address) pages are removed [or are harmless].
>>
>> Done.  Now there's only one user-executable page and it's mostly harmless.
>
> ok. Will test your v3 series.
>
>> Maybe I'll try to get rid of vread_tsc and vread_hpet later on to
>> make it even more harmless.
>
> Yeah, that's a good idea. They need pushing into the INT 0xCC
> do_intcc() handler, that's all that's needed AFAICS - or can you see
> other complications with them?
>

They're called from the vDSO.  I think they should just be moved into
the vDSO since they're not used by the vsyscall code any more, but
there are two problems.  The clocksource.vread mechanism (or whatever
its called) won't really work if we let them get relocated (not a big
deal).  More importantly, vread_tsc contains an alternative and the
vDSO can't currently contain alternative instructions.  That can
probably be fixed, but it'll take a bit of work.

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