cpuctl(formely devcpu) patch test request

Stanislav Sedov stas at FreeBSD.org
Sun Jun 15 19:03:06 UTC 2008

On Fri, 06 Jun 2008 09:23:24 -0400
Coleman Kane <cokane at cokane.org> mentioned:

> What about using the API in priv(9) or similar, such as is done in the
> mlock(2)/munlock(2) code in sys/vm/vm_mmap.c ?

This is really a good idea. I've added a bunch of priv checks to cpuctl
Names are self-describing. CPUID ioctl doesn't need that check as this
operation are entirely safe and doesn't disclose any sensitive information.
In fact it might be even performed from userland if one will find a way
to bind the process to a specific cpu.

On Fri, 6 Jun 2008 09:14:13 +1000
Peter Jeremy <peterjeremy at optushome.com.au> mentioned:

> ENOSYS generally means "system call not implemented".  You need a response
> implying that the requested operation isn't supported on the hardware.
> IMHO, ENODEV comes closest to that.

Yeah, it seems that ENODEV is a better choice.
> I also agree with phk@ that serious thought needs to be given to the
> foot-shooting capability offered by this patch before it is implemented.
> Maybe add a sysctl to enable the write (at least) functionality - eg
> hw.cpuctl.wrmsr_enable and hw.cpuctl.update_enable (both defaulting to
> disabled).  This at least adds a safety catch.  I'm not sure if RDMSR
> is dangerous - if so, possibly there should be an enable for it as well.

I don't think that extra anti foot-shooting checks are needed: you can't
easily fire up your system via ioctl(2) interface. At least, a little
programming exercise is required. What's regarding microcode updates - 
there's a lot of checks if the microcode image valid in update utility,
also the cpu itself checks the microcode CRC before applying update.

The latest version of the patch against recent HEAD is available at


Stanislav Sedov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080615/6be967f0/attachment.pgp

More information about the freebsd-current mailing list