linux-kernel - Re: [Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 12 Oct 2019 15:09:55 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Discussions about the Letux Kernel <letux-kernel@...nphoenux.org>
Cc:     Merlijn Wajer <merlijn@...zup.org>, Adam Ford <aford173@...il.com>,
        Tony Lindgren <tony@...mide.com>,
        Philipp Rossak <embed3d@...il.com>,
        Paweł Chmiel <pawel.mikolaj.chmiel@...il.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Filip Matijević <filip.matijevic.pz@...il.com>,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
        moaz korena <moaz@...ena.xyz>,
        James Hilliard <james.hilliard1@...il.com>,
        maemo-leste@...ts.dyne.org,
        linux-omap <linux-omap@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kernel@...a-handheld.com, Robert Nelson <robertcnelson@...il.com>
Subject: Re: [Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

Hi,

> Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller <hns@...delico.com>:
> 
> So I have several ideas what the reasons for the problems on the non-omap5
> devices could be:
> * initial code may have some omap5 specific hack inside
> * or has omap5 specific magic constants
> * uKernel may "know" on which platform it runs and
>  we would need differently patched user-space code
>  for each one
> * omap5 has a dual core sgx544 while the other
>  have single core
> * the register address translation is not yet correct and
>  this inhibits communicating of the user-space libs
>  with the uKernel
> 
> Maybe, if someone can point me to a complete and working BeagleBone source
> tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare
> code and address setup to find what makes the difference.

I have found the following description, followed all steps, and it works:

http://blog.0xpebbles.org/PowerVR-SGX-on-the-beaglebone-black-in-2019

So with this, I have got a working user-space setup for BeagleBone and some working
pvrsrvkm.ko module (kernel 4.4.155-ti-r155) for evaluation.

Symbols of the kernel module are not stripped, so that I can indirectly compare
some build/configure options.

root@arm:~# uname -a
Linux arm 4.4.155-ti-r155 #1 SMP Thu May 23 06:00:18 UTC 2019 armv7l GNU/Linux
root@arm:~# ls -l /lib/modules/4.4.155-ti-r155/extra/ti335x/pvrsrvkm.ko
-rw-r--r-- 1 root root 408084 May 23 06:46 /lib/modules/4.4.155-ti-r155/extra/ti335x/pvrsrvkm.ko
root@arm:~# dmesg|fgrep -i pvr
[   24.589384] pvrsrvkm: loading out-of-tree module taints kernel.
[   25.051602] [drm] Initialized pvr 1.14.3699939 20110701 on minor 1
root@arm:~# sudo /usr/bin/pvrsrvctl --start --no-module
root@arm:~# cat /proc/pvr/version
Version SGX_DDK sgxddk MAIN@...9939 (release) omap_linux
System Version String: SGX revision = 125
root@arm:~# 

For comparison, I have:

root@...ux:~# uname -a
Linux letux 5.4.0-rc2-letux+ #1161 SMP PREEMPT Wed Oct 9 19:05:21 CEST 2019 armv7l GNU/Linux
root@...ux:~# ls -l /lib/modules/5.4.0-rc2-letux+/kernel/drivers/staging/pvr/1.14.3699939/eurasia_km/pvrsrvkm_omap_am335x_sgx530_125.ko
-rw-r--r-- 1 1002 root 4751504 Oct  9 17:09 /lib/modules/5.4.0-rc2-letux+/kernel/drivers/staging/pvr/1.14.3699939/eurasia_km/pvrsrvkm_omap_am335x_sgx530_125.ko
root@...ux:~# dmesg|fgrep -i pvr
[  119.376338] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
[  119.478943] [drm] Initialized pvr 1.14.3699939 20110701 for 56000000.sgx on minor 1
root@...ux:~# /usr/bin/pvrsrvctl --start --no-module
[  238.178801] PVR_K: UM DDK-(3699939) and KM DDK-(3699939) match. [ OK ]
PVR:(Error): LoaduKernelProgram : SGX ukernel program Device Addr: 0xe400000 invalid alignment
PVR:(Error): SetupuKernel : Failed to load uKernel program
PVR:(Error): SrvInit: Initialisation for device of class 0, type 7, index 0, failed (1) [0, ]
[  238.667915] PVR_K:(Error): BridgedDispatchKM: Initialisation failed.  Driver unusable.
PVR:(Error): PVRSRVBridgeCall: Failed to access device.  Function ID:3223086862 (strerror returns no value.). [0, ]
/usr/bin/pvrsrvctl: SrvInit failed (already initialized?) (err=PVRSRV_ERROR_OUT_OF_MEMORY - Unable to allocate required memory)
root@...ux:~# 

First observations:
* pvrsrvkm.ko is a little smaller (may be a result of compiler and build options)
* both taint the kernel, as expected
* they are exactly the same DDK release 1.14.3699939
* my version is a little more verbose
* but fails loading the uKernel

What I don't have yet is the full source code or build recipe for the specific
4.4.155-ti-r155 pvrsrvkm.ko from TI.

But even without having this yet, I can start experiments by replacing
kernel and pvrsrvkm.ko with mine. This should allow to gain new insights.

BR,
Nikolaus