Closed thinkpanzer closed 1 year ago
See also https://lkml.org/lkml/2022/1/24/3382
Just to avoid any misunderstanding, we don't do any kernel development. It should be mainline kernel. I guess @MichaIng could explain in detail which kernel is used exactly.
It is indeed FriendlyELECs kernel. There is currently no alternative since mainline kernel support is not there and also Armbian has no proper build/kernel support for them (both R5S and R6S) yet.
Don't ask me why FriendlyELEC has this enabled in their official kernel builds. I'll check with their sources and open a PR to disable it.
Interesting, here the commit: https://github.com/friendlyarm/kernel-rockchip/commit/861a024589b3f42ca93877bf74f8a67f59c66ca8
This doesn't introduce security or safety issues for Android since debugfs itself is already considered unsafe and mounting it isn't allowed on user devices.
So this is an Android-only change while this is not feasible for Linux. Since FriendlyELEC user the same branch for Android and Linux, there may be other such Android commits merged into the Linux kernel which shouldn't be there. I'll open an issue, since not sure how to resolve best. Actually splitting branches and reverting ALL commits merged from AOSP/Android repos would be best.
Even more interesting, this commit along with all those merges from Android is coming from Rockchip's Linux branch, so FriendlyELEC is not responsible, but Rockchip: https://github.com/rockchip-linux/kernel/blob/develop-5.10/drivers/clk/clk.c#L3110
Okay, I informed now both, FriendlyELEC and the Rockchip kernel developer. I'm confused that this made it's way into official end user images since a long time already and no-one recognised or complained until our users see the hard to overlook warning emitted by the kernel 🤔.
Further links for background:
What you can do is this:
find /sys/kernel/debug/clk -perm 644 -exec chmod a-w {} +
# or
chmod a-w /sys/kernel/debug/clk/*/clk_{rate,prepare_enable}
It is two files in all clk sub directories which are writable by the root user clk_prepare_enable
and clk_rate
. This removes the write bit. But the root user can re-add it so it is not really a solution but at best prevents against accidents. This needs to be changed in kernel sources, to that the UNIX permissions have no effect but you get
-bash: echo: write error: Permission denied
whatever permissions are set when trying to change the value.
Thanks for all the updates. I find it somewhat surprising that Rockchip asserts that this kernel config is required for Android; I'm moderately confident it isn't.
My broader concern is what other poor security choices did they make in their kernel config that don't trigger stern warnings.
@MichaIng do you have any idea when we'll see mainline RK3588(S) support?
The commit may be even just pulled in from the Android branch, where, as the commit text states, it has no negative impact for end user systems since the debugfs cannot be mounted anyway, at least not without rooting the phone first, I guess.
So the central problem really is that Linux and Android branches have been merged into one.
My broader concern is what other poor security choices did they make in their kernel config that don't trigger stern warnings.
Dito, although I do not worry so much about security (I think it is rare that Android and mainline Linux diverge in this regards), but stability and performance. I can imagine that the Android kernel has optimisations and switches set to best serve the Android OS and the common setup of it on Android mobile phones. Even that SBCs use the same CPU architecture, I can imagine that on a regular Linux distro, those changes have a negative impact on kernel features, performance and stability.
However, all speculation so far. I am not even sure how the device clock rate can have a security impact. Probably has something to do with the way hardware random generators work to generate entropy used for cryptographic tasks 🤔. Or I'm on the wrong track 😄.
I hope Rockchip and FriendlyELEC answer soon to get some clarification and a fix for the writable clk_rate
at a minimum.
Rockchip answered that they are looking into splitting Linux and Android kernel trees with next release. But that means probably next Linux LTS which is not applied by vendors for their current SBCs. FriendlyELEC will most likely stay at Linux 5.10 for NanoPi 5 and 6 series, so they'd need to patch it their end.
Well, that doesn't sound great at all.
Did Rockchip give you any indication about whether they were putting the effort into mainline 3588(S) support? Seems to me that mainline would then be the sustainable path fwd vs relying on vendor-patched kernels.
Did Rockchip give you any indication about whether they were putting the effort into mainline 3588(S) support?
While I totally agree with you, I gave up hoping for this. To me it looks like Rockchip does not aim to support mainline kernel. They create an own branch, vendors use it, and mainline kernel support is done by volunteers or probably also paid kernel developers, but unrelated to Rockchip or any vendor.
For the good of all, the only correct thing would be to not have an own kernel repository at all, respectively only as feature branch, contributing and syncing everything with mainline kernel directly. Then we wouldn't need to wait for 2-3 years until we finally have an acceptable kernel and images for SBCs with new Rockchip SoCs. Same is true for most other vendors and chip manufacturers as well. I think Allwinner is the only one which seems to care a bit about mainline kernel support?
... same with the bootloader/U-Boot of course. This is all Rockchip or vendor branch first, often not working great (Quartz64 Rockchip U-Boot hat problems booting from several SD cards), mainline U-Boot needed a year longer or more.
Yeah, ideally no custom kernel repo or u-boot branches; I'd like to use this hardware for multiple purposes and with different OSes and u-boot is in a number of respects even more important.
Thanks for being so responsive and filling some gaps in my understanding.
Yeah, ideally no custom kernel repo or u-boot branches
No chance to achieve this with FriendlyELEC, but as soon as others implemented support into mainline kernel, we'll switch of course 🙂.
Good new, PR has been merged 🙂. There are new FriendlyELEC Debian images available as well, built today, but the OneDrive download links are down and I cannot manage to download something from Baidu without installing some downloader tool or what.
Thanks for the update.
They definitely changed the download links. The one that's working for me at the moment is https://1drv.ms/u/s!AkNn1aO7NlsfvljhexlJNkGU2VtO
Does the PR give you any indication whether they made any other kernel config changes that would be security-relevant?
Thanks, that works now. Wasn't it actually Google Drive before?
Kernel build is from January 13th, so we need to wait.
What is this?
Raspberry Pi bootloader files, even the RPi 4 and pre-4 variants, further split into regular, cut-down, extended and debug variants. This cannot work anywhere else than on Raspberry Pi, and of course those images use U-Boot, so why the hack are these files there?
Next to it:
Some GRUB files with a config pointing to Linux images which do not exist. Not sure what was experimented with, but that all this stuff is just left (alone with a large number of other useless files spread across the image) on the end user image is... well... good that we purge and re-create the whole rootfs from scratch 😄.
Yes, it was Google Drive before. No idea why they changed it to OneDrive.
I am increasingly concerned about Rockchip/FriendlyElec release engineering, and whether even taking their kernel directly is such a good idea 🫤
I am increasingly concerned about Rockchip/FriendlyElec release engineering
Note that this is common, I saw similar and worse with most other SBC manufacturers. Only Raspberry Pi as own real quality images, Hardkernel the second best, I'd say.
For R5S there is one alternative: https://github.com/pyavitz/binary/releases/tag/images For R6S sadly none I'm aware of.
Looks like RK3588/3588S support is coming in mainline 6.3: https://lore.kernel.org/lkml/4f42519a-d087-416a-b7d6-aa9f63d2c395@app.fastmail.com/
Hopefully NanoPi R6S support in particular as well (device tree at least). Same with U-Boot.
Anyone have a current link or mirror for the R5S downloads that works? OneDrive links are still down, and I'm not about to install the Baidu software for the Mainland China links.
The OneDrive files for R6S disappeared in the last 24 hours as well.
You are correct, seems they have fixed it for now. I did manage to find an HTTP server as well but it is very slow.
Not only affect NanoPi R5S/R6S, I have also found the same issue with my Rock Pi 5B.
Interesting. It is based on the same Rockchip kernel sources, but I'd have though that Armbian patched this out. Looks like we should open the same PR on Radxa's kernel branch, so Armbian and everyone else, using it, benefits as well.
According to GinKage (from Radxa' discord server), the flag is disabled via patch in BSP https://github.com/radxa-repo/bsp/blob/main/linux/rockchip/0100-vendor/0008-Revert-ANDROID-clk-Enable-writable-debugfs-files.patch
Which is good, but does not help other developers which do not know about these patches, like obviously Armbian. And they may even use a deprecated branch, if using 5.10.y-rock5
explicitly instead of the default.
Yes, I know and what is the way to move forward for DietPi to support Rock Pi 5b?
DietPi does support ROCK 5B? If you mean the issue with insufficient boot partition size, very different topic, so let's keep it over there.
Fixed with: https://github.com/MichaIng/DietPi/commit/738678c The kernel upgrade is enforced during next DietPi update, as this seems to be a sufficient serious reason. But it is a little risky, as the kernel itself on partition 5 needs to be upgraded as well, otherwise the new kernel modules cannot be loaded with the old kernel. All partitions from 1 to 7 are now re-flashed from a minimal FriendlyELEC base image, which includes SPL, U-Boot, kernel, device tree etc, so everything which is or may be relevant. If someone manually adjusted the U-Boot environment (I'm not even sure where it is located), that will be overwritten, but I think its better this way than skipping it and risking failing boot if the old env does not work with the new bootloader for some reason.
I tried to implement it as failsafe as possible, assuring that base image and modules did successfully download, extract and that the base image as well as the system have the expected 8th partition, before starting with modules package install and flashing the partitions over.
@skyuplam The issue is still present on ROCK 5 with latest Armbian kernel?
Otherwise we can add the patch from https://github.com/radxa-repo/bsp/blob/main/linux/rockchip/0100-vendor/0008-Revert-ANDROID-clk-Enable-writable-debugfs-files.patch to https://github.com/armbian/build/tree/main/patch/kernel/rockchip-rk3588-legacy
Nice side-effect of the R5S/R6S kernel upgrade: The console resolution does not fit the screen. On R6S I do not get 1080p console with 1080p screen resolution, on R5S even 1440p both. Not sure where the difference comes from, but it doesn't really matter for the text console.
@MichaIng, yes, the DebugFS is turned on with Armbian_23.02.2_Rock-5b_bullseye_legacy_5.10.110_minimal.img
@skyuplam Could you check some other things on ROCK 5B:
apt install rng-tools5
sleep 5
systemctl status rngd
This reports a running service? If so, this is to be preferred over haveged:
G_AGP haveged
And:
ls -l /dev/ttyS2
ls -l /dev/ttyFIQ0
The first does not exist, the second does. And in case you use a serial console, it is actually on /dev/ttyFIQ0.
Both was true on Orange Pi 5 with same SoC and same kernel, so I'm pretty sure both is true on ROCK 5B as well and regarding the serial console there is another bug in the Armbian boot configs, which try to use ttyS2.
Yes, the rngd is running
I cannot find /dev/ttyS2
but I can find /dev/ttyFIQ0
Good news, I just wanted to add the patch, but next kernel upgrade should have it fixed for Orange Pi 5 and ROCK 5B as well: https://github.com/armbian/linux-rockchip/pull/9
@skyuplam Thanks for verification, will be patched with next DietPi release.
I'll mark this as closed now.
Creating a bug report/issue
Required Information
bullseye
Linux r6s 5.10.110 #1 SMP Sat Dec 3 01:25:15 CST 2022 aarch64 GNU/Linux
NanoPi R6S (aarch64)
Anker 20W PD
PNY 64GB Elite-X
Additional Information (if applicable)
YES
Steps to reproduce
The R6S image appears to be using the FriendlyElec kernel
The kernel config is not secure
Expected behaviour
dmesg should not be reporting insecure kernel config
Actual behaviour
dmesg includes
Extra details
This configuration makes me unwilling to expose the system to a publicly routable network, especially since it suggests that there might also be other suboptimal configuration choices in effect.