Hi,
I managed to access coprocessor 14 and 15 of the ARM from the user space. I built a small prog which modifies the registers depending on user requirements.
It was difficult to achieve, but now it workd fine and I can modify clock speed or power management from the user space. You should also be able to access the cache registers.
If interested, I can send you the prog.
Regards,
Why are you doing this?
It really sounds like this sort of thing belongs in kernel space. Ideally,
you would expose the clocks through the kernel's clock or cpufreq
subsystem.
Moreover, what are you doing fooling around with the i-cache from
userspace? Just curious, although this sounds quite fishy.
- Ben
"Lovric Ivan" <ivan.lovric@eseco.fr> writes:
Hi,
I managed to access coprocessor 14 and 15 of the ARM from the user
space. I built a small prog which modifies the registers depending
on user requirements.
Are you saying you managed to access supervisor-only registers from
userspace? Sounds tricky...
It was difficult to achieve, but now it workd fine and I can modify clock
speed or power management from the user space. You should also be able to
access the cache registers.
Clock speed and power are not controlled by CP14 or CP15. These
features are controlled through memory-mapped registers in the SoC,
and these can of course be accessed from userspace if the kernel
permits the required mmap() operation.
Hi,
I did this because it is not sometimes not easy to recompile and
reinstall the kernel. So I built a little program named energy which
allows to modifiy thre CP14 and CP15 registers from user space in
order to control clock speed and power management features. It is
therefore also possible to use the coprocessor registers to modify i-
cache behaviours.
Regards,
Hello,
Yes, it was tricky, because these registers are not mapped in memory
and can only be accesses in supervisor mode.
I created a sourceforge program "energy" to get the code and have it
modified by the community.
You can dowload it using subversion "svn co https://energy.svn.sourceforge.net/svnroot/energy
energy"
Regards,
Wasn't the sysfs interface to cpuidle, cpufreq and smartreflex good enough?
ESECO SYSTEMS <ivan.lovric@eseco.fr> writes:
"Lovric Ivan" <ivan.lov...@eseco.fr> writes:
> Hi,> I managed to access coprocessor 14 and 15 of the ARM from the user
> space. I built a small prog which modifies the registers depending
> on user requirements.Are you saying you managed to access supervisor-only registers from
userspace? Sounds tricky...> It was difficult to achieve, but now it workd fine and I can modify clock
> speed or power management from the user space. You should also be able to
> access the cache registers.Clock speed and power are not controlled by CP14 or CP15. These
features are controlled through memory-mapped registers in the SoC,
and these can of course be accessed from userspace if the kernel
permits the required mmap() operation.Yes, it was tricky, because these registers are not mapped in memory
and can only be accesses in supervisor mode.
I created a sourceforge program "energy" to get the code and have it
modified by the community.
You can dowload it using subversion "svn co https://energy.svn.sourceforge.net/svnroot/energy energy"
Regards,
____________
Ivan Lovric
ESECO SYSTEMS
Web3.0 for security and risk protection
http://www.eseco.fr
_________________
That is the silliest thing I've seen in a long time. You are dumping
an MCR instruction at some magic memory address, then you issue a
legacy software breakpoint trap. Presumably, at least on your system,
the handler for that trap happens to pass the address where you wrote
the MCR. Not only is this an utterly stupid thing to do, I cannot
imagine a more inefficient way than yours of doing it. And that's
without considering that clock speed and power setting are not
controlled through coprocessor interfaces.
The code you posted reeks of incompetence on more levels than I care
to count. I feel sorry for your customers, if you have any.
Hi,
Maybe you don't know that the CCCR (0x4130 000) cannot be modified
without modifying the CLKCFG coprocessor CP14 register 6 on ARM Xscale
PXA270, which is not possible from user space due to privileged mode.
I guess you should better read the ARM documentation before posting
such mails which show your incompetencies. Probably, you tried to do
this before but without any success...
Better luck next time...
Don't worry for my customers because they all are very satisfied.
I'm going to say this once. Please, for the good of you and your
customers, don't ship that code with any product. There are well-defined
and very well thought out interfaces already around for this sort of
thing. Your code really is not the best solution here. It really isn't that
difficult to write a kernel module. Good luck,
- Ben
Agreed, this piece of code seems to exploit a security issue on Arm
and Linux, and should be used for testing and demonstration only. I
will submit it to Linux security forums to determine how to get
protected against this security hack.
Regards,
ESECO SYSTEMS <ivan.lovric@eseco.fr> writes:
Hi,
Maybe you don't know that the CCCR (0x4130 000) cannot be modified
without modifying the CLKCFG coprocessor CP14 register 6 on ARM Xscale
PXA270, which is not possible from user space due to privileged mode.
This list is for discussing the OMAP3-based Beagle board. On the
OMAP3, physical address 0x41300000 (I generously assume you
accidentally left off a zero) is not mapped at all.
On ARMv7, the MCR instructions in your code will attempt to access
debug registers 768 (CRn=6) and 896 (CRn=7), both of which are
reserved. Furthermore, on the Cortex-A8 processor used in the OMAP3,
these registers are not accessible through the CP14 interface at all,
making these instructions undefined.
OMAP3 clocks and power are controlled through the PRCM registers,
all memory-mapped as described in the OMAP35xx TRM.
Low-level details of the PXA270 have no relevance whatsoever on this
list. If you still choose to discuss this processor, you should make
this clear from the start.
Finally, even if your code miraculously works on a PXA270, it is still
extremely badly written.
ESECO SYSTEMS <ivan.lovric@eseco.fr> writes:
Agreed, this piece of code seems to exploit a security issue on Arm
and Linux, and should be used for testing and demonstration only. I
will submit it to Linux security forums to determine how to get
protected against this security hack.
There is no security issue. Of course you can mmap /dev/mem as root
and write whatever code you like anywhere you like. There is also an
option in the Linux kernel to restrict /dev/mem mappings to safe
regions, making even this difficult or impossible.
But please do submit a report. I'm sure they'll get a good laugh out
of it.