Feature branch not working on iPhone 6 Plus - ios 8.1 about sdklauncher-ios

[rkwright]

Which feature branch? there are so many...

[OmarCur]

This is the one Daniel Weck asked us to use

https://github.com/readium/readium-sdk/tree/feature/ByteRangeStreams

With kind regards / Met vriendelijke groet

Omar Curiëre
OCG Studios

T ..31-[0]35 6946091

http://www.ocgstudios.com/ https://www.facebook.com/OCGStudios
https://twitter.com/ocgstudios https://www.youtube.com/user/ocgstudios

Wilhelminaplantsoen 7B 1404 JA Bussum The Netherlands

On Thu, Nov 13, 2014 at 5:12 PM, Ric Wright [email protected]
wrote:

Which feature branch? there are so many...

—
Reply to this email directly or view it on GitHub
#38 (comment)
.

[danielweck]

Same problem on develop (feature branch used for testing apps using the latest bug fixes, but otherwise develop has the same build configuration).
It looks like iPhone 6+ for iOS8 does not build correctly (unlike iPad4 iOS8 which works fine, as well as the other configurations Omar mentioned).

[OmarCur]

We haven't tried another branch, is that useful?

With kind regards / Met vriendelijke groet

Omar Curiëre
OCG Studios

T ..31-[0]35 6946091

http://www.ocgstudios.com/ https://www.facebook.com/OCGStudios
https://twitter.com/ocgstudios https://www.youtube.com/user/ocgstudios

Wilhelminaplantsoen 7B 1404 JA Bussum The Netherlands

On Thu, Nov 13, 2014 at 5:57 PM, danielweck [email protected]
wrote:

Same problem on develop (feature branch used for testing apps using the
latest bug fixes, but otherwise develop has the same build configuration).
It looks like iPhone 6+ for iOS8 does not build correctly (unlike iPad4
iOS8 which works fine, as well as the other configurations Omar mentioned).

—
Reply to this email directly or view it on GitHub
#38 (comment)
.

[danielweck]

@OmarCur develop is fine too.

[danielweck]

Okay, yesterday I met with a developer (Readium integrator) who also owns an iPhone 6+
Same build error (ARM 64?)

Error:Undefined symbol '_epub_sys_cache_flush' referenced from:
Error:  ePub3::ByteBuffer::Clean(unsigned char*, unsigned long) in libePub3-iOS.a(byte_buffer.o)
Note:ld: symbol(s) not found for architecture arm64
Error:linker command failed with exit code 1 (use -v to see invocation)

In fact, I am able to reproduce this error by building against the "iOS Device" target which is selected by default when my iPad 4 is not plugged in. Strangely, the "iPhone 6 Plus" target works!
UPDATE (see my comment below): "iOS Device" fails to build in AppCode, but in XCode I cannot actually even start the build with this target. Also, the "iPhone 6 Plus" target works because the simulator does not actually need arm architecture build.

[OmarCur]

Ís there something we can try?

With kind regards / Met vriendelijke groet

Omar Curiëre
OCG Studios

T ..31-[0]35 6946091

http://www.ocgstudios.com/ https://www.facebook.com/OCGStudios
https://twitter.com/ocgstudios https://www.youtube.com/user/ocgstudios

Wilhelminaplantsoen 7B 1404 JA Bussum The Netherlands

On Tue, Nov 18, 2014 at 12:20 PM, danielweck [email protected]
wrote:

Okay, yesterday I met with a developer (Readium integrator) who also owns
an iPhone 6+
Same build error (ARM 64?)

Error:Undefined symbol '_epub_sys_cache_flush' referenced from:
Error: ePub3::ByteBuffer::Clean(unsigned char*, unsigned long) in libePub3-iOS.a(byte_buffer.o)
Note:ld: symbol(s) not found for architecture arm64
Error:linker command failed with exit code 1 (use -v to see invocation)

