linux-kernel - RE: [RFC PATCH] Unexport do_machine_check() and machine_check

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: <3908561D78D1C84285E8C5FCA982C28F3A008EDD@ORSMSX114.amr.corp.intel.com>
Date:	Mon, 14 Mar 2016 18:24:23 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH] Unexport do_machine_check() and machine_check_poll()

> But the sentiment is: I want to unexport do_machine_check() and
> machine_check_poll() and not let external modules call into them
> directly. Why, you ask? Because they have no business doing that.

EXPORT is a big hammer ... we either let every module have access to
a function, or none.  It sounds like you want a way to just export to a
few trusted friendly areas that have a real need to access, and make this
invisible to everyone else.

I can't imagine a way to absolutely enforce that ... whatever mechanism
you choose could be abused by someone willing to have their module lie
and say "sure, I'm a KVM user that is allowed to use that".

Perhaps there's a way to implement an advisory scheme ... which would
make it blatantly obvious when modules are hooking into things that
they shouldn't. The only similar thing we have now is EXPORT_GPL which doesn't
look scalable to lots of uses.

-Tony