rdmsr from userspace
Andriy Gapon
It seems that rdmsr instruction can be executed only at the highest
privilege level and thus is not permitted from userland. Maybe we should
provide something like Linux /dev/cpu/msr?
I don't like interface of that device, I think that ioctl approach would
be preferable in this case.
Something like create /dev/cpuN and allow some ioctls on it:
ioctl(cpu_fd, CPU_RDMSR, arg).
What do you think?
--
Andriy Gapon
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
Kostik Belousov
>
> It seems that rdmsr instruction can be executed only at the highest
> privilege level and thus is not permitted from userland. Maybe we should
> provide something like Linux /dev/cpu/msr?
> I don't like interface of that device, I think that ioctl approach would
> be preferable in this case.
> Something like create /dev/cpuN and allow some ioctls on it:
> ioctl(cpu_fd, CPU_RDMSR, arg).
> What do you think?
I believe ports/sysutils/devcpu is what you need. In fact, I think this
ought to be committed to the base. I do not know why Stas did not asked
for this, at least at public.
Andriy Gapon
Thanks a lot! This is exactly it.
I agree, this would be quite useful in the OS.
Rui Paulo
>
> It seems that rdmsr instruction can be executed only at the highest
> privilege level and thus is not permitted from userland. Maybe we should
> provide something like Linux /dev/cpu/msr?
> I don't like interface of that device, I think that ioctl approach would
> be preferable in this case.
> Something like create /dev/cpuN and allow some ioctls on it:
> ioctl(cpu_fd, CPU_RDMSR, arg).
> What do you think?
>
While I think this (devcpu) is good for testing and development, I
prefer having a device driver to handle that specific MSR than a generic
/dev/cpuN where you can issue MSRs.
Both for security and reliability reasons.
Regards,
--
Rui Paulo
Andriy Gapon
> Andriy Gapon wrote:
>>
>> It seems that rdmsr instruction can be executed only at the highest
>> privilege level and thus is not permitted from userland. Maybe we
>> should provide something like Linux /dev/cpu/msr?
>> I don't like interface of that device, I think that ioctl approach
>> would be preferable in this case.
>> Something like create /dev/cpuN and allow some ioctls on it:
>> ioctl(cpu_fd, CPU_RDMSR, arg).
>> What do you think?
>>
>
> While I think this (devcpu) is good for testing and development, I
> prefer having a device driver to handle that specific MSR than a generic
> /dev/cpuN where you can issue MSRs.
> Both for security and reliability reasons.
What about /dev/pci, /dev/io? Aren't they a precedent?
--
Andriy Gapon
Rui Paulo
> on 17/05/2008 18:37 Rui Paulo said the following:
>> Andriy Gapon wrote:
>>>
>>> It seems that rdmsr instruction can be executed only at the highest
>>> privilege level and thus is not permitted from userland. Maybe we
>>> should provide something like Linux /dev/cpu/msr?
>>> I don't like interface of that device, I think that ioctl approach
>>> would be preferable in this case.
>>> Something like create /dev/cpuN and allow some ioctls on it:
>>> ioctl(cpu_fd, CPU_RDMSR, arg).
>>> What do you think?
>>>
>>
>> While I think this (devcpu) is good for testing and development, I
>> prefer having a device driver to handle that specific MSR than a
>> generic /dev/cpuN where you can issue MSRs.
>> Both for security and reliability reasons.
>
> What about /dev/pci, /dev/io? Aren't they a precedent?
They are, but, IMHO, we should no longer continue to create this type of
interfaces.
Regards,
--
Rui Paulo
Mike Meyer
Rui Paulo <rpa...@FreeBSD.org> wrote:
> Andriy Gapon wrote:
> > on 17/05/2008 18:37 Rui Paulo said the following:
> >> Andriy Gapon wrote:
> >>>
> >>> It seems that rdmsr instruction can be executed only at the highest
> >>> privilege level and thus is not permitted from userland. Maybe we
> >>> should provide something like Linux /dev/cpu/msr?
> >>> I don't like interface of that device, I think that ioctl approach
> >>> would be preferable in this case.
> >>> Something like create /dev/cpuN and allow some ioctls on it:
> >>> ioctl(cpu_fd, CPU_RDMSR, arg).
> >>> What do you think?
> >>>
> >>
> >> While I think this (devcpu) is good for testing and development, I
> >> prefer having a device driver to handle that specific MSR than a
> >> generic /dev/cpuN where you can issue MSRs.
> >> Both for security and reliability reasons.
> >
> > What about /dev/pci, /dev/io? Aren't they a precedent?
>
> They are, but, IMHO, we should no longer continue to create this type of
> interfaces.
Ok, in relation to the question I asked about sysctl's vs. /dev/* -
why not?
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Kostik Belousov
> Andriy Gapon wrote:
> >on 17/05/2008 18:37 Rui Paulo said the following:
> >>Andriy Gapon wrote:
> >>>
> >>>It seems that rdmsr instruction can be executed only at the highest
> >>>privilege level and thus is not permitted from userland. Maybe we
> >>>should provide something like Linux /dev/cpu/msr?
> >>>I don't like interface of that device, I think that ioctl approach
> >>>would be preferable in this case.
> >>>Something like create /dev/cpuN and allow some ioctls on it:
> >>>ioctl(cpu_fd, CPU_RDMSR, arg).
> >>>What do you think?
> >>>
> >>
> >>While I think this (devcpu) is good for testing and development, I
> >>prefer having a device driver to handle that specific MSR than a
> >>generic /dev/cpuN where you can issue MSRs.
> >>Both for security and reliability reasons.
> >
> >What about /dev/pci, /dev/io? Aren't they a precedent?
>
> They are, but, IMHO, we should no longer continue to create this type of
> interfaces.
Why ? Are developers some kind of the second-class users ?
I would have no opinion on providing /dev/cpu by the loadable module, not
compiled into GENERIC. But the interface itself is useful at least for
three things:
- CPU identification (see x86info or whatever it is called);
- CPU tweaking for bugs workaround without patching the kernel;
- updating the CPU microcode.
None of these is limited to the developers only.
I am interested why Stanislav still did not submitted it for inclusion into
the base still. Maybe, some other reasons exist.
Rui Paulo
Input validation is my main concern here. Regarding to your two last
points, I would prefer to have a microcode driver than a microcode
userland utility that relies on devcpu.
Rui Paulo
> On Sat, 17 May 2008 11:13:52 +0300
> Andriy Gapon <a...@icyb.net.ua> wrote:
>> It seems that rdmsr instruction can be executed only at the highest
>> privilege level and thus is not permitted from userland. Maybe we should
>> provide something like Linux /dev/cpu/msr?
>> I don't like interface of that device, I think that ioctl approach would
>> be preferable in this case.
>> Something like create /dev/cpuN and allow some ioctls on it:
>> ioctl(cpu_fd, CPU_RDMSR, arg).
>> What do you think?
>
> haven't been able to find an answer in the google.
>
> I've been mucking about with general access to sysctl's (a sysctl
> plugin for gkrellm, and a python module for accessing sysctls), and
> with that hammer in my hand, the nail for this problem is obviously a
> dev.cpu.#.msr sysctl.
How can you request a rdmsr within the sysctl tree? I don't think sysctl
is appropriate here either.
--
Rui Paulo
Mike Meyer
Rui Paulo <rpa...@FreeBSD.org> wrote:
> Mike Meyer wrote:
> > On Sat, 17 May 2008 11:13:52 +0300
> > Andriy Gapon <a...@icyb.net.ua> wrote:
> >> It seems that rdmsr instruction can be executed only at the highest
> >> privilege level and thus is not permitted from userland. Maybe we should
> >> provide something like Linux /dev/cpu/msr?
> >> I don't like interface of that device, I think that ioctl approach would
> >> be preferable in this case.
> >> Something like create /dev/cpuN and allow some ioctls on it:
> >> ioctl(cpu_fd, CPU_RDMSR, arg).
> >> What do you think?
> >
> > Ok, this points directly at a question I've been wondering about, but
> > haven't been able to find an answer in the google.
> >
> > I've been mucking about with general access to sysctl's (a sysctl
> > plugin for gkrellm, and a python module for accessing sysctls), and
> > with that hammer in my hand, the nail for this problem is obviously a
> > dev.cpu.#.msr sysctl.
>
> How can you request a rdmsr within the sysctl tree? I don't think sysctl
> is appropriate here either.
Reading (or writing) a sysctl mib can trigger a sysctl handler, which
can do pretty much anything. In particular, there are already examples
in the kernel where sysctl handlers use devices that don't have /dev
entries to get & set their values. Look through kern/kern_cpu.c and
i386/cpufreq/p4tcc.c to see the two ends of that kind of
connection. In fact, the cpu frequency sysctls would seem to be an
excellent model for something like the msr.
ioctl, open+read/write, sysctl - they're all just interfaces to kernel
handlers.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Kostik Belousov
Driver has four basic operations:
read/write msr
perform cpu id work
update microcode.
The later is done as a whole operation, with the microcode blob supplied
by the userspace.
Rui Paulo
Yes, but I still don't like having everything mixed up in one driver. At
the very least, I would like us to have two drivers. One for the
microcode update and the other driver for the rest.
I would like to see a microcode update utility (driver + something to
parse Intel's file aka devcpu-data) in the base system, but not "the
rest", though.
Rui Paulo
Yes, sure, but who do you select the MSR you want to read or write?
dev.cpu.N.<insert MSR number in hexadecimal here> ?
I'll have to think about whether or not I like this interface.
Regards,
--
Rui Paulo
Mike Meyer
Rui Paulo <rpa...@FreeBSD.org> wrote:
I don't think that would work - you'd have to register all those
hexadecimal strings as sysctl names. You could do an interface like
this, but the calling program would have to use sysctlnametomib to get
dev.cpu.N.msr, then append the MSR number to the results. Not really
very pretty. If you want to allow the user to poke at arbitrary msrs,
this would be a way to do it with sysctls, but the file api is
probably better.
On the other hand, if you want to allow access to the fixed set of
documented msr's (for each cpu model, anyway), then handing back that
fixed set as an array would be a better approach, and would have the
advantage of not having to deal with invalid requests (non-existent
MSRs, 1-byte reads/writes of multi-byte MSRs, etc).
On the other hand, it might be more useful - *especially* if the MSRs
move around depending on processor types (I honestly don't know) - to
provide a "named" interface:
dev.cpu.0.msr.mtrr
dev.cpu.0.msr.arr
dev.cpu.0.msr.efer
and so on. You'd register the names when the module was initialized,
and would only register the ones that actually existed. You'd then
never have to deal with a request for a non-existent MSR, because the
sysctl call would return an error to the calling program without ever
calling your handler.
Of course, you can *combine* these two approaches, and have:
dev.cpu.0.msr.all # returns an array of all available msrs
dev.cpu.0.msr.have # an array of the available msrs
but at this point it's just blue sky speculation...
> I'll have to think about whether or not I like this interface.
Actually, I'm more interested in why there seems to be a dislike
of file-based interfaces in favor of sysctls in the freebsd
community. Exploring this has been enlightening. Thank you.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Mike Meyer
Rui Paulo <rpa...@FreeBSD.org> wrote:
I don't think that would work - you'd have to register all those
dev.cpu.0.msr.mtrr
dev.cpu.0.msr.arr
dev.cpu.0.msr.efer
> I'll have to think about whether or not I like this interface.
Actually, I'm more interested in why there seems to be a dislike
of file-based interfaces in favor of sysctls in the freebsd
community. Exploring this has been enlightening. Thank you.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Suleiman Souhlal
For what it's worth, CPUID is not a privileged instruction, so this
doesn't need to be done in the kernel (as long as you have a way to
pin a userland thread to a cpu, which I believe we have, now).
I would personally would *really* to see stas's driver committed as
well, as it's really useful.
(I had a similar driver (but only for MSRs) that I was about to
commit to 7.0 a few months ago, but re@ asked that I add a manpage,
and I never got around to doing it:
http://people.freebsd.org/~ssouhlal/testing/msr-20070707.diff
It's slightly different from devcpu in that it works with lseek +
read/write instead of ioctl).
-- Suleiman
Rui Paulo
>
> I don't think that would work - you'd have to register all those
> hexadecimal strings as sysctl names.
Yes, in theory you could also hack sysctl in a way that it doesn't walk
when you do a sysctl -a, but works fine when you issue sysctl
dev.cpu.N.0xffaabbcc, for example.
I would be against this, though, because this will be like "sysctl on
steroids", a really crude hack.
> You could do an interface like
> this, but the calling program would have to use sysctlnametomib to get
> dev.cpu.N.msr, then append the MSR number to the results. Not really
> very pretty. If you want to allow the user to poke at arbitrary msrs,
> this would be a way to do it with sysctls, but the file api is
> probably better.
Agreed.
> On the other hand, if you want to allow access to the fixed set of
> documented msr's (for each cpu model, anyway), then handing back that
> fixed set as an array would be a better approach, and would have the
> advantage of not having to deal with invalid requests (non-existent
> MSRs, 1-byte reads/writes of multi-byte MSRs, etc).
>
> On the other hand, it might be more useful - *especially* if the MSRs
> move around depending on processor types (I honestly don't know)
They do. At least on Intel (I don't know about AMD). But this "moving"
is not documented.
> - to
> provide a "named" interface:
>
> dev.cpu.0.msr.mtrr
> dev.cpu.0.msr.arr
> dev.cpu.0.msr.efer
>
> and so on. You'd register the names when the module was initialized,
> and would only register the ones that actually existed. You'd then
> never have to deal with a request for a non-existent MSR, because the
> sysctl call would return an error to the calling program without ever
> calling your handler.
>
> Of course, you can *combine* these two approaches, and have:
>
> dev.cpu.0.msr.all # returns an array of all available msrs
> dev.cpu.0.msr.have # an array of the available msrs
>
> but at this point it's just blue sky speculation...
>
>> I'll have to think about whether or not I like this interface.
>
> Actually, I'm more interested in why there seems to be a dislike
> of file-based interfaces in favor of sysctls in the freebsd
> community.
Speaking for myself, sometimes sysctl is an interface that "just works"
and is simple enough. Of course there are some types of structured data
that don't belong to sysctl, but overall, I don't think we are abusing it.
Creating a /dev node, handling ioctl's, etc. is much more work and error
prone. That's all. At least for me.
Regards,
--
Rui Paulo
Andriy Gapon
>
> Yes, but I still don't like having everything mixed up in one driver. At
> the very least, I would like us to have two drivers. One for the
> microcode update and the other driver for the rest.
>
> I would like to see a microcode update utility (driver + something to
> parse Intel's file aka devcpu-data) in the base system, but not "the
> rest", though.
Well, I am not sure what is a basis for such a requirement.
As I pointed out before we already have /dev/pci and /dev/io and those
are not going to go away, because there are quite reasonable
applications that require those devices (and wide-spread too). And I
think that sufficiently structured (via ioctl interface) access to CPU
is also needed for some quite useful (and reasonable) userland applications.
I can understand efforts to prevent foot-shooting, but I can not
understand an approach of limiting abilities of a (sufficiently)
privileged user. After all, he/she can rebuild a kernel and put all they
need into it.
--
Andriy Gapon
John Baldwin
Actually, you don't have to register all of them. You can write a node
handler which parses the next item in the MIB directly. Look at the all the
proc sysctl's which accept a PID for example. That said, I think if someone
already has a device driver done that is fine. I also think it is ok to let
root request arbitrary MSR's from userland using an ioctl() or the like.
--
John Baldwin