Hi, Il 15/11/19 12:29, Pali Rohár ha scritto: > No. I have not tested that my patch on other models. You can look at > that my patch link, some people already reported that on some models it > does not work... Yes, I saw that. But they are also using other laptops, which could be excluded by the whitelist until we have a working command for them. > What is incompatible with Secure Boot? sys_iopl nor sys_ioperm has > nothing to do with UEFI Secure Boot. They are just ordinary syscalls > like any other and are executed on kernel side. And IIRC it is up to the > kernel how it set privileges for I/O ports. Maybe bootloaders under > Secure Boot can set some other default values, but kernel can overwrite > them. I really do not see reason why it could be incompatible with UEFI > Secure Boot nor why it should not work. It just looks like improper > setup from userspace. Ah, my fault here: there is a patch to lock down the kernel when it is started with Secure Boot[1], and I believed that was already in mainline, but apparently it is not. [1] https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit?id=160a99536afc317b337212dd40eaba341702343e > It makes sense to have implemented in kernel switching between automatic > and manual mode as kernel has API for it. But it depends on the fact > that we know which SMM API to call. And currently it is just some random > call which we somehow observed that is working on 2 machines and on some > more other does not. Until we have fully working implementation we > cannot put it into kernel. Mmh, but then what is a plausible way forward to have this? Can't we start populating a whitelist for the machines we already have a solution for, and add more entries when they are discovered? This would already give a benefit to the users of supported laptops, without impacting users of unsupported laptops. My feeling is that if we pretend to have information for all possible models supported by dell-smm-hwmon, we will never benefit any user. Or can you suggest a plan? > What does not make sense for me is to have that "protection" in kernel. I am not really sure which "protection" you mean. I didn't mean to introduce any protection from userspace in my patch, I just wanted to make SET_FAN working. I think that the kernel module cannot (and should not) reliably protect itself from userspace sending random IO port reads/writes. Thanks, Giovanni. -- Giovanni Mascellani <g.mascellani@xxxxxxxxx> Postdoc researcher - Université Libre de Bruxelles
Attachment:
signature.asc
Description: OpenPGP digital signature
