[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <6FA68A07-F718-46F5-81B4-586A5ED3E479@linux.alibaba.com>
Date: Tue, 1 Dec 2020 22:25:43 +0800
From: wangrongwei <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月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.
>
>> 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...
Yes, but accessing those system registers doesn't seem to have an address, just have a register number (I'm not sure about that)?
>
>> 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.
Not really sure what you mean by CPU validation as you describe above? However, the biggest challenge we encountered during implementation was an undefined instruction exception that could occur after modifying a code segment, but this problem was also solved using the kernel's existing interface.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny…
Regard,
Rongwei.
Powered by blists - more mailing lists