10/7/2019 Drivers Allwinner A64 Linux
I got this interesting Tweet this morning from Ken Tindell @kentindell I decided to check what is this about and expand the message then LMAO! David Manouchehri @DaveManouchehri found interesting code in the Allwinner GitHub What does this means? If string “rootmydevice” pass through sunxidebug process it assigns you root privileges. My first though was who the hell will use the original extracted from Android Linux Kernel 3.4 made by Allwinner which contains binary blobs, when there is completely Free Open Source alternative developed by Linux-Sunxi community? And while thinking on it, scrolling down I found this: some guy decided to try it on his Orange Pi – you see the result, he got root access to the device by simple echo command!
And this is put with non-conditional flags i.e. Embedded always in the kernel you can’t remove it! If the guys from Allwinner were smart enough they would at least hide this in the binary blobs, so no one could see it! This is just yet another example what you are exposed to when use kernels which are with binary blobs inside, not speaking of the security quality of the code which Allwinner developers produce! Fortunately we use Linux-Sunxi community kernel which is 100% open source and no binary blobs! (well if you want hardware acceleration GPU drivers are still with binary blobs and no one knows what is inside, but this looks like heap of works and no one is interested to liberate them so far).
![]()
So you either take their kernel drop (3.10.65), take community's partially fixed one (then you're at 3.10.104 but this is still an ugly Android kernel that might contain severe flaws) or you wait for linux-sunxi community to get real mainline drivers later. Based on looking at Allwinner's tinalinux software offerings I doubt they will ever get that mainlining work should start at Allwinner already. Phoronix: Cedrus Video Decode Driver Moving Along With Allwinner H5/A64 Support With the Linux 4.20 kernel the Cedrus VPU decoder driver was mainlined that was developed this year over at Bootlin for providing open-source accelerated video support for Allwinner SoCs.
Here is what OLinuXino Kernel responds on the same command: What does this means? All devices which run Allwinner Linux Kernel 3.4 are subject to this backdoor security flaw and you can easily gain root access on any on them! BTW: You should keep in mind that the kernel tree you’re referring to (‘Linux-Sunxi community kernel which is 100% open source’) contains hardware drivers and stuff taken from Allwinner’s BSP kernel 3.4.39 released a few years ago. So while this specific local privileges escalation is not possible with the sun7i 3.4.103 kernel you use the drivers might hide other unwanted ‘surprises’.
Switching to mainline kernel is the better alternative for most use cases in the meantime. A10/A20 support is pretty good. And according to our download logs Lime/Lime2 users relying on Armbian prefer mainline over 3.4 already ?. ssvb. The mainline kernel also has privilege escalation bugs getting discovered on a regular basis.
Also some people are in fact interested in rooting their Android devices. So Allwinner might have probably thought that they were doing a good thing for their users ? See The users of the Chinese “Pi” clones based on the same A20 SoC can and do run the mainline kernel on their boards too. So the A20 boards from OLIMEX do not have any real advantage at least in the software support. But OLIMEX boards do have their own advantages because they are OSHW compliant, which is definitely a good thing.
Which ‘better alternative’ are you referring to? The problem only affects Allwinner’s BSP 3.4.x kernel released for H3/A83T last year (not A20 or any other Allwinner device — unfortunately you chose a rather misleading title for this blog post). H3/A83T contain different IP Blocks for many things and linux-sunxi community is still busy writing mainline code for this stuff from scratch. Until mainline kernel support for H3/A83T isn’t ready there simply has been no alternative if you wanted to run a H3 device a few weeks/months ago. Which kernel sources do you currently use for testing your new H3 based OlinuXinos?
BTW: While it’s a good idea to patch this flaw ASAP I would believe that most affected OS images relying on this kernel (for Orange and Banana Pi) are that insecure by design (sudo without authentication for default user) that it doesn’t matter that much whether the fix is applied or not. Any news on your H3 boards while we’re already at it? ?. Trackback:. Trackback:.
1, 2016, 5:39 p.m. Based on the Allwinner A64 user manual and on the previous sunxi pinctrl drivers this introduces the pin multiplex assignments for the ARMv8 Allwinner A64 SoC. Port A is apparently used for the fixed function DRAM controller, so the ports start at B here (the manual mentions 'n from 1 to 7', so not starting at 0). Signed-off-by: Andre Przywara -./bindings/pinctrl/allwinner,sunxi-pinctrl.txt 1 + arch/arm64/Kconfig.platforms 1 + drivers/pinctrl/sunxi/Kconfig 4 + drivers/pinctrl/sunxi/Makefile 1 + drivers/pinctrl/sunxi/pinctrl-a64.c 606 5 files changed, 613 insertions(+) create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c Comments.
![]()
2, 2016, 5:37 p.m. Hi, On Tue, Feb 02, 2016 at 03:58:52AM +0200, Siarhei Siamashka wrote: On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote: Based on the Allwinner A64 user manual and on the previous sunxi pinctrl drivers this introduces the pin multiplex assignments for the ARMv8 Allwinner A64 SoC. Port A is apparently used for the fixed function DRAM controller, so the ports start at B here (the manual mentions 'n from 1 to 7', so not starting at 0). 4, 2016, 4:51 p.m. Hi Andre, On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote: So, droping it in the filenames, why not. But I'd really like to keep the same compatible scheme.
And I still don't get this: in the DT compatible scheme we always have a vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. Core or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So why should we add an arbitrary and confusing sun50i naming to it (when it actually should be more like 'sun8i-a64').
I don't decide on their marketing names. And I know you want to start anew with the arm64 SoCs, but the truth is, you don't.
Most of the compatibles in the DTSI are from earlier SoCs, and we have to keep that legacy and remain consistent with it. With all the good and bad things a legacy imply. 8, 2016, 3:54 p.m. On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote: Hi AndreOn Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote: So, droping it in the filenames, why not.
But I'd really like to keep the same compatible scheme. And I still don't get this: in the DT compatible scheme we always have a vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. Core or a new Apple SoC.
Instead it is the A64 from Allwinner, full stop. So why should we add an arbitrary and confusing sun50i naming to it (when it actually should be more like 'sun8i-a64'). I don't decide on their marketing names. And I know you want to start anew with the arm64 SoCs, but the truth is, you don't. Most of the compatibles in the DTSI are from earlier SoCs, and we have to keep that legacy and remain consistent with it. With all the good and bad things a legacy imply. I have to agree.
Unless there is some agreement to move to another naming scheme, then just follow the same pattern. If sunXi is just a made up name outside of Allwinner to provide some logical grouping of SoCs, then yes, that probably should not have been done. Rob - To unsubscribe from this list: send the line 'unsubscribe devicetree' in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html. 8, 2016, 3:58 p.m. Hi, On 08/02/16 15:54, Rob Herring wrote: On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote: Hi AndreOn Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote: So, droping it in the filenames, why not.
But I'd really like to keep the same compatible scheme. And I still don't get this: in the DT compatible scheme we always have a vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. Core or a new Apple SoC.
Instead it is the A64 from Allwinner, full stop. So why should we add an arbitrary and confusing sun50i naming to it (when it actually should be more like 'sun8i-a64'). I don't decide on their marketing names. And I know you want to start anew with the arm64 SoCs, but the truth is, you don't. Most of the compatibles in the DTSI are from earlier SoCs, and we have to keep that legacy and remain consistent with it. With all the good and bad things a legacy imply. I have to agree.
Unless there is some agreement to move to another naming scheme, then just follow the same pattern. If sunXi is just a made up name outside of Allwinner to provide some logical grouping of SoCs, then yes, that probably should not have been done. So I still don't like it, but will not waste my time or energy on that front.
Maxime, do you want 'allwinner,sun50i-a64' or would 'allwinner,sunxi-a64' be OK as well? Cheers, Andre. To unsubscribe from this list: send the line 'unsubscribe devicetree' in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html. 9, 2016, 5:12 p.m. On Mon, Feb 08, 2016 at 03:58:18PM +0000, Andre Przywara wrote: HiOn 08/02/16 15:54, Rob Herring wrote: On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote: Hi AndreOn Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote: So, droping it in the filenames, why not. But I'd really like to keep the same compatible scheme. And I still don't get this: in the DT compatible scheme we always have a vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd.
Core or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So why should we add an arbitrary and confusing sun50i naming to it (when it actually should be more like 'sun8i-a64'). I don't decide on their marketing names.
And I know you want to start anew with the arm64 SoCs, but the truth is, you don't. Most of the compatibles in the DTSI are from earlier SoCs, and we have to keep that legacy and remain consistent with it. With all the good and bad things a legacy imply. I have to agree.
Unless there is some agreement to move to another naming scheme, then just follow the same pattern. If sunXi is just a made up name outside of Allwinner to provide some logical grouping of SoCs, then yes, that probably should not have been done. So I still don't like it, but will not waste my time or energy on that front. Maxime, do you want 'allwinner,sun50i-a64' or would 'allwinner,sunxi-a64' be OK as well? The former will be fine.
Maxime Patch.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |