mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Giovanni Mascellani <gio@debian.org>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Jean Delvare <jdelvare@suse.com>,
	linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hwmon: (dell-smm-hwmon) Disable BIOS fan control on SET_FAN
Date: Fri, 15 Nov 2019 14:44:59 +0100	[thread overview]
Message-ID: <97d17b37-0267-ae32-803c-ce8f7a871ab4@debian.org> (raw)
In-Reply-To: <20191115112902.yfaoqttsafmilijh@pali>


[-- Attachment #1.1: Type: text/plain, Size: 2592 bytes --]

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@gmail.com>
Postdoc researcher - Université Libre de Bruxelles


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2019-11-15 13:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-14 21:14 Giovanni Mascellani
2019-11-14 21:39 ` Guenter Roeck
2019-11-14 21:51   ` Pali Rohár
2019-11-15  9:51     ` Giovanni Mascellani
2019-11-15 11:29       ` Pali Rohár
2019-11-15 13:44         ` Giovanni Mascellani [this message]
2019-11-15 14:36           ` Pali Rohár
2019-11-15 14:46             ` Guenter Roeck
2019-11-15 19:10               ` Giovanni Mascellani
2019-11-15  7:12 ` kbuild test robot
2019-11-15  8:19 ` kbuild test robot
2019-11-16 15:03 ` Pali Rohár
2019-11-16 17:14   ` Giovanni Mascellani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=97d17b37-0267-ae32-803c-ce8f7a871ab4@debian.org \
    --to=gio@debian.org \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=pali.rohar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®