[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <059ed4a8768ff3881005796cb4a10d5e@kernel.org>
Date: Tue, 01 Dec 2020 08:12:30 +0000
From: Marc Zyngier <maz@...nel.org>
To: wangrongwei <rongwei.wang@...ux.alibaba.com>
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
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?
> Actually, we used existing interfaces to realize this driver, likes
> aarch64_insn_read and aarch64_insn_patch_text.
Sure. At that stage, you could also directly expose the linear mapping
to
userspace and start writing to it, it would probably be a fitting
addition...
> These existing intefaces had validated a CPU.
If CPU validation is your goal, I suggest this is kept out of tree, as
the
kernel is hardly a validation tool for the arm64 architecture.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists