记一次有趣的hwclock写RTC的PermissionDenied错误
技术分享
2年前 (2023-11-20)
0
999+
PS:要转载请注明出处,本人版权所有。
PS: 这个只是基于《我自己》的理解,
如果和你的原则及想法相冲突,请谅解,勿喷。
环境说明
无
前言
稍微接触过嵌入式板卡的,基本都知道嵌入式板卡里面有个功能叫做RTC。在Linux里面,有几个概念比较重要,它们分别是系统时间和硬件时钟。对于系统时间的话,大家都了解的比较多,我们在各种界面上看到的时间都是系统时间,我们在CLI里面,用date命令操作的时间就是系统时间,我们的系统时间可以通过网络同步或者说RTC同步。
此外,还有一个硬件时钟功能,这个功能就是RealTimeClock,它主要是用纽扣电池来维护一个硬件时钟,主要是用来同步时钟用的。例如,我们的设备怎么在没有网络的情况下,每次上电开机都能够得到真实时间,就需要靠RTC功能。对于RTC来说,在Linux里面,我们一般使用hwclock命令来对他做相关的操作,例如设置硬件时钟,例如从硬件时钟中得到真实时间,并设置到系统时钟等等。
一个奇怪的错误
上面我们提到了hwclock,最近,我们常用的一个板卡,其是Android系统,我们在交付给客户的时候,发现了一个奇怪的问题,我们执行hwclock失败了,而且错误还是Permission Deniend,熟悉linux的朋友可能都经常看到这个错误,它就是权限错误。下面是我们执行此命令的环境和错误:
有人立马就会想到是不是我们没有用root用户来执行的原因,从上图可知,并不是这样的,这个错误远远没有想象的那么简单,但是也没有那么复杂。
深入分析相关源码
首先,在Android里面,hwclock是来至于一个叫做toybox的库,大概在external/toybox/toys/other/hwclock.c,其中关于设置硬件时钟时的核心代码段如下:
if (toys.optflags & FLAG_w) { /* The value of tm_isdst is positive if daylight saving time is in effect, * zero if it is not and negative if the information is not available. * todo: so why isn't this negative...? */ tm.tm_isdst = 0; xioctl(fd, RTC_SET_TIME, &tm); }
看到这里,我们明白,必须要到内核源码才能够得到我们想要的答案。
通过RTC_SET_TIME,在内核代码的drivers/rtc/rtc-dev.c里面,我们找到了第一处可能导致出现Permission Deniend的地方,代码如下:
static long rtc_dev_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { int err = 0; struct rtc_device *rtc = file->private_data; const struct rtc_class_ops *ops = rtc->ops; struct rtc_time tm; struct rtc_wkalrm alarm; void __user *uarg = (void __user *) arg; err = mutex_lock_interruptible(&rtc->ops_lock); if (err) return err; /* check that the calling task has appropriate permissions * for certain ioctls. doing this check here is useful * to avoid duplicate code in each driver. */ switch (cmd) { case RTC_EPOCH_SET: case RTC_SET_TIME: if (!capable(CAP_SYS_TIME)) err = -EACCES; break; case RTC_IRQP_SET: if (arg > rtc->max_user_freq && !capable(CAP_SYS_RESOURCE)) err = -EACCES; break; case RTC_PIE_ON: if (rtc->irq_freq > rtc->max_user_freq && !capable(CAP_SYS_RESOURCE)) err = -EACCES; break; } //...... }
这里产生权限拒绝的原因是由于Linux Capability,因此我们首要的是检查我们的hwclock有没有CAP_SYS_TIME能力,我们通过prctl + PR_CAPBSET_READ 来获取hwclock有没有这个能力(当然,这里可以有很多的其他方式来确定,我这里用最简单的方法来确定),在hwclock源码中添加如下代码段:
int ret = prctl(PR_CAPBSET_READ, CAP_SYS_TIME); if (ret < 0) perror("sky: prctl PR_CAPBSET_READ"); printf("has CAP_SYS_TIME %dn", ret);
运行结果如下图:
从这里我们可以知道,我们的hwclock程序是具备CAP_SYS_TIME的,因此,报权限拒绝的地方并不在这里。
我们接着通过RTC_SET_TIME,在内核代码的drivers/rtc/rtc-dev.c里面,有如下片段:
static long rtc_dev_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { // ... ... case RTC_SET_TIME: mutex_unlock(&rtc->ops_lock); if (copy_from_user(&tm, uarg, sizeof(tm))) return -EFAULT; return rtc_set_time(rtc, &tm); // ... ... }
我们从这里可以看到,通过RTC_SET_TIME,我们执行rtc_set_time此方法,然后得到了返回值,我们有理由怀疑,我们得到的权限拒绝,来自于这个地方。
在内核代码的drivers/rtc/interface.c里面,有rtc_set_time的定义,函数定义如下:
int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm) { int err; err = rtc_valid_tm(tm); if (err != 0) return err; err = rtc_valid_range(rtc, tm); if (err) return err; rtc_subtract_offset(rtc, tm); err = mutex_lock_interruptible(&rtc->ops_lock); if (err) return err; if (!rtc->ops) err = -ENODEV; else if (rtc->ops->set_time) err = rtc->ops->set_time(rtc->dev.parent, tm); else if (rtc->ops->set_mmss64) { time64_t secs64 = rtc_tm_to_time64(tm); err = rtc->ops->set_mmss64(rtc->dev.parent, secs64); } else if (rtc->ops->set_mmss) { time64_t secs64 = rtc_tm_to_time64(tm); err = rtc->ops->set_mmss(rtc->dev.parent, secs64); } else err = -EINVAL; pm_stay_awake(rtc->dev.parent); mutex_unlock(&rtc->ops_lock); /* A timer might have just expired */ schedule_work(&rtc->irqwork); trace_rtc_set_time(rtc_tm_to_time64(tm), err); return err; } EXPORT_SYMBOL_GPL(rtc_set_time);
从这段代码可知,真正的错误还是来自于rtc 具体驱动里面的xxx_set_time 函数里面。在Linux内核里面,有许多的RTC驱动,因此,我们需要了解到我们的当前的RTC硬件是什么,我们通过logcat -b kernel |grep rtc命令得到了如下的信息:
因此,我们当前的rtc驱动就是rtc-pm8xxx,我们去查找相关的驱动源码drivers/rtc/rtc-pm8xxx.c,发现了一点端倪,其set_time源码重点片段如下:
从这里,我们可以知道,这个驱动有一个allow_set_time的参数,如果不允许,就会返回权限拒绝,那到底可不可以呢?我们尝试将这个属性设置一下,或者直接修改当前的源码。我们全局查找一下这个属性,发现其来自于这里:
然后我们通过重新编译android源码,重新生成dtbo.img镜像,然后刷入我们的系统,然后我们惊奇的发现,我们解决了这个奇怪的permission denied问题。
虽然,我们解决了permission denied问题,但是后续还是出现了rtc无法正常设置的问题,通过内核日志查看,是pm8150驱动出了问题,最后只能交给上游板卡厂家去适配解决。