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

Message-ID: <20160314185634.GK15800@pd.tnic>
Date:	Mon, 14 Mar 2016 19:56:34 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] Unexport do_machine_check() and machine_check_poll()

On Mon, Mar 14, 2016 at 06:24:23PM +0000, Luck, Tony wrote:
> > 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.

Yap. Exactly.

Right, so the optimal thing to do IMHO is make those two users solve
their needs differently, so that there's no requirement for exports at
all. And the fact that both are modules - and they need to be modules
for obvious reasons - doesn't make it any easier.

I can't think of something useful right now though... I'll need to
ponder on it a while longer.

Thanks for listening!

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.