In fact, I am able to reproduce this error by building against the "iOS
Device" target which is selected by default when my iPad 4 is not plugged
in. Strangely, the "iPhone 6 Plus" target works!

—
Reply to this email directly or view it on GitHub
#38 (comment)
.

[danielweck]

Thanks @OmarCur
The "arm64" architecture seems correctly set in the ePub3-iOS target of ePub3.xcodeproj, so I am not sure what is going on.

https://github.com/readium/readium-sdk/blob/feature/ByteRangeStreams/ePub3/utilities/CPUCacheUtils_arm.S#L9

When I build SDKLauncher-iOS for my iPad4 device (not simulator), CPUCacheUtils_arm is compiled for armv7 (as you can see, no support for arm64 architecture):

lipo -info  /Users/danielweck/Library/Developer/Xcode/DerivedData/SDKLauncher-iOS-edxulaokdyiopefmkrttdfypkoih/Build/Intermediates/ePub3.build/Debug-iphoneos/ePub3-iOS.build/Objects-normal/armv7/CPUCacheUtils_arm.o

Non-fat file: CPUCacheUtils_arm.o is architecture: armv7

Could you please check your "DerivedData" folder (as per the above file path), and run "lipo -info" on "CPUCacheUtils_arm.o" when you build for your iPhone 6 Plus?

[OmarCur]

