linux-kernel - Re: [RFC PATCH] x86: Filter MSR writes from luserspace

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: <20191126203336.GF31379@zn.tnic>
Date:   Tue, 26 Nov 2019 21:33:36 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Andi Kleen <ak@...ux.intel.com>
Cc:     x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] x86: Filter MSR writes from luserspace

On Tue, Nov 26, 2019 at 12:15:10PM -0800, Andi Kleen wrote:
> This will break a bazillion of tools that rely on programing many of
> those MSRs from user space.

Userspace has no deal to poke into random MSRs. End of story.

The next version will switch to a whitelist and I've added the ones
which are used by turbostat and powertop:

int msr_filter_write(u32 reg)
{
        switch (reg) {
        case MSR_IA32_ENERGY_PERF_BIAS:
        case MSR_RAPL_POWER_UNIT:
        case MSR_DRAM_POWER_LIMIT:
        case MSR_PP0_POWER_LIMIT:
        case MSR_PP1_POWER_LIMIT:
                return 0;

I guess adding other, non-critical MSRs to that list is fine.

But if people really wanna program the hardware, a proper interface
needs to be designed. This patch has an example for why poking at random
MSRs from userspace is simply not going to work in the long run.

And if they still wanna poke at MSRs and if you look at the patch in
more detail, you'll see there's msr.allow_writes=1 and we'll taint the
kernel.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette