Re: [PATCH 0/3] arm64:msr: Add MSR driver

On 2020-12-03 05:45, Rongwei Wang wrote:

quoted

2020年12月1日 下午11:37，Marc Zyngier [off-list ref] 写道：

On 2020-12-01 14:25, wangrongwei wrote:

quoted

quoted

2020年12月1日 下午4:12，Marc Zyngier [off-list ref] 写道：
On 2020-12-01 03:09, wangrongwei wrote:

quoted

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.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel