| 00:05 | _rmk_ | jnettlet: unfortunately... that causes a deadlock |
| 00:09 | _rmk_ | gckEVENT_Submit calls gckCOMMAND_Reserve -> _NewQueue -> gckEVENT_Signal -> gckEVENT_AddList which then tries to get the listMutex again |
| 00:12 | _rmk_ | easier maybe to change the order here |
| 00:20 | _rmk_ | hmm, but that may cause a locking inversion :( |
| 00:33 | _rmk_ | ok, that works. |
| 00:33 | _rmk_ | ... so far |
| 01:17 | _rmk | 01:17 * _rmk_ wonders if that will also solve the other problem I've been seeing: occasional lack of response from the GPU after boot |
| 01:18 | _rmk_ | jnettlet: does Marvell accept patches back in for the galcore stuff? |
| 07:16 | jnettlet | _rmk_, they will. I also have contacts at Vivante that I can try to get it to. Unfortunately Vivante's policy is not to work directly with the customers. That is usually about troubleshooting problems, not taking back fixes. |
| 07:17 | jnettlet | _rmk_, are you still running the galcore version that Solidworks has posted on their website or have you upgraded to the newest version of the driver and libraries? |
| 07:37 | jnettlet | It is a vivante GPU in the chromecast |
| 09:01 | shesselba | jnettlet: its Armada 1000 (88AP3010) in the Chromecast, basically Armada 370 CPU with pimped Armada 510 peripherals |
| 09:02 | shesselba | dual CPU, plus one for security stuff (most likely Feroceon or PXA) |
| 09:02 | shesselba | but that is all guessing ;) |
| 09:03 | jnettlet | are they using both cpu's? |
| 09:03 | jnettlet | on the XO we are running our EC code one the security processor |
| 09:03 | jnettlet | battery charging and keyboard/touchpad processing |
| 09:04 | shesselba | don't know if they use both CPUs on Cc, but there are two of them |
| 09:05 | shesselba | Dove's PMU also has some programmable core |
| 09:05 | shesselba | I'd guess this time it is feroceon |
| 09:05 | shesselba | that is virtually in _every_ Marvell Chip somewhere ;) |
| 09:10 | jnettlet | It is getting pretty disappointing that there are more and more Marvell chips popping up in hardware and yet they still seem to be the least supported upstream. |
| 09:25 | shesselba | well, at least for AXP and A370 they have contractors working on upstream, they are also discussing to (a) release open datasheets and (b) work on mainline A1k and A1k5 someday |
| 09:26 | shesselba | now with the gtvhacker's u-boot hack, I tempt to finally break into my sony nsz-gs7 and just try it first ;) |
| 09:26 | shesselba | luckily they are always reusing their peripherals |
| 10:20 | _rmk_ | jnettlet: I updated it to what you had a few months back, which was 0.8.0.2905 |
| 10:21 | jnettlet | _rmk_, okay great just checking |
| 10:22 | jnettlet | I have dropped a line to my Vivante contacts to see if they are willing to accept patches from the OSS community. |
| 10:23 | jnettlet | I will offer up to Marvell as well, but only after I have checked if their upstream is interested. Considering MIPS are using this GPU as well I would prefer to not have to push patches up through multiple vendors for a singular codebase. |
| 10:27 | jnettlet | _rmk_, there is actually a newer version that we obtained for our 2128 chips. It is based on Vivantes 4.x codebase. The Marvell version is 0.8.4609p8 |
| 10:37 | _rmk_ | is that in the olpc tree, and does it require userspace changes too? |
| 10:40 | jnettlet | _rmk_, yes and yes. It is in the arm-3.5 repo |
| 10:44 | dv_ | jnettlet: I think it is also disappointing that Marvell chips pop up more and more, and yet Marvell's support leaves so much to be desired |
| 10:45 | dv_ | ideally, they would have a Freescale-like support. Public docs, examples etc. |
| 10:45 | _rmk_ | jnettlet: gah, wish they'd get the clue that breaking the user API is bad practice |
| 10:45 | dv_ | the Freescale VPU documentation is very detailed and comprehensive. The vMeta documentation .... does not exist. |
| 10:45 | jnettlet | dv_, yeah I agree. I am hoping that Google using them may help push that. But only hoping. |
| 10:46 | dv_ | and their random code drops dont help either |
| 10:46 | dv_ | at least they could add some version numbers to them.. |
| 10:46 | jnettlet | _rmk_, yes. but that is because of the "major" revision jump. |
| 10:47 | dv_ | jnettlet: I think they do not realize that this kind of thing is a major and valid selling point. |
| 10:47 | jnettlet | the big change is the support for dual-core graphics chips like the GC1000 in the XO-4. 2D and 3D are two distinct cores. |
| 10:47 | jnettlet | I think they also bumped their OpenCL support revision, and possibly a newer version of OpenGL ES |
| 10:48 | dv_ | gles3 ? nice |
| 10:48 | jnettlet | I know that is why we had a pre-release of their software as our WebGL support in chromium was very problematic with the older driver. |
| 10:48 | dv_ | oh, jnettlet, any news on vmeta audio? |
| 10:49 | jnettlet | dv_, I haven't heard back from Marvell. It usually takes 2-3 weeks before I get a response |
| 10:49 | dv_ | okay |
| 10:49 | jnettlet | dv_, and glesv2.1 not 3 |
| 10:50 | jnettlet | before they were just glesv2 I believe |
| 10:50 | dv_ | 2.1 ? I cannot find any specs for 2.1 |
| 10:51 | dv_ | there is _desktop_ opengl 2.1 |
| 10:53 | _rmk_ | dv: you mean something like... VMeta 1.2 (Dove Y0) SA/SP build: 14271 20120202.1220 |
| 10:53 | dv_ | what is that? |
| 10:54 | jnettlet | dv_, v2.x not v2.1 |
| 10:54 | _rmk_ | vmeta_const_t has a version_string pointer, and that's retrievable by calling vmeta_get_const() |
| 10:54 | dv_ | ah |
| 10:54 | dv_ | no, I mean versioning of the code drops |
| 10:54 | _rmk_ | all documented in vdec_api.h |
| 10:54 | dv_ | the IPP stuff, the miscgen, libvmeta etc. |
| 10:55 | _rmk_ | why are you using miscgen? |
| 10:55 | dv_ | I use vmeta through IPP |
| 10:56 | dv_ | initially I wanted to use the vdec functions directly, but I was concerned about things I may be missing. at least with the IPP way there are the marvell plugins I can use as an example |
| 10:57 | _rmk_ | take a look at what MiscGeneralCallbackTable contains, and search the header files for similarly called functions, which will give you their prototypes |
| 10:57 | dv_ | I can imagine it is similar to the Freescale libraries imx-lib and libfslvpuwrap. the first one is a thin layer over ioctl calls, the second one is a higher-level one that takes care of some hardware bug workarounds et.c |
| 10:57 | _rmk_ | there's even examples of that in the marvel-ipp examples |
| 10:59 | dv_ | hmm yes. although the decoder works very well now, I would like to get rid of the IPP layer if it does not give me the same benefits libfslvpuwrap gives me over imx-lib |
| 10:59 | dv_ | still... there are other, bigger TODOs right now |
| 11:02 | jnettlet | dv_, I may have asked you this already. Which compiler are you using for your OpenEmbedded builds? |
| 11:03 | dv_ | whatever is built by openembedded |
| 11:03 | dv_ | gcc 4.7 I think |
| 11:03 | jnettlet | okay so you aren't doing any iwmmxt optimizations |
| 11:03 | dv_ | unfortunately no |
| 11:03 | dv_ | this is rather tricky to get in before gcc 4.8 |
| 11:03 | jnettlet | gcc 4.8 has the iwmmxt fixes in it |
| 11:03 | dv_ | I am using openembedded through Yocto btw. |
| 11:04 | dv_ | yes, gcc 4.8 has the PJ4 as separate machine |
| 11:04 | dv_ | (I use Yocto dylan, the current stable version) |
| 11:04 | jnettlet | but it is still missing the scheduling optimizations. I still need to push that again on the mailing list. |
| 11:04 | dv_ | oh, also, I pushed gstreamer 1.0 upstream to OE. will be included in the next release. until then, you can use my OE gstreamer 1.0 layer |
| 11:05 | jnettlet | I do have a patchset for gcc 4.7 but it has a couple of bugs that seem to have been fixed in 4.8, just never tracked them down |
| 11:05 | jnettlet | okay great. |
| 11:05 | dv_ | here: https://github.com/dv1/meta-gstreamer1.0 |
| 11:06 | jnettlet | I also have an optimized iwmmxt vp8 optmized decoder from Marvell. I have to finish porting it to the vpx 1.x codebase though. It is based on 0.8 |
| 11:07 | dv_ | speaking of vp8, is there a vmeta version that supports it? |
| 11:07 | jnettlet | apparently the vmeta chip in the chromecast supports it. |
| 11:08 | jnettlet | but when we pressed Marvell about it for our mmp2 chips trying to get google talk support working they provided an iwmmxt optimized software solution |
| 11:09 | _rmk_ | sorry, to repeat probably old questions, but is vmeta Marvell's own IP? |
| 11:10 | jnettlet | The Armada 1500 supports vp8 SD/HD decoding in hardware. |
| 11:10 | jnettlet | _rmk_, yep it is Marvells |
| 11:11 | jnettlet | I don't know if they bought a company at some point to get it, but everything comes from Marvell |
| 11:12 | _rmk_ | I wonder whether its possible to persuade them to open it up a little more, down to providing the slices and metadata rather than giving it a stream then |
| 11:13 | jnettlet | My guess would be Google may be the only entity that could make that happen. Marvell is only persuaded by purchasing volume |
| 11:14 | dv_ | similar to broadcom? |
| 11:15 | jnettlet | I think similar to all chip manufacturers in Asia |
| 11:15 | _rmk_ | in which case, what I might do instead is the black box treatment on libvmetahal - provide stimulus and monitor behaviour (in terms of how to talks to the hardware) and come up with something that will do slices |
| 11:17 | jnettlet | Here is the version that the Chromecast spits out. VMeta 2.5.3 (BG2-CD-1) SA/SP/2K/h264/vp8 build: 19143:20006M 20130605.1108 |
| 11:17 | _rmk_ | much later |
| 11:17 | jnettlet | I guess that means the pxa2128 chip in the XO-4 should theoretically do vp8 as well |
| 11:19 | jnettlet | or not. |
| 11:19 | _rmk_ | ok, so what's the latest available (to us) hard-float vmeta libraries? |
| 11:22 | jnettlet | I have VMeta 2.2 on the XO-4 |
| 11:22 | jnettlet | looking for a 1.75 |
| 11:23 | jnettlet | and that was the newest that was provided as of June and it was like pulling teeth to get it. |
| 11:23 | jnettlet | I have one newer tarball to look to see if there is a newer version |
| 11:26 | jnettlet | VMeta 2.2 (MMP2X) SA/DP build: 18861 20130131.1700 is the newest version I have. |
| 11:26 | jnettlet | let me see if it requires NEON |
| 11:27 | jnettlet | actually I take that back. It is not compiled for hardfp.....grrr |
| 11:31 | _rmk_ | if I had more time and stuff setup, I'd try some of this stuff out on the XO-4 (cjb sent me one) |
| 11:32 | _rmk_ | bbiab |
| 11:35 | jnettlet | VMeta 1.8 (MMP2 A0) SA/SP build: 15593 20110904.2253 is the latest that I have that came in a build for a non NEON ipplib. However if you are not using ipplib then the newer version should work |
| 11:36 | jnettlet | I have not tried to mix or build a newer libvmeta against an iwmmxt libipp and associated codecs and a newer libvmetahal |
| 11:37 | jnettle | 11:37 * jnettlet really needs to walk the dogs now. |
| 11:40 | jnettlet | _rmk_, I am still finishing hdmi audio support for the XO-4. hdmi video will get a new driver once I switch over to your armada-drm driver |
| 11:41 | dv_ | jnettlet: did you encounter the static in the audio signal as well? |
| 11:41 | dv_ | I hear it with 44.1 kHz. 48 kHz is fine. |
| 11:51 | rabeeh | dv_: running with xbmc 44.1khz i don't hear that static |
| 12:26 | jnettlet | dv_, the audio on the XO's is different than the cubox. Completely different codecs. |
| 12:34 | jnettlet | dv_, which version of libvmeta/hal/ipplib are you testing against? |
| 12:34 | dv_ | jnettlet: the ones from https://github.com/dv1/meta-cubox/tree/dylan |
| 12:36 | jnettlet | and you are still using libbbm? |
| 12:36 | jnettlet | libbmm sorry |
| 12:37 | dv_ | yes, although I think only the marvell plugins depend on that |
| 12:39 | _rmk_ | okay, the same version that I have then |
| 12:42 | dv_ | jnettlet: btw, does the newest version of my plugins build for you out of the box, without patching? |
| 12:44 | jnettlet | dv_, will test now. |
| 12:45 | dv_ | thanks. also, you said that you had to comment out the suspend calls. |
| 12:45 | jnettlet | will test both |
| 12:45 | dv_ | yeah please, I am not sure if I disabled it the correct way in case the suspend calls are not detected |
| 12:48 | jnettlet | dv_, worked fine. |
| 12:48 | dv_ | nice |
| 12:49 | dv_ | just out of curiosity, when you patched it, did you disable gst_vmeta_dec_suspend_and_resume() like I did? |
| 12:49 | dv_ | (as in, effectively commented out the whole thing) |
| 12:54 | jnettlet | yep |
| 12:56 | jnettlet | oh so your openembedded still using the libvmeta.so that uses libbmm for allocations. I will need to update that to support libphycontmem and the newer libvmeta.so |
| 12:57 | dv_ | actually, I need to update the layer |
| 12:57 | jnettlet | it is trivial to patch libphycontmem to also detect and support libbmm at runtime |
| 12:57 | dv_ | there are newer versions of libvmeta on dev.laptop.org |
| 12:57 | dv_ | and these already use libphycontmem |
| 12:57 | jnettlet | yep |
| 12:58 | jnettlet | actually, I may have to provide those to you. I think they got yanked due to codec licensing garbage. |
| 12:59 | dv_ | oh |
| 12:59 | dv_ | no, providing them to me isnt enough for OE |
| 12:59 | dv_ | to add them to OE, they need to be publicly accessible |
| 13:00 | jnettlet | I have been meaning to put them in a github repository. Marvell's licensing is free to re-distribute unmodified |
| 13:00 | dv_ | huh |
| 13:00 | dv_ | weird licensing |
| 13:00 | dv_ | so if you spot a bug, you have to keep them in patch files? |
| 13:00 | dv_ | *you have to keep the fixes in patchfiles |
| 13:00 | jnettlet | that is on their binaries |
| 13:01 | jnettlet | libphycontmem is GPL |
| 13:01 | dv_ | ah alright |
| 13:01 | jnettlet | let me check libvmeta, that must be as well. |
| 13:02 | jnettle | 13:02 * jnettlet is not the build master / purveyor of licenses. |
| 13:03 | jnettlet | yeah libvmeta is GPL v2.1 |
| 13:04 | jnettlet | dv_, the repos are on olpc's git. I think we should probably move them to github as the OLPC dev team is pretty minimal right now. |
| 13:06 | dv_ | alright |
| 13:06 | dv_ | yes that would be good |
| 13:06 | dv_ | including the driver repo |
| 13:07 | _rmk_ | jnettlet: umm... |
| 13:07 | jnettlet | yeah I need to bite the bullit and sort out my local binary versioned repos. |
| 13:07 | jnettlet | _rmk_, yes? |
| 13:07 | _rmk_ | LGPL I hope |
| 13:08 | jnettlet | nope just GPL |
| 13:08 | jnettlet | at least the version provided to OLPC |
| 13:08 | _rmk_ | that's not legal then |
| 13:08 | _rmk_ | my version says: |
| 13:08 | _rmk_ | * This library is free software; you can redistribute it and/or |
| 13:08 | _rmk_ | * modify it under the terms of the GNU Library General Public |
| 13:08 | _rmk_ | * License as published by the Free Software Foundation; either |
| 13:08 | _rmk_ | * version 2 of the License, or (at your option) any later version. |
| 13:10 | _rmk_ | and that's in vmeta_lib.c |
| 13:10 | jnettlet | _rmk_, sorry yes LGPL. I was referring to a licensing email not the source. Project manager screw up. |
| 13:11 | jnettlet | it was corrected further down the thread |
| 13:11 | _rmk_ | or is it... debian/copyright disagrees, says its GPL3 |
| 13:11 | _rmk_ | and that has been modified to include Marvell email addresses |
| 13:12 | jnettlet | as copyright holders they could have changed the licensing |
| 13:12 | _rmk_ | someone needs to kick Marvell in the nuts and give us a clear statement on the license here :) |
| 13:12 | dv_ | a clear statement on many more things as well |
| 13:12 | _rmk_ | debian/copyright says: |
| 13:12 | _rmk_ | This work was packaged for Debian by: |
| 13:13 | _rmk_ | ubuntu on Sun, 17 Oct 2010 00:24:16 -0400 |
| 13:13 | _rmk_ | ... |
| 13:13 | _rmk_ | License: |
| 13:13 | _rmk_ | This program is free software: you can redistribute it and/or modify |
| 13:13 | _rmk_ | it under the terms of the GNU General Public License as published by |
| 13:13 | _rmk_ | the Free Software Foundation, either version 3 of the License, or |
| 13:13 | _rmk_ | (at your option) any later version. |
| 13:13 | jnettlet | hmmm, and our libphycontmem code has no license on it just copyright Marvell 2010 all rights reserved. Which isn't even correct as I wrote it. |
| 13:14 | dv_ | public domain then :o) |
| 13:14 | jnettlet | well I wrote the original ION support code and Daniel did the auto-detection and cleanup. |
| 13:14 | _rmk_ | I'll have to check what GPLv3 says, but I suspect that if libvmeta is GPLv3, then it creates a very dubious legal situation |
| 13:15 | jnettlet | but if it is released under different licenses to different projects and there is no central repo, which one wins? |
| 13:16 | _rmk_ | is [email protected] your contact at Marvell? |
| 13:16 | jnettlet | nope |
| 13:16 | _rmk_ | hmm, I bet that email address doesn't work anymore |
| 13:16 | jnettlet | probably not, but you can try. |
| 13:18 | jnettlet | I know OLPC has been cleared to release the code that is in the repos, and associated binaries. |
| 13:20 | _rmk_ | and yours definitely says GPLv2? |
| 13:20 | _rmk_ | sorry LGPLv2 |
| 13:21 | jnettlet | _rmk_, http://dev.laptop.org/git/users/dsd/libvmeta/tree/vmeta_lib.c |
| 13:21 | jnettlet | that does say GPL. |
| 13:22 | jnettlet | and here is the binary only license in the same source. http://dev.laptop.org/git/users/dsd/libvmeta/tree/vdec_os_api.h |
| 13:23 | _rmk_ | 6 License: GPLv2+ |
| 13:23 | jnettlet | and I have a separate vmetalib.c that is LGPLv2 |
| 13:23 | _rmk_ | and... |
| 13:23 | _rmk_ | That vmeta_lib.c you pointed at is LGPLv2 |
| 13:24 | _rmk_ | root/Android.mk... |
| 13:24 | _rmk_ | 3 # Licensed under the Apache License, Version 2.0 (the "License"); |
| 13:24 | _rmk_ | so almost every file in this is licensed under a separate license... |
| 13:25 | jnettlet | _rmk_, the vmeta_lib.c says GNU Library General Public License, doesn't that have to be GNU Lesser General Public License |
| 13:26 | _rmk_ | "Library" |
| 13:26 | dv_ | Library is older |
| 13:26 | dv_ | but its just a different naming, it is the same license |
| 13:26 | jnettlet | ah okay. sorry for the confusion. |
| 13:26 | jnettlet | I have another version with the newer licensing convention at the top |
| 13:26 | _rmk_ | jnettlet: not your confusion :) |
| 13:27 | jnettlet | :-) |
| 13:27 | _rmk_ | I think its Marvell that's confused |
| 13:27 | dv_ | jnettlet: btw, if you sort out this mess with the different library versions etc. and put all of them in a nice and clear github repo (or multiple repos, one per library), you'd be my hero :) |
| 13:28 | jnettlet | you guys can answer this question better than me as I am new to the EU. What is the general rule in terms of media codec software. |
| 13:29 | _rmk_ | "550 No such user - psmtp" |
| 13:29 | dv_ | I am not aware of any general rule |
| 13:29 | dv_ | what do you mean? patent licenses? |
| 13:29 | jnettlet | patents, but specifically for codecs. |
| 13:29 | _rmk_ | is what marvell's mail server said in response to [email protected] |
| 13:29 | jnettlet | Are they lumped in under software patents? |
| 13:29 | dv_ | generally, there are no software patents in the EU |
| 13:30 | dv_ | in practice though they exist "under the radara" |
| 13:30 | jnettlet | _rmk_, that doesn't surprise me. Developers move through there pretty quick. |
| 13:30 | dv_ | *radar |
| 13:32 | dv_ | jnettlet: I recommend talking to an IP attorney about this. from what I know, the situation is quite complicated in the EU, since you also have to respect national laws |
| 13:33 | _rmk_ | if you want some hints look at the legal statements on videolan.org's website concerning libaacs... their position on this is: |
| 13:33 | jnettlet | that is what I was thinking of doing. |
| 13:33 | _rmk_ | "Neither French law nor European conventions recognize software as patentable (see French section below). Therefore, software patents licenses do not apply on VideoLAN software." |
| 13:34 | _rmk_ | they refer to a ruling on this too |
| 13:34 | jnettlet | Maybe we can get some Frenchie's to host the ipplib repo then |
| 13:35 | dv_ | _rmk_: true, however GB does allow software patents for example |
| 13:35 | jnettlet | I guess ipplib should probably be spit into the -hardware and -software decoding components |
| 13:36 | jnettlet | because those binaries are either NEON optimized or iWMMXt optimized making versions important. |
| 13:37 | dv_ | yes |
| 13:37 | dv_ | agreed |
| 13:38 | jnettle | 13:38 * jnettlet wonders if I can persuade Marvell to provide up to date vmeta libraries for all of the above. |
| 13:39 | _rmk_ | preferably with clear license statements for each (especially the open source bits - libbmm and libvmeta) |
| 13:39 | jnettlet | _rmk_, are you still set on sticking with libbmm or could you be persuaded to roll libbmm into libphycontmem to simplify things? |
| 13:40 | _rmk_ | I'm not overly attached to libbmm if that's what you're asking :) |
| 13:41 | _rmk_ | it probably needs a bit of hacking to add dma_buf support |
| 13:41 | jnettlet | well I know Linaro is working on integrating ION mm with dma_buf |
| 13:42 | jnettlet | which is why I jumped on that bandwagon |
| 13:42 | jnettlet | and it supports dynamic memory allocation through CMA |
| 13:44 | _rmk_ | what I may do is augment libvmeta to have some more APIs so that the only thing that interfaces with the memory management is that library |
| 13:45 | _rmk_ | that's mostly what already happens though |
| 13:45 | dv_ | how are the vdec_ alloc calls tied into BMM and phycontmem btw? |
| 13:46 | jnettlet | pretty much a straight up wrapper |
| 13:46 | dv_ | do they use bmm internally inside libvmeta? ( I cannot look it up right now) |
| 13:46 | _rmk_ | yes |
| 13:46 | dv_ | okay, thanks |
| 13:46 | _rmk_ | libvmeta just wraps them |
| 13:46 | dv_ | then i am using whatever libvmeta is using :) |
| 13:47 | _rmk_ | the old libgstvmetadec.so doesn't link directly with libbmm |
| 13:47 | jnettlet | so vdec_ is the api which doesn't change and then that used to go straight to libbmm. Then Android switched to pmem so Marvell created libphycontmem which was another abstraction and could be used with different backends at compile time. |
| 13:47 | dv_ | yes. the modified xvimagesink does |
| 13:48 | _rmk_ | gut libgstbmmxvimagesink.so does |
| 13:48 | _rmk_ | but |
| 13:48 | jnettlet | dv_, it does to query the physical addresses right? |
| 13:48 | dv_ | yes |
| 13:48 | dv_ | to map the virt addr to a physical one |
| 13:49 | _rmk_ | note that libphycontigmem isn't going to be mainline-able, because it exposes physical addresses to userspace |
| 13:49 | jnettlet | anyways the end of the story is. Marvell abstracting to libphycontmem actually made it trivial for me to add ION support and now we can easily support ION/PMEM/BMM with runtime detection |
| 13:50 | jnettlet | _rmk_, yep I realize that. |
| 13:50 | _rmk_ | the whole "get a physical address and hand it to hardware" is one massive security hole |
| 13:51 | dv_ | sure, ideally, you'd have to use a map/unmap mechanism I guess |
| 13:51 | _rmk_ | you'd do something like DRM does and passes buffer IDs in the GPU stream, and a set of "relocations" so that the kernel fixes them up to real physical addresses |
| 13:51 | dv_ | yes. buffer IDs and mapping to access the data |
| 13:52 | dv_ | just like it is done with OpenGL buffer objects for example |
| 13:52 | _rmk_ | that's never going to happen for vmeta :( |
| 13:52 | dv_ | unfortunately |
| 13:52 | dv_ | but that would be one killer infrastructure |
| 13:52 | jnettlet | isn't that what dma-buf is aiming for. |
| 13:53 | jnettlet | s/./?/ |
| 13:53 | _rmk_ | dma-buf sorts out passing between subsystems without userspace getting the details of the buffer |
| 13:54 | _rmk | 13:54 * _rmk_ goes in search of caffeine |
| 13:54 | jnettlet | as long as libvmetahal needs physical addresses there isn't much we can do to fix this problem. |
| 13:55 | jnettlet | so it won't be upstreamable but we can make it as easy as possible for other distros to pull in support if they need to run on the hardware. |
| 23:08 | dv_ | hey, is this a good example of the severity of the physical address security hole? |
| 23:08 | _rmk_ | hmm? |
| 23:08 | dv_ | you pass on a physical address to the hw encoder as the source of the "pixels" |
| 23:08 | dv_ | in truth, these "pixels" arent image data. |
| 23:09 | dv_ | you circumvent any kind of memory protection with this |
| 23:09 | _rmk_ | here's an easier one: |
| 23:10 | _rmk_ | set up a GPU raster copy operation. Set the physical destination address to be the start of kernel space. Set the source address to be your own compromised kernel. Tell it to do the copy... |
| 23:10 | dv_ | oh. nice one. |
| 23:11 | _rmk_ | or if you want to find something more... elaborate. |
| 23:12 | dv_ | no thats good |
| 23:12 | _rmk_ | mpeg2 compress a kernel. use vmeta to decompress it in place of the existing kernel and hope the loss isn't too significant :) |
| 23:12 | dv_ | I was thinking of snooping passwords and private keys with the encoding trick |
| 23:12 | rabeeh | haha |
| 23:12 | rabeeh | nice one _rmk_ |
| 23:14 | _rmk_ | rabeeh: fortunately, this is nothing new, but unfortunately some people don't realise just how big a hole it is |
| 23:14 | dv_ | _rmk_: fortunately, desktop video hardware accelerator APIs do not seem to suffer from this |
| 23:14 | _rmk_ | it basically means user level access to vmeta or the gpu is a security hole you can fly a dreamliner through. |
| 23:15 | dv_ | unfortunately, embedded devices are extremely popular these days, so people are walking with huge security holes around |
| 23:15 | _rmk_ | dv: that's because the DRM subsystem was invented and specifically addressed this |
| 23:15 | _rmk_ | if it weren't for DRM, desktops would have the same problem |
| 23:16 | dv_ | you can upload a completely new kernel, and do not even have to be root |
| 23:17 | _rmk_ | exactly |
| 23:17 | dv_ | jesus |
| 23:17 | dv_ | I hope at least freescale would listen to this |
| 23:17 | dv_ | and move to something like dmabuf |
| 23:17 | _rmk_ | you can download the existing one too, modify it slightly to give yourself a hidden backdoor, and load it back up. |
| 23:18 | dv_ | so, my rootkit is a special mpeg video. nice |
| 23:18 | _rmk_ | dv: dmabuf is not the answer. dmabuf is just about solving the "how to pass buffer B out of subsystem X into subsystem Y" |
| 23:19 | dv_ | _rmk_: at least you use FDs then instead of passing around addresses directly |
| 23:19 | _rmk_ | dv: possibly. through my investigations today, (dumping all register reads/writes) I don't believe that vmeta hardware is given an upper bound on the size of a decoded frame. |
| 23:20 | _rmk_ | maybe that's in the software libs though when it parses the metadata |
| 23:21 | dv_ | hmm am I missing something? if the API only returns FDs, you need to map/unmap to access the buffer memory, and all the other places use FDs (graphical output etc.) , is there still a security hole left? |
| 23:22 | _rmk_ | dv: this is why I finally killed the bmm passing method on the head in my X server |
| 23:23 | dv_ | oh wait, dmabuf does not do all of that? |
| 23:23 | dv_ | because I am confused as to what the connection between drm and dmabuf is |
| 23:23 | _rmk_ | things you can do with a dmabuf fd: |
| 23:23 | _rmk_ | 1. you can pass it into another subsystem which accepts dmabuf fds to give it access to that DMA buffer |
| 23:23 | _rmk_ | 2. you can close the fd |
| 23:24 | _rmk_ | 3. you can mmap() the fd (which will be limited to the buffer) if the buffer supports mmap |
| 23:24 | dv_ | with refcount? |
| 23:24 | _rmk_ | yep |
| 23:24 | _rmk_ | fully refcounted |
| 23:24 | dv_ | okay |
| 23:24 | _rmk_ | those three things are the limit to what userspace can do with it |