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: <yq1y2vbhe6i.fsf@oracle.com>
Date:   Mon, 16 Dec 2019 21:35:33 -0500
From:   "Martin K. Petersen" <martin.petersen@...cle.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        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

Guenter,

> If and when drives are detected which report bad information, such
> drives can be added to a blacklist without impact on the core SCSI or
> ATA code. Until that happens, not loading the driver solves the
> problem on any affected system.

My only concern with that is that we'll have blacklisting several
places. We already have ATA and SCSI blacklists. If we now add a third
place, that's going to be a maintenance nightmare.

More on that below.

>> 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).

OK, so I spent my weekend tinkering with 15+ years of accumulated USB
devices. And my conclusion is that no, we can't in any sensible manner,
support USB storage monitoring in the kernel. There is no heuristic that
I can find that identifies that "this is a hard drive or an SSD and
attempting one of the various SMART methods may be safe". As opposed to
"this is a USB key that's likely to lock up if you try". And that's
ignoring the drives with USB-ATA bridges that I managed to wedge in my
attempt at sending down commands.

Even smartmontools is failing to work on a huge part of my vintage
collection.  Thanks to a wide variety of bridges with random, custom
interfaces.

So my stance on all this is that I'm fine with your general approach for
ATA. I will post a patch adding the required bits for SCSI. And if a
device does not implement either of the two standard methods, people
should use smartmontools.

Wrt. name, since I've added SCSI support, satatemp is a bit of a
misnomer. drivetemp, maybe? No particular preference.

> The one USB/UAS connected SATA drive I have (a WD passport) reports
> itself as "WD      ", not as "ATA     ". I would expect other drives
> to do the same.

Yes. Most vendors are too fond of their brand names to put "ATA" in
there. So my suggestion is to relax the heuristic to trigger on the ATA
Information VPD page only and ignore the name.

Also, there are some devices that will lock up the way you access that
VPD page. So a tweak is also required there.

To avoid the multiple blacklists and heuristic collections my suggestion
is that I introduce a helper function in SCSI (based on what I did in
the disk driver) that can be called to identify whether something is an
ATA device. And then the hwmon driver can call that and we can keep the
heuristics in one place.

If a device turns out to be problematic wrt. getting the ATA VPD for the
purpose of SMART, for instance, it will also need to be blacklisted for
other reasons in SCSI. So I would really like to keep the heuristics in
one place.

-- 
Martin K. Petersen	Oracle Linux Engineering