I will pass this through to Arthur he is one of the developers, this goes
way beyond my knowledge :(

With kind regards / Met vriendelijke groet

Omar Curiëre
OCG Studios

T ..31-[0]35 6946091

http://www.ocgstudios.com/ https://www.facebook.com/OCGStudios
https://twitter.com/ocgstudios https://www.youtube.com/user/ocgstudios

Wilhelminaplantsoen 7B 1404 JA Bussum The Netherlands

On Tue, Nov 18, 2014 at 12:53 PM, danielweck [email protected]
wrote:

Thanks @OmarCur https://github.com/OmarCur
The "arm64" architecture seems correctly set in the ePub3-iOS target of
ePub3.xcodeproj, so I am not sure what is going on.

https://github.com/readium/readium-sdk/blob/feature/ByteRangeStreams/ePub3/utilities/CPUCacheUtils_arm.S#L9

When I build SDKLauncher-iOS for my iPad4 device (not simulator),
CPUCacheUtils_arm is compiled for armv7 (as you can see, no support for
arm64 architecture):

lipo -info /Users/danielweck/Library/Developer/Xcode/DerivedData/SDKLauncher-iOS-edxulaokdyiopefmkrttdfypkoih/Build/Intermediates/ePub3.build/Debug-iphoneos/ePub3-iOS.build/Objects-normal/armv7/CPUCacheUtils_arm.o

Non-fat file: CPUCacheUtils_arm.o is architecture: armv7

Could you please check your "DerivedData" folder (as per the above file
path), and run "lipo -info" on "CPUCacheUtils_arm.o" when you build for
your iPhone 6 Plus?

—
Reply to this email directly or view it on GitHub
#38 (comment)
.

[Omarkth]

Hello, any updates regarding this? I'm facing the same problem when I try to release the "develop" branch.

[danielweck]

Hello @Omarkth I think (to be confirmed tomorrow) that we are going to make the hardware-specific "system cache erasure" feature optional in ReadiumSDK -based apps, by wrapping the code within an ifdef preprocessor directive. The default build configuration will not enable it, so this will effectively become an "opt-in" feature. Those who really need low-level cache control will be able to reinstate it, but they will need to check that their target platforms are properly supported (e.g. hardware-specific assembly code). The rationale for this change is (1) the ByteBuffer is zero'ed and this should sufficiently address confidentiality concerns (i.e. DRM / resource encryption), and (2) in the long term, the maintenance cost for such low-level platform-specific code does not seem to be justified, given the benefits.

See ByteBuffer::Clean() which invokes epub_sys_cache_flush():
https://github.com/readium/readium-sdk/blob/develop/ePub3/utilities/byte_buffer.cpp#L242
...which is defined here:
https://github.com/readium/readium-sdk/blob/develop/ePub3/utilities/CPUCacheUtils.h
https://github.com/readium/readium-sdk/blob/develop/ePub3/utilities/CPUCacheUtils.c
...along with "satellite" platform-specific implementations:
ARM (currently not working / not tested with arm64 / armv8):
https://github.com/readium/readium-sdk/blob/develop/ePub3/utilities/CPUCacheUtils_arm.S
i386:
https://github.com/readium/readium-sdk/blob/develop/ePub3/utilities/CPUCacheUtils_i386.S
x64:
https://github.com/readium/readium-sdk/blob/develop/ePub3/utilities/CPUCacheUtils_x64.S
Win:
https://github.com/readium/readium-sdk/blob/develop/ePub3/utilities/CPUCacheUtils_win.cpp

[Omarkth]

Thanks daniel, until this issue is resolved, and just to make the build work, I worked around it by providing an empty implementation of both functions epub_sys_cache_flush and epub_sys_cache_invalidate in the CPUCacheUtils.c.

Please let me know when a solution is found for the issue.

[AlanQuatermain]

On Dec 9, 2014, at 10:08 AM, danielweck [email protected] wrote:

the ByteBuffer is zero'ed and this should sufficiently address confidentiality concerns (i.e. DRM / resource encryption)

Just for the record, that’s the point of the cache-flush: if the buffer’s memory range is in the cache right now, then either the cache OR main memory will be zeroed. I think it’s cache that gets cleared, but I’m not certain. Using cache-flush ensures that both are set to zero. Without a cache flush, the decrypted data persists in memory for an indeterminate amount of time.

-Jim=

[rkwright]

Yes, but the problem is that as it stands it doesn't compile/link on a number of platforms (and the number of platforms is only going to increase). We don't have the resources to support this, so the question is this: Who requested this feature? I started/ran the eBook group (ACS4) at Adobe for years and we never had a request for such a low-level approach. As the head of security at that time stated (not in reference to this issue but one much simpler) "There are far easier vectors of attack than this, so why spend the effort on this FIRST? " Same question here.

[AlanQuatermain]

I put it in because that’s what was in the similar code I looked at inside Apple’s open-source encryption frameworks. I’m not wedded to it by any means, but I just wanted to make sure it was pointed out.

That said, I thought the ARMv7 code would work on ARM64. shrug

On Dec 9, 2014, at 4:08 PM, Ric Wright [email protected] wrote:

Yes, but the problem is that as it stands it doesn't compile/link on a number of platforms (and the number of platforms is only going to increase). We don't have the resources to support this, so the question is this: Who requested this feature? I started/ran the eBook group (ACS4) at Adobe for years and we never had a request for such a low-level approach. As the head of security at that time stated (not in reference to this issue but one much simpler) "There are far easier vectors of attack than this, so why spend the effort on this FIRST? " Same question here.

—
Reply to this email directly or view it on GitHub #38 (comment).

[danielweck]

FYI, here's the assembly code for sys_icache_invalidate from Libc-825.40.1, but it is not clear whether ARMv8 (AArch64) is supported:

http://www.opensource.apple.com/source/Libc/Libc-825.40.1/arm/gen/icacheinval.s

Header:

http://www.opensource.apple.com/source/Libc/Libc-825.40.1/include/libkern/OSCacheControl.h

Doc:

http://www.opensource.apple.com/source/Libc/Libc-825.40.1/sys/cache.3

The latest available versions are Libc-997.1.1 and Libc-997.90.3, but it looks like the "cache"-related functionality (above links) was removed:

http://www.opensource.apple.com/source/Libc/

As @AlanQuatermain (Jim Dovey) said, one could try adding defined(ARM64), check the 4-byte alignment, and see if it works.

[danielweck]

Addressed here:
readium/readium-sdk@0c6c54f