linux-omap-psp and security code

linux-omap-psp and security code

[Vladimir Zapolskiy]

Hello,

I have a question about linux-omap-psp-2.6.32 kernel and boards, which 
uses this kernel, in particular about 
0038-ARM-Expose-some-CPU-control-registers-via-sysfs.patch. The recent 
toolchains based on binutils-2.21 or later imply more accurate handling 
with `smc #0' instructions, which are found in the aforementioned patch. 
The compilation of the linux-omap-psp kernel with such toolchains leads 
to "selected processor does not support ARM mode `smc #0'" errors. The 
patch itself adds /sys/devices/system/cpu/cpuN/ nodes providing access 
to control register, auxiliary control register, and L2 cache auxiliary 
control register.

I see several possible solutions of the problem, and I'd be glad to find 
out the best one. First of all it might have sense to remove the patch 
completely, because its functionality is purely optional, presumably it 
is not used by any userspace programs and therefore can be omitted. As a 
soft alternative CONFIG_CPU_V7_SYSFS kernel option for a list of boards 
could be disabled in default kernel config files, but I personally don't 
like this variant, because it merely veils a problem, better to remove 
the patch itself.

One more option is to fix the patch, either remove store feature of 
/sys/devices/system/cpu/cpuN/(l2_)?aux_control files or provide 
-march=armv7-a+sec AFLAGS in Makefile.

Any suggestions and comments are appreciated.

With best wishes,
Vladimir

Re: linux-omap-psp and security code

[Denys Dmytriyenko]

This one got stuck in the moderation queue with all the spam... Just wanted to 
comment on the third option, though.

On Thu, Jul 19, 2012 at 01:31:26PM +0300, Vladimir Zapolskiy wrote:
> One more option is to fix the patch, either remove store feature of
> /sys/devices/system/cpu/cpuN/(l2_)?aux_control files or provide
> -march=armv7-a+sec AFLAGS in Makefile.

FWIW, I previously made a similar fix for this type of issue:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=051482e3b03ba7e2d6cecc0d8f85cc3be22dc8b2

But either way it's better to update to a more recent 2.6.37 kernel for AM37x 
anyway, which I'll work on next.

-- 
Denys

Re: linux-omap-psp and security code

[Vladimir Zapolskiy]

Hi Denys,

On 31.07.2012 23:16, Denys Dmytriyenko wrote:
> This one got stuck in the moderation queue with all the spam... Just wanted to
> comment on the third option, though.
>
> On Thu, Jul 19, 2012 at 01:31:26PM +0300, Vladimir Zapolskiy wrote:
>> One more option is to fix the patch, either remove store feature of
>> /sys/devices/system/cpu/cpuN/(l2_)?aux_control files or provide
>> -march=armv7-a+sec AFLAGS in Makefile.
>
> FWIW, I previously made a similar fix for this type of issue:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=051482e3b03ba7e2d6cecc0d8f85cc3be22dc8b2

Eventually I verified this alternative and found that it won't work
as expected in this particular case. Here assembly instructions are
ingrained in C code, and after compilation there will be ".arch armv7"
directive in the generated assembly sources, which has precedence
over -march assembler flag. So, the only remaining option is to fix C
code.

But asflags method shall work fine with pure assembly sources like
in your fix.

> But either way it's better to update to a more recent 2.6.37 kernel for AM37x
> anyway, which I'll work on next.

Indeed. Excluding two problematic (and IMO useless and potentially
destructive) patches may be a good immediate measure to restore the
builds, but it's up to you to disable them or not. Having support
of the boards in 2.6.37 is the best option for sure.

With best wishes,
Vladimir