linux-kernel - Re: [PATCH 0/1] Summary: hwmon driver for temperature sensors on SATA drives

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <yq15zinmrmj.fsf@oracle.com>
Date:   Tue, 10 Dec 2019 23:08:04 -0500
From:   "Martin K. Petersen" <martin.petersen@...cle.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     linux-hwmon@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [PATCH 0/1] Summary: hwmon driver for temperature sensors on SATA drives

Hi Guenter,

> The most recent attempt was [1] by Linus Walleij. It went through a total
> of seven iterations. At the end, it was rejected for a number of reasons;
> see the provided link for details. This implementation resides in the
> SCSI core. It originally resided in libata but was moved to SCSI per
> maintainer request, where it was ultimately rejected.

While I am sure I come across as a curmudgeon, regressions is a major
concern for me. That, and making sure we pick the right architecture. I
thought we were making good progress in that department when Linus
abandoned the effort.

> The feedback on this approach suggests to use the SCSI Temperature log
> page [0x0d] as means to access drive temperature information. It is
> unknown if this is implemented in any real SCSI drive.

Almost every SCSI drive has it.

> The feedback also suggests to obtain temperature from ATA drives,
> convert it into the SCSI temperature log page in libata-scsi, and to
> use that information in a hardware monitoring driver. The format and
> method to do this is documented in [3]. This is not currently
> implemented in the Linux kernel.

Correct, but I have no qualms over exporting the SCSI temperature log
page. The devices that export that page are generally well-behaved.

My concerns are wrt. identifying whether SMART data is available for
USB/UAS. I am not too worried about ATA and "real" SCSI (ignoring RAID
controllers that hide the real drives in various ways).

I am not sure why the SCSI temperature log page parsing would be
complex. I will have to go check smartmontools to see what that is all
about. The spec is as simple as can be.

Anyway. I think the overall approach wrt. SCT and falling back to
well-known SMART fields is reasonably sane and fine for libata. But I
don't understand the pushback wrt. using the SCSI temperature log page
as a conduit. I think it would be fine if this worked out of the box for
both SCSI and ATA drives.

The elephant in the room remains USB. And coming up with a way we can
reliably detect whether it is safe to start poking at the device to
discover if SMART is provided. If we eventually want to pursue USB, I
think your heuristic stuff needs to be a library that can be leveraged
by both libata and USB. But that doesn't have to be part of the initial
effort.

And finally, my concerns wrt. reacting to bad sensors remain. Not too
familiar with hwmon, but I would still like any actions based on
reported temperatures to be under user control and not the kernel.

-- 
Martin K. Petersen	Oracle Linux Engineering