Message-Id: <58C4701C-DEAC-4FE9-B54C-3B9ADC8E197D@linux.alibaba.com>
Date:   Thu, 3 Dec 2020 19:25:43 +0800
From:   Rongwei Wang <rongwei.wang@...ux.alibaba.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     catalin.marinas@....com, Will Deacon <will@...nel.org>,
        bjorn.andersson@...aro.org, shawnguo@...nel.org, gshan@...hat.com,
        geert+renesas@...der.be, Anson.Huang@....com, masahiroy@...nel.org,
        michael@...le.cc, krzk@...nel.org, linux-kernel@...r.kernel.org,
        vkoul@...nel.org, olof@...om.net, vincenzo.frascino@....com,
        ardb@...nel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/3] arm64:msr: Add MSR driver



> 2020年12月3日 下午4:35，Marc Zyngier <maz@...nel.org> 写道：
> 
> On 2020-12-03 05:45, Rongwei Wang wrote:
>>> 2020年12月1日 下午11:37，Marc Zyngier <maz@...nel.org> 写道：
>>> On 2020-12-01 14:25, wangrongwei wrote:
>>>>> 2020年12月1日 下午4:12，Marc Zyngier <maz@...nel.org> 写道：
>>>>> On 2020-12-01 03:09, wangrongwei wrote:
>>>>>> Hi
>>>>>> We have validate this driver in vm and physical machine, and works fine.
>>>>> But what does "work fine" mean? None of these system registers are supposed
>>>>> to be accessible from userspace, so please explain *what* you are trying to
>>>>> do with this, other that introducing security holes and general system
>>>>> instability?
>>>> I think I know what you mean. Do you want me to describe how we achieved it?
>>>> In x86, the different registers can be accessed directly using the
>>>> rdmsr and wrmsr instructions, but in ARM, since these two instructions
>>>> are missing, so we modify the code segment during runtime, similar to
>>>> the principle of static_key.
>>> [...]
>>> These are implementation details, none of which answer my question:
>>> What makes you think this is a good idea? I cannot see any legitimate
>> In fact, I think this tool useful mainly in the following scenarios:
>> 	1. performance debug
>> 	2. Arm-core features test
>> 	3. Debug-tool for kernel developer
>> Also, for example, MSR-ARM is needed for chip verification and
>> system-level functional verification.
>> A simple example, perf stat can test pmu, but the overflow interrupt
>> function and forced overflow function of pmu is not covered.
> 
> But what does it mean to change random system registers while the kernel
> itself is using them in parallel? All you are introducing is a bunch of
> uncontrolled, unexpected, and possibly fatal side effects.
This problem exists when writing to a register, but it does not exist when reading a register.
> 
> Introducing such an interface makes the kernel unsafe, insecure, and
> and violates all the possible guarantees that we are trying hard to
> provide. After all, why would we even try to mitigate side channel
> vulnerabilities if we were to introduce such a thing?
> 
>> In both cases, we need a special interface to configure it, which can
>> be considered as testing requirements, so it can only be tested by
>> configuring (access) registers, e.g., devmem command for memmap
>> registers, MSR-ARM driver for system registers.
> 
> devmem was a terrible mistake. Unprivileged sysreg access is another
> instance of the same mistake.
> 
> The kernel is not a validation tool. It is designed to operate safely,
> securely, and reliably. What you propose is the negation of these goals
> for dubious purposes, and I think I represent a large number of kernel
> developers when I say that we really do not want it.
> 
> This will (hopefully) be my last message on this subject.
> 
> Thanks,
> 
>        M.
> -- 
> Jazz is not dead. It just smells funny…
Thanks,
Rongwei Wang.

Powered by blists - more mailing lists