linux-kernel - Tightening up rdpmc permissions?

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-next>] [day] [month] [year] [list]

Message-ID: <CALCETrU3nNvG6+-7iScYT8LDRFnq8kYnpK0cdW1bgW5O4EGrUg@mail.gmail.com>
Date:	Mon, 29 Sep 2014 09:39:16 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Tightening up rdpmc permissions?

I was surprised to notice that, by default, every task has permission
to use rdpmc.  seccomp cannot work around this.  This leaks
information, although the information leaked is of dubious and
variable value to an attacker.  It also renders the PR_TSC_SEGV
mechanism mostly useless.

Would it make sense to restrict rdpmc to tasks that are in mms that
have a perf_event mapping?  After all, unless I misunderstand
something, user code can't reliably use rdpmc unless they've mapped a
perf_event object to check the rdpmc bit and figure out what ecx value
to use.

I think that this could be implemented with very little overhead,
especially if combined with the existing CR4_TSD code and if that code
were taught to avoid reading cr4.

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