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

[Marc Zyngier]

On 2020-12-03 05:45, Rongwei Wang wrote:
> > 2020年12月1日 下午11:37，Marc Zyngier <maz@xxxxxxxxxx> 写道：
> >
> > On 2020-12-01 14:25, wangrongwei wrote:
> > > > 2020年12月1日 下午4:12，Marc Zyngier <maz@xxxxxxxxxx> 写道：
> > > > 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.

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