Re: Preventing the mixing of armhf packages

On Thu, Apr 26, 2012 at 2:40 PM, Wookey <wookey@wookware.org> wrote:

The right way to do this is with HWCAPS bits to identify whether the
hardware can run v7 binaries and for dpkg to refuse to install stuff
that won't run.

This is how it works on x86:
http://developers.sun.com/solaris/articles/hwcap_modification.html
with HWCAPS for cmov and cmpxchg16b

However I'm not sure the arm HWcaps list:
http://lxr.free-electrons.com/source/arch/arm/include/asm/hwcap.h?v=2.6.30
actually covers the extra v7 instructions. You could probably use the
VFP3 CAP as a proxy on PI, but it may be better to define an actual
'has v7 ISA' bit)

Somehow I don't think the armhf people would be too happy about rebuilding all their packages to accommodate the Raspberry Pi as it would be those packages that would have to include 'has v7 ISA' bit.

So to use this mechanism would need the kernel to check for only-on-v7
instructions and set/not-set the bit. Then arrange for packages to
have needed HWCAPS set in metadata for dpkg to check.

This would prevent the kernel from executing the binary, but this would still leave us in the boat that if the binaries get on the system they could leave the system in an un-runnable state. It's just the kernel refuses to load the binary rather than the binary generating an illegal instruction. Still, it's useful the kernel can prevent execution of the binaries as its definitely more graceful way to catch code that can't execute.

As this data is not already present in everyone else's packages
you'd be best just adding it for the PI packages you've built.

Which of course means you could actually use any old item of metadata
'X-package-ISA:v6' and check that, refusing to install anything else,
rather than a properly general HWCAPS method. But doing it right would
be generalisable to many problems of this class (multimedia-optimised
libraries, with without/NEON etc).

Right now, as I'm building armv6 packages I use a perl script and 'readelf' to scan each elf/library file in the package for v7 file attributes signature. Readelf will tell me the following for armv7 elf files:

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_DIV_use: Not allowed

For armv6 elf files, it reports the following:

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_DIV_use: Not allowed

I'm assuming I could create a special Raspberry Pi version of dpkg which would perform this test at download time and abort the installation if binaries with 'Tag_CPU_arch: v7' were found.

I realize it's short circuiting the more formal HWCAPS method, but it seems to me it would yield similar capability. Also, I wonder if the kernel is exposed to the 'Tag_CPU_arch:' setting in the elf as it is loaded. If so, the kernel on the Raspberry Pi could prevent loading v7 binaries without necessarily going the full HWCAPS route.

Mike