Hello.
In this topic we talk about the Lenovo ICS versions and the home-brown self-made Ice Cream Sandwich I'm trying to build.
Currently I'm trying to port Ice Cream Sandwich (Android 4.0.4) to A1 IdeaPad by Lenovo.
Currently working:
* Touchscreen Input
* SGX530 Hardware Graphic Acceleration
* Orientation
* 3D Acceleration
* Brightness (using lights.omap3.so from Lenovo)
Not working:
* Audio
* ...
UPDATE 05.08.2012:
SGX530 Integration succeeded into Android AOSP ICS 4.0.4!
One should have to know that you have to use a DIFFERENT SGX DDK for ICS than for Gingerbread but that's not documented... [email protected] for ICS, 1.7.X for GB. Installed the proper components, ES=5.X and then we are rolling. I'm now trying to use some of the ICS libraries from the Lenovo ICS, but those have horrible dependencies. Thou I can most likely take the camera.omap3.so, I still want to be able to build those libraries from source, where available, so I gotta have to collect some stuff together. If this progresses nicely, I might be able to make a CM9 port here aswell, but for now, I need to get the rest of the functionallity working (WiFi driver [dhd_oob.ko] registers, but doesn't appear on the ICS yet, same for bluetooth. Sound is not working yet (E/AudioFlinger( 4034): createTrack_l() Bad parameter: sampleRate 44100 m 44100 format 1 m 1, channelMask 0x0000000 m 0x00000001 for output 0x3 with format 67520, e.a. channelMask is not doing what it should do), ...)
Again, I'm sorry that I don't have much spare time right now, so the progress is rather slow.
Status:
Right now Ice Cream Sandwich is booting, I had to patch SystemUI.apk to force hardware acceleration off. I tried to set debug.egl.hw=0 in the prop-file, but it didn't change anything, so I had to modify the source to hard-set it to accept no hardware acceleration.
I'm trying to get input to work, but it seems that the mg-capacity / Morgan Touch Capacity Display doesn't give proper values to InputReader. Since the libinput.so got massivly changed after switching from GingerBread to Ice Cream Sandwich, it doesn't seem to give proper values to the InputReader anymore. I patched/modified my libinput.so to display raw events and log them to logcat, but I gotta take a look if I have to write myself a wrapper for that.
UPDATE 31.03.2012:
- I was able to fix the missing BTN_TOUCH in the kernel sources. Now we have a working touchscreen.
- Added ro.sf.hwrotation 270, so the input is correct
UPDATE 25.07.2012:
- Sorry for the lack of updates, I currently don't have much spare time to work on this, sadly.
- What I found out is, that I was able to implement SGX530 libraries to Ice Cream Sandwich, but the driver wouldn't really activate my screen. To be honest, when i loaded the SGX drivers, my screen or speakers (not sure which) started to give this really high pitched noise. I'm not sure where it came from, but I'm sure I ****ed something up with the SGX drivers. We can't simply take the Gingerbread SGX Drivers to Ice Cream Sandwich, sadly. And we can't simply use the SGX Module from the version Lenovo provided, since they depend on a certain kernel module.
E.a. If you use a GingerBread Kernel with the Input Fix (like the one I compiled), you can boot Ice Cream Sandwich fine and stuff, but you can not use the SGX530 modules from the Lenovo ICS. (As this one flashes a new kernel version, and modifies the MBR and does other witch-craftery)
My ultimate goal would be, to use the Gingerbread Kernel from Lenovo with the additional screen input fixes for ICS and add the SGX/PowerVR 530 to that, so we would have hardware acceleration (for now). I want to avoid the 3.x kernel from Lenovo as much as possible as it seems to have various terrible problems in the regular use (disconnecting Wifi, standby problems, power supply problems, etc.)
We can't simply make an omap-kernel from the 3.x tree aswell, as we are missing lots of the arch/arm/mach-omap2/board-evt* and the important arch/arm/mach-omap2/board-evt1a.c which initializes our board for the boot process. And even if we could use a 3.x tree and implement powerVR into it, we would have to port ALL the changes Lenovo made to the sources (some MMC adaptions, power supply adaptions, modification to the rfkill, etc.) to the new kernel by which, most likely, lenovo will release either another pad or ICS for A1 (as it would take a HUGE amount of time).
So the goals are:
- Wait for Lenovo to stabilize the kernel of ICS and use their ROM.
OR:
- Use GB-Kernel from Lenovo Source Ball, try to implement PowerVR/SGX530 drivers and user-land applications to the ICS
- Slowly adapting other OMAP devices and libraries (brightness, vibration, sound, ...)
Chat:
#ideapad-a1 @ irc.freenode.net
(it's gmarkall's channel, but I hang out there.)
This is great. I look forward to seeing what you come up with.
My guess is that the Kernel is missing most of the drivers you need. I have been able to sort out this hardware so far:
CPU: TI OMAP3622 ARM® Cortex™-A8 processor
Video: PowerVR SGX530
Wireless: Broadcom BCM4329
Bluetooth: Broadcom BCM4329
Audio: TI TLV320AIC3110 (tlv320aic3111)
GPS: Broadcom BCM4751
I2C Ambient Light Sensor: Capella CM3217 (I2C) input5
Power Management: TI twl4030 (I2C)
Soft keypad?: TI twl4030 (I2C) input1
Capacitive Touch: TI twl4030 (I2C) input2
Power Button: TI twl4030 (I2C) input3
Back Camera: s5k5ca (3mp camera)
Front Camera: omap34xxcam Aptina MT9V115
Accelerometer (G sensor): Analog Devices ADXL345 (I2C) input4
Gyroscope: None
eCompass: None
Hopefully this helps when choosing kernel options.
---------- Post added at 08:58 AM ---------- Previous post was at 08:55 AM ----------
...additionally, the Nook Color is nearly the same hardware from what I can tell and they seem to be getting pretty far on ICS.
If someone can post a dmesg listing from a nook color, I can compare it to an A1 to try to document the hardware differences.
that's cool, I'm looking forward to your good news
It would be awesome to get ICS running on the a1!
nice work!
OK, some news:
It seems I'm pretty much f*cked until we get the sources for the kernel. The GB Kernel doesn't send the proper events for InputReader/EventHub.
I investigated the input within the system using the "getevent" tool (getevent -l).
The device itself seems to be able to report PRESSURE from what I've seen, just plain doesn't want to do it. (using 'dumpsys window')
It currently doesn't send a PRESSURE event which we need for activating the touchscreen. (Instead it gets sent by the redicoulus light sensor...)
One attempt would be to hack away and modify the InputReader to send a ABS_MT_PRESSURE event on every ABS_MT_X modification, or just wait for the sources.
On related note: I also tried to compile CM9 in an attempt to see if it may fix the input issuses or use a different input system, but it's just the same result as using vanilla ICS
spiegeleixxl said:
OK, some news:
It seems I'm pretty much f*cked until we get the sources for the kernel. The GB Kernel doesn't send the proper events for InputReader/EventHub.
I investigated the input within the system using the "getevent" tool (getevent -l).
The device itself seems to be able to report PRESSURE from what I've seen, just plain doesn't want to do it. (using 'dumpsys window')
It currently doesn't send a PRESSURE event which we need for activating the touchscreen. (Instead it gets sent by the redicoulus light sensor...)
One attempt would be to hack away and modify the InputReader to send a ABS_MT_PRESSURE event on every ABS_MT_X modification, or just wait for the sources.
On related note: I also tried to compile CM9 in an attempt to see if it may fix the input issuses or use a different input system, but it's just the same result as using vanilla ICS
Click to expand...
Click to collapse
Access to source would definitely make this a lot easier! Thankfully, the admin over at the Lenovo forum has promised to release the A1 source within the next week (just Google search "Lenovo Ideapad A1 source code", should be first or second link).
Thanks for spearheading this project. Would be great to see ICS on the A1!!
If you don't mind me asking, how exactly did you force hardware acceleration off inside of the SystemUI.apk? I'm currently working on doing something similar to this for the skyrocket, but I keep running into systeumui force closes.
One possible change would be changing the AndroidManifest.xml, i suppose:
frameworks/base/packages/SystemUI/AndroidManifest.xml: android:hardwareAccelerated="true"
Allthou I changed it somewhere in source, I can look it up for you later, try changing that XML option.
Great, can't wait for the A1 source being published - alas I would be glad if I would have any experience with linux/modding to help getting ICS to work on the A1 Kudos to spiegeleixxl for spearheading the development here!
Source Code released
finally Lenovo did it...
Thanks to Mark from Lenovo !
download.lenovo.com/lenovo/content/sm/A1-Kernel-Source.tgz
Unfortunately the source seems incomplete -> http://forum.xda-developers.com/showthread.php?t=1439451&page=23
drsnuggles79 said:
Unfortunately the source seems incomplete -> http://forum.xda-developers.com/showthread.php?t=1439451&page=23
Click to expand...
Click to collapse
Luckily enough the mg-i2c-driver is in there. It looks like it's failing to report some ABS_MT messages that are required for libinput/EventHub/InputReader to work. If gmarkall and me get the kernel compiled and working we can get rolling on porting ICS.
The graphics driver for ICS are also available via TI SGX SDK which is freely available.
So we're going into a good direction!
Great news. Is there anything that us noobs can do to help?!
tonyyeb said:
Great news. Is there anything that us noobs can do to help?!
Click to expand...
Click to collapse
spend money
otti17 said:
spend money
Click to expand...
Click to collapse
If by that you mean buy an A1, I'm already ahead of you!
waiting for your first build ..
how glad to see someone porting ICS to my cute A1 !
I've been searching someone trying to port ics since i bought A1 ...
wanna see a first build of ics to taste on my pad...
so much appreciate your works here .. guys....
Tint Ag Khaing said:
how glad to see someone porting ICS to my cute A1 !
I've been searching someone trying to port ics since i bought A1 ...
wanna see a first build of ics to taste on my pad...
so much appreciate your works here .. guys....
Click to expand...
Click to collapse
It's not like i can't give you a BUILD, you'll even SEE something, but you won't be able to DO something cause it doesn't register the press event.
What is the likelihood of getting to a beta stage with this?
AFAIK there are some touchscreen drivers-related issues.
[email protected]_a1
Hi guys,
I've written a completely new Android binder driver (for IPC), which is targeted to solve some fundamental issues in the existing driver. One main improvement is to make concurrent IPC calls possible. Some background info can be found in my earlier post on Android kernel group:
http: slash slash groups.google.com/group/android-kernel/browse_thread/thread/c57874670e4decb1
(oops external urls are not allowed for new users
There weren't many people interested due to low volume of the group. Now that I have completed the first version, which is back compatible with the existing driver, and fixed a few bugs. I've tested on the ICS emulator and my phone U8150 Froyo. It seems to be running quite well, but I want to see how it runs on other Android devices while I'm getting my new phone. Test results, bug/issue reports, and of course community comments will be very welcomed, which are important for me to determine how the code should further move on.
Although not proven, I'm expecting not only those dual core phones, but single core ones will get an overall smoother response in various parts of the system.
Okay if this still somehow interests you, you can find my project on github
https: slash slash github.com/rong1129/android-binder-ipc
and just dive into the release directory, use the latest version (0.4 so far) to patch your kernel source tree, then upload the new kernel image to your device and see whether it works for you.
Note this is still an early release and has very limited tests so far. Please make sure you understand the risk before you hack your phone and always back up everything before you started. As other disclaims go, I'm not responsible for any damage may be caused by or related to using or in the process of using the driver
Lastly, happy hacking!
Cheers,
Rong
*subscribing to this thread*
Hi Rong,
thank you so much
our phones, tablets, etc.
can't have too much smoothness
I hope that I'll find some time within the next weeks to also give this a test on the Xoom and see whether it works (with ICS; Team Eos kernel)
there at least seem to be issues with ICS on the SGS (galaxys s1)
http://forum.xda-developers.com/showpost.php?p=23937103&postcount=2502
I found this thread . Is this driver the same on all android devices and roms? Or do you have to mod it for every single device/rom?
This is a general service announcement. There is vulnerability in the Mali GPU drivers that allows for root access discovered by security researcher Man Yue Mo (CVE-2022-38181). The vulnerability goes way back and affects almost any device with a Mali GPU. That covers most of the FireHD tablets from the last 5 years, most of the FireTV televisions, and the 1st, 2nd and 3rd gen Cubes (and FireTV pendant).
Man Yue Mo posted a POC for the Pixel 6, that was adapted to work on the 2nd and 3rd gen FireTV Cubes. It takes a non-trivial number of changes to get it to work on other devices, and I don't have any FireHD tablets to work through it on. It appears that the cat's out of the bag on this exploit now, because the 2nd gen Cube just got an update that patches the POC. So I'm assuming a patch is coming (possibly even present) to other Fire devices as well, otherwise I would have kept it quiet for longer to try to work through some other devices.
Rortiz2 said:
This is really interesting and exciting. I wonder if this vulnerability affects any other Fire HD devices as well (obviously those using Mali GPUs). If you don't mind me asking, what are your plans regarding the PoC's source code? (nevermind, I think I found the original POC here). Could you give some hints regarding to what needs to be changed in order to port the exploit to other devices? I'd love to test it and learn more about this CVE.
Click to expand...
Click to collapse
I will try to post the source for the two Cube versions within the next day.
The Pixel 6 POC has to be modified for 32bit userspace, and there may need to be modifications to some of the struct's depending on which version of the Mali driver your device is using.
Kallsyms offsets need to be changed for any firmware you want to cover
Pool_size should be verified on your device
I'd also double check the path for define Mali, I've seen a couple devices that don't use the default path.
Lastly disabling selinux may need to be modified depending on the kernel version.
I'd start out with a device that you already have root on so that you can get any values needed, and use it as a potential template.
Edit: added 2nd and 3rd gen source code
Pro-me3us said:
I will try to post the source for the two Cube versions within the next day.
The Pixel 6 POC has to be modified for 32bit userspace, and there may need to be modifications to some of the struct's depending on which version of the Mali driver your device is using.
Kallsyms offsets need to be changed for any firmware you want to cover
Pool_size should be verified on your device
I'd also double check the path for define Mali, I've seen a couple devices that don't use the default path.
Lastly disabling selinux may need to be modified depending on the kernel version.
I'd start out with a device that you already have root on so that you can get any values needed, and use it as a potential template.
Edit: added 2nd and 3rd gen source code
Click to expand...
Click to collapse
Thank you for your the brief explanation regarding the changes that need to be made. We are currently attempting to exploit the Fire HD8 2020 (onyx), but have encountered an issue. We were able to extract the kallsyms table using this script, which seemed to work correctly. However, we have discovered that some of the kallsyms appear to be missing, specifically:
sel_read_handle_unknown: ffffff80083b08b0
selinux_enforcing: Doesn't seem to exist.
init_creds: Doesn't seem to exist.
commit_creds: ffffff80080dc530
add_init: Doesn't seem to exist.
add_commit: Doesn't seem to exist.
We have also observed that the tablet crashes after increasing FLUSH_SIZE (which seems to be normal as per the comments in the source code of the PoC), probably indicating that this device is indeed vulnerable to the CVE. Do you have any suggestions on how we can proceed with regards to the missing kallsyms?
Rortiz2 said:
Do you have any suggestions on how we can proceed with regards to the missing kallsyms?
Click to expand...
Click to collapse
I don't know if it's a good idea to go through methods publicly since it will help instruct Amazon on how to make future probing and intrusions harder for other exploits. I'll pm you
Rortiz2 said:
Thank you for your the brief explanation regarding the changes that need to be made. We are currently attempting to exploit the Fire HD8 2020 (onyx), but have encountered an issue. We were able to extract the kallsyms table using this script, which seemed to work correctly. However, we have discovered that some of the kallsyms appear to be missing, specifically:
sel_read_handle_unknown: ffffff80083b08b0
selinux_enforcing: Doesn't seem to exist.
init_creds: Doesn't seem to exist.
commit_creds: ffffff80080dc530
add_init: Doesn't seem to exist.
add_commit: Doesn't seem to exist.
We have also observed that the tablet crashes after increasing FLUSH_SIZE (which seems to be normal as per the comments in the source code of the PoC), probably indicating that this device is indeed vulnerable to the CVE. Do you have any suggestions on how we can proceed with regards to the missing kallsyms?
Click to expand...
Click to collapse
FYI, if you want to test anything on other devices i have almost everything 10 gen and below, including the hd8 (10). Totally dont care if i brick them, they arent used regularly... Including a unlocked and locked fire 7 (2019)
Graphics adapter
ARM Mali-T720 MP
I'll gladly run any testing on my devices as well. Fire 7 (2019) and HD 10+ (2021) both running firmware version 7.3.2.1.
I have an already-rooted Karnak (8th gen HD 8) that I can reflash to any OS needed - do let me know if it can be of any service to the cause.
Pro-me3us said:
I don't know if it's a good idea to go through methods publicly since it will help instruct Amazon on how to make future probing and intrusions harder for other exploits. I'll pm you
Click to expand...
Click to collapse
I am also facing trouble to find kallsyms - add_init add_commit values. can you help me to find that
mind _spacer said:
I am also facing trouble to find kallsyms - add_init add_commit values. can you help me to find that
Click to expand...
Click to collapse
The values you're referring to are not kernel symbols, but rather shellcode(s). You'll need to adjust the ADD_* values to align them with your specific kallsyms. The following example shows the correct values for the Amazon Fire HD8 2020 (onyx):
Code:
#define AVC_DENY_7314_1443 0x3252F4 // avc_denied.isra.6
#define SEL_READ_HANDLE_UNKNOWN_7314_1443 0x3308B0
#define PREPARE_KERNEL_CRED_7314_1443 0x5C8E8
#define COMMIT_CREDS_7314_1443 0x5C530
#define ADD_PREPARE_KERNEL_CRED_7314_1443 0x9123a108 // add x8, x8, #0x8E8 <-- prepare_kernel_cred
#define ADD_COMMIT_7314_1443 0x9114c108 // add x8, x8, #0x530 <-- commit_creds
As you can see, these values are ARM assembly opcodes encoded as 32-bit constants. In this case, they represent the add operation on the x8 register. To create these constants, you can use online converters or the ARM instruction set encoding.
For instance, add x8, x8, #0x8E8 is encoded into the 32-bit value 0x9123a108 using the following breakdown:
91000000 - Base value for ADD (immediate) instruction with 64-bit registers (this will be different for non-ARM64 archs).
00001000 - Destination and first operand register (x8 in binary).
00111010 - Immediate value to be added, rotated right by 12 bits (0x8E8 rotated - prepare_kernel_cred).
00000001 - Shift amount for immediate value (1*12, since immediate value is specified in multiples of 12).
I actually implemented a function to dynamically craft the values, but I never tried it so far. In case anyone is interested, this is how it looked like:
Code:
#define ADD_OPCODE_ARM64 0x91000000 // ARM64
#define ADD_OPCODE_ARM32 0xE0000000 // ARM32
uint32_t add_off_to_reg(uint32_t offset, uint8_t reg) {
uint32_t add_value = ADD_OPCODE_ARM64;
add_value |= reg; // Rd
add_value |= reg << 5; // Rn
add_value |= (offset & 0xFFF) << 10; // imm12
LOG("add x%d, x%d, %#x: 0x%08X\n", reg, reg, offset, add_value);
return add_value;
}
I hope this helps you!
Rortiz2 said:
The values you're referring to are not kernel symbols, but rather shellcode(s). You'll need to adjust the ADD_* values to align them with your specific kallsyms. The following example shows the correct values for the Amazon Fire HD8 2020 (onyx):
Code:
#define AVC_DENY_7314_1443 0x3252F4 // avc_denied.isra.6
#define SEL_READ_HANDLE_UNKNOWN_7314_1443 0x3308B0
#define PREPARE_KERNEL_CRED_7314_1443 0x5C8E8
#define COMMIT_CREDS_7314_1443 0x5C530
#define ADD_PREPARE_KERNEL_CRED_7314_1443 0x9123a108 // add x8, x8, #0x8E8 <-- prepare_kernel_cred
#define ADD_COMMIT_7314_1443 0x9114c108 // add x8, x8, #0x530 <-- commit_creds
As you can see, these values are ARM assembly opcodes encoded as 32-bit constants. In this case, they represent the add operation on the x8 register. To create these constants, you can use online converters or the ARM instruction set encoding.
For instance, add x8, x8, #0x8E8 is encoded into the 32-bit value 0x9123a108 using the following breakdown:
91000000 - Base value for ADD (immediate) instruction with 64-bit registers (this will be different for non-ARM64 archs).
00001000 - Destination and first operand register (x8 in binary).
00111010 - Immediate value to be added, rotated right by 12 bits (0x8E8 rotated - prepare_kernel_cred).
00000001 - Shift amount for immediate value (1*12, since immediate value is specified in multiples of 12).
I actually implemented a function to dynamically craft the values, but I never tried it so far. In case anyone is interested, this is how it looked like:
Code:
#define ADD_OPCODE_ARM64 0x91000000 // ARM64
#define ADD_OPCODE_ARM32 0xE0000000 // ARM32
uint32_t add_off_to_reg(uint32_t offset, uint8_t reg) {
uint32_t add_value = ADD_OPCODE_ARM64;
add_value |= reg; // Rd
add_value |= reg << 5; // Rn
add_value |= (offset & 0xFFF) << 10; // imm12
LOG("add x%d, x%d, %#x: 0x%08X\n", reg, reg, offset, add_value);
return add_value;
}
I hope this helps you!
Click to expand...
Click to collapse
Thank you for the brief reply, definitely it helped a lot.
Pro-me3us said:
I will try to post the source for the two Cube versions within the next day.
The Pixel 6 POC has to be modified for 32bit userspace, and there may need to be modifications to some of the struct's depending on which version of the Mali driver your device is using.
Kallsyms offsets need to be changed for any firmware you want to cover
Pool_size should be verified on your device
I'd also double check the path for define Mali, I've seen a couple devices that don't use the default path.
Lastly disabling selinux may need to be modified depending on the kernel version.
I'd start out with a device that you already have root on so that you can get any values needed, and use it as a potential template.
Edit: added 2nd and 3rd gen source code
Click to expand...
Click to collapse
Is this POC works on android devices (such as samsung) having mali driver , if its works can you tell me the modifications need to done on struct's and disable selinux depending on kernel version(which u mentioned) and what are the changes do we need to do?
mind _spacer said:
Is this POC works on android devices (such as samsung) having mali driver , if its works can you tell me the modifications need to done on struct's and disable selinux depending on kernel version(which u mentioned) and what are the changes do we need to do?
Click to expand...
Click to collapse
Knowing nothing about your device, it's hard to know what changes are required to get the POC to run. What is the device kernel version and Mali driver type and version? Is it using a 32bit or 64bit version of Android? Do you have a copy of the firmware that your device is currently using (most importantly boot.img)? Do you have the source code for the kernel? Is the source code for the same version of the firmware that your device is currently running?
There are a few ways to do things depending on what resources you have available to you.
Following....with my 2021 Fire HD 10 running 7.3.2.1
Pro-me3us said:
Knowing nothing about your device, it's hard to know what changes are required to get the POC to run. What is the device kernel version and Mali driver type and version? Is it using a 32bit or 64bit version of Android? Do you have a copy of the firmware that your device is currently using (most importantly boot.img)? Do you have the source code for the kernel? Is the source code for the same version of the firmware that your device is currently running?
There are a few ways to do things depending on what resources you have available to you.
Click to expand...
Click to collapse
This is the spec of my device:
Samsung M30s (M307FXXU4CVD1)
Android 11, 64-bit version
Kernel - 4.14.113
Security patch level - 1 Mar 2022
Mali - G72 MP3, version - r26 p0
I have the source code and firmware image of this device. And I have found the device specific offsets (from elf of kernel) and @Rortiz2 helped me to find some of it, kernel base address (by reading header of boot.img) and path defined for mali is correct.
I tried to run the original POC but device reboots at the after it prints "Cleanup flush region" part.
then, I tried ur poc which ends by "Release_mem_pool" and reboot.
Hope you could help me.
mind _spacer said:
G72 MP3, version - r26 p0
I have the source code and firmware image of this device. And I have found the device specific offsets (from elf of kernel) and @Rortiz2 helped me to find some of it, kernel base address (by reading header of boot.img) and path defined for mali is correct.
I tried to run the original POC but device reboots at the after it prints "Cleanup flush region" part.
then, I tried ur poc which ends by "Release_mem_pool" and reboot.
Click to expand...
Click to collapse
I'm assuming that Mali driver type is Valhall? or Bifrost? Midgard?
Valhall r26p0 might be recent enough that you don't need to make any struct changes to for older driver compatibility.
Since your device is using 64bit Android, I'd stick to the original Pixel6 POC. A lot of the changes in my two POCs was 64bit to 32bit conversations. The 32bit POC may work on your device, but I don't know if there are any incompatibilities. Better to avoid any potential 32bit complications.
What are the 6 kernel addresses that you plugged in to the Pixel6 POC for your device?
Pro-me3us said:
I'm assuming that Mali driver type is Valhall? or Bifrost? Midgard?
Valhall r26p0 might be recent enough that you don't need to make any struct changes to for older driver compatibility.
Since your device is using 64bit Android, I'd stick to the original Pixel6 POC. A lot of the changes in my two POCs was 64bit to 32bit conversations. The 32bit POC may work on your device, but I don't know if there are any incompatibilities. Better to avoid any potential 32bit complications.
What are the 6 kernel addresses that you plugged in to the Pixel6 POC for your device?
Click to expand...
Click to collapse
I'm trying to work with your gazelle POC as a base for amazon mustang (midgard r26p0), but I have some questions; what is alloc.in.flags (1 << 22) in spray()? It doesn't seem to match any base_mem_alloc_flags I could find for either the cube or the mustang.
I'm also getting -EPERM on the alias_sprayed_regions() mmap(), presumably because of MAP_SHARED. When ORed with MAP_ANON the mmap64 call succeeds, however find_pgd() then fails because the pages are all zeroed. Can you advise?
@Pro-me3us
A temp root would be great - at least, to make backups easier. is this new exploit realistic to get working on hd tablets? Do you have a tablet like that to try ?
relalis said:
I'm trying to work with your gazelle POC as a base for amazon mustang (midgard r26p0), but I have some questions; what is alloc.in.flags (1 << 22) in spray()? It doesn't seem to match any base_mem_alloc_flags I could find for either the cube or the mustang.
I'm also getting -EPERM on the alias_sprayed_regions() mmap(), presumably because of MAP_SHARED. When ORed with MAP_ANON the mmap64 call succeeds, however find_pgd() then fails because the pages are all zeroed. Can you advise?
Click to expand...
Click to collapse
I have never taken a look at Midgard.
Midgard r26p0 - July, 2018 (mustang)
Bifrost r25p0 - June, 2020 (gazelle)
Bifrost r16p0 - December, 2018 (raven)
Based on the timing, I would use the raven POC as your base, because the driver is likely more similar. This is related to the issue you were asking about. Bifrost r16p0 doesn't support the memory pool group which is that flag. Support for that was added somewhere between Bifrost r16p0 and r25p0, and Midgard r26p0 may not support it either. Check out the changes made in Raven, I basically just removed it.
bibikalka said:
@Pro-me3us
A temp root would be great - at least, to make backups easier. is this new exploit realistic to get working on hd tablets? Do you have a tablet like that to try ?
Click to expand...
Click to collapse
There are two parts to the POC, the GPU driver exploit, and disabling selinux to open a root shell. The GPU exploit portion should be mostly compatible between devices. If your device is using 64bit userspace, use the original Pixel6 POC which shouldn't have any driver incompatibilities back to about Bifrost r25p0 (2020). The Pixel6 uses Valhall, i'm not sure what driver version was available in 2020. If you have a device with 32bit userspace like most Amazon devices, then either the raven or gazelle POC should work for the GPU exploit portion. Midgard may have other unknown differences that need to be addressed
Disabling selinux / rootshell fixup portion is the part that needs to be modified to get the POC working with any individual tablet, because this portion has kernel specific instructions. This part of the POC probably isn't going to be as simple as swapping a couple kallsyms addresses. I think @Rortiz2 was working on getting the selinux / rootshell fixup working a few of the tablets. Using that as a base for the other MediaTek tablets might be more useful than my POCs, assuming they are more similar.
The new POC uses a race condition and the GPU portion is a bit more complicated, and may need more device specific tuning. The selinux / rootshell portion is mostly the same as the older exploit. The new user_buf exploit exploit mostlyonly has the advantage of working on Bifrost r38p0 which is the driver Amazon updated the Cubes to, to patch the shrinker exploit.
@mind _spacer sorry, I didn't notice your device kernel version before. The pixel6 POC handles the rootshell portion by disabling AVC_deny, for kernels older than 5.0 it may be easier to substitute selinux_enforcing, at least that's what was done for raven. I struggled a bit to get the rootshell portion working on both raven and gazelle. @rortiz was able to adapt it to one of the FireTablets in just a couple days, so he probably has a much better understanding and might be able to offer insights.
Pro-me3us said:
There are two parts to the POC, the GPU driver exploit, and disabling selinux to open a root shell. The GPU exploit portion should be mostly compatible between devices. If your device is using 64bit userspace, use the original Pixel6 POC which shouldn't have any driver incompatibilities back to about Bifrost r25p0 (2020). The Pixel6 uses Valhall, i'm not sure what driver version was available in 2020. If you have a device with 32bit userspace like most Amazon devices, then either the raven or gazelle POC should work for the GPU exploit portion. Midgard may have other unknown differences that need to be addressed
Disabling selinux / rootshell fixup portion is the part that needs to be modified to get the POC working with any individual tablet, because this portion has kernel specific instructions. This part of the POC probably isn't going to be as simple as swapping a couple kallsyms addresses. I think @Rortiz2 was working on getting the selinux / rootshell fixup working a few of the tablets. Using that as a base for the other MediaTek tablets might be more useful than my POCs, assuming they are more similar.
Click to expand...
Click to collapse
A bulk of Fire HDs was 32 bit user space indeed, armv8l was the kernel on many (HD10 2019 that i have). HD10 2021 became aarch64.
I thought @diplomatic had a fairly generic code to disable selinux fairly for all devices within his MTK exploit? Or was that a lot more different than here? Too bad a lot of old crew seems to have scattered, so much less capability around here these days (looking at @k4y0z here ).
What's the best way to find out the version of MALI driver that the device is using?
bibikalka said:
What's the best way to find out the version of MALI driver that the device is using?
Click to expand...
Click to collapse
KBASE_IOCTL_VERSION_CHECK will return param.major and param.minor API versions, as to the driver type (midgard/bifrost/valhal) you'll have to look at Amazon's source code release for the individual devices, or perhaps find the relevant page on postmarketos wiki