Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1721901 > unrolled thread

boot failure with 4.13.0-rc6 due to ATA errors

Back to article view | Back to linux.kernel

Contents

  boot failure with 4.13.0-rc6 due to ATA errors David Ahern <dsahern@gmail.com> - 2017-08-28 20:50 +0200
    Re: boot failure with 4.13.0-rc6 due to ATA errors Tejun Heo <tj@kernel.org> - 2017-08-28 22:00 +0200
      Re: boot failure with 4.13.0-rc6 due to ATA errors David Ahern <dsahern@gmail.com> - 2017-08-28 22:30 +0200
        Re: boot failure with 4.13.0-rc6 due to ATA errors Tejun Heo <tj@kernel.org> - 2017-08-28 23:30 +0200
          Re: boot failure with 4.13.0-rc6 due to ATA errors Christoph Hellwig <hch@lst.de> - 2017-08-29 14:50 +0200
            Re: boot failure with 4.13.0-rc6 due to ATA errors Tejun Heo <tj@kernel.org> - 2017-08-29 16:30 +0200
            Re: boot failure with 4.13.0-rc6 due to ATA errors David Ahern <dsahern@gmail.com> - 2017-08-29 17:10 +0200
              Re: boot failure with 4.13.0-rc6 due to ATA errors Tejun Heo <tj@kernel.org> - 2017-08-29 17:40 +0200
                Re: boot failure with 4.13.0-rc6 due to ATA errors Tejun Heo <tj@kernel.org> - 2017-08-29 18:00 +0200
                  Re: boot failure with 4.13.0-rc6 due to ATA errors Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2017-08-29 18:10 +0200
                Re: boot failure with 4.13.0-rc6 due to ATA errors Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2017-08-29 18:00 +0200
            Re: boot failure with 4.13.0-rc6 due to ATA errors Tejun Heo <tj@kernel.org> - 2017-08-29 17:40 +0200

#1721901 — boot failure with 4.13.0-rc6 due to ATA errors

Not sure why mailing list to direct this bug report to, so starting with
libata based on the error messages.

Some where between v4.12 and 4.13.0-rc6 a Celestica redstone switch
fails to boot due to ATA errors:

[    9.185203] ata1.00: failed to set xfermode (err_mask=0x40)
[    9.500825] ata1.00: revalidation failed (errno=-5)
[   20.449205] ata1.00: failed to set xfermode (err_mask=0x40)

I just tried Linus' top of tree (cc4a41fe5541) and it still fails. With
v4.12 the same switch boots and 'dmesg | grep ata' shows:

[    0.129080] libata version 3.00 loaded.
[    1.016520] ata1: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce100 irq 27
[    1.016524] ata2: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce180 irq 27
[    1.016528] ata3: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce200 irq 27
[    1.016531] ata4: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce280 irq 27
[    1.028623] ata5: SATA max UDMA/133 abar m2048@0xdffcd000 port
0xdffcd100 irq 28
[    1.028627] ata6: SATA max UDMA/133 abar m2048@0xdffcd000 port
0xdffcd180 irq 28
[    1.326767] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.328646] ata2: SATA link down (SStatus 0 SControl 300)
[    1.330519] ata4: SATA link down (SStatus 0 SControl 300)
[    1.330554] ata3: SATA link down (SStatus 0 SControl 300)
[    1.330575] ata1.00: ATA-9: InnoDisk Corp. - mSATA 3ME, S130604, max
UDMA/133
[    1.330581] ata1.00: 31277232 sectors, multi 16: LBA48 NCQ (depth
31/32), AA
[    1.332433] ata1.00: failed to get Identify Device Data, Emask 0x1
[    1.332709] ata1.00: failed to get Identify Device Data, Emask 0x1
[    1.332717] ata1.00: configured for UDMA/133
[    1.335813] ata6: SATA link down (SStatus 0 SControl 300)
[    1.339829] ata5: SATA link down (SStatus 0 SControl 300)

Given the overhead of building, installing, booting and recovering from
a failed boot, 'git bisect' is not a realistic option for this switch
option unless some one can cut the span to a few iterations.

If it helps, lspci and lsscsi output from an older kernel:

# lspci
00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC
Transaction Router (rev 02)
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 1 (rev 02)
00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 2 (rev 02)
00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 3 (rev 02)
00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus
2.0 (rev 02)
00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354
(rev 03)
00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354
(rev 03)
00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354
(rev 03)
00:16.0 USB controller: Intel Corporation Atom processor C2000 USB
Enhanced Host Controller (rev 02)
00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA2 Controller (rev 02)
00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA3 Controller (rev 02)
00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
01:00.0 Ethernet controller: Broadcom Corporation Device b854 (rev 03)


# lsscsi
[0:0:0:0]    disk    ATA      InnoDisk Corp. - 604   /dev/sda

[toc] | [next] | [standalone]

#1721937

(cc'ing Christoph)

On Mon, Aug 28, 2017 at 12:40:39PM -0600, David Ahern wrote:
> Not sure why mailing list to direct this bug report to, so starting with
> libata based on the error messages.
> 
> Some where between v4.12 and 4.13.0-rc6 a Celestica redstone switch
> fails to boot due to ATA errors:
> 
> [    9.185203] ata1.00: failed to set xfermode (err_mask=0x40)
> [    9.500825] ata1.00: revalidation failed (errno=-5)
> [   20.449205] ata1.00: failed to set xfermode (err_mask=0x40)
> 
> I just tried Linus' top of tree (cc4a41fe5541) and it still fails. With
> v4.12 the same switch boots and 'dmesg | grep ata' shows:
> 
> [    0.129080] libata version 3.00 loaded.
> [    1.016520] ata1: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce100 irq 27
> [    1.016524] ata2: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce180 irq 27
> [    1.016528] ata3: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce200 irq 27
> [    1.016531] ata4: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce280 irq 27
> [    1.028623] ata5: SATA max UDMA/133 abar m2048@0xdffcd000 port
> 0xdffcd100 irq 28
> [    1.028627] ata6: SATA max UDMA/133 abar m2048@0xdffcd000 port
> 0xdffcd180 irq 28
> [    1.326767] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [    1.328646] ata2: SATA link down (SStatus 0 SControl 300)
> [    1.330519] ata4: SATA link down (SStatus 0 SControl 300)
> [    1.330554] ata3: SATA link down (SStatus 0 SControl 300)
> [    1.330575] ata1.00: ATA-9: InnoDisk Corp. - mSATA 3ME, S130604, max
> UDMA/133
> [    1.330581] ata1.00: 31277232 sectors, multi 16: LBA48 NCQ (depth
> 31/32), AA
> [    1.332433] ata1.00: failed to get Identify Device Data, Emask 0x1
> [    1.332709] ata1.00: failed to get Identify Device Data, Emask 0x1
> [    1.332717] ata1.00: configured for UDMA/133
> [    1.335813] ata6: SATA link down (SStatus 0 SControl 300)
> [    1.339829] ata5: SATA link down (SStatus 0 SControl 300)
> 
> Given the overhead of building, installing, booting and recovering from
> a failed boot, 'git bisect' is not a realistic option for this switch
> option unless some one can cut the span to a few iterations.
> 
> If it helps, lspci and lsscsi output from an older kernel:
> 
> # lspci
> 00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC
> Transaction Router (rev 02)
> 00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
> Port 1 (rev 02)
> 00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
> Port 2 (rev 02)
> 00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
> Port 3 (rev 02)
> 00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
> 00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
> 00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus
> 2.0 (rev 02)
> 00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354
> (rev 03)
> 00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354
> (rev 03)
> 00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354
> (rev 03)
> 00:16.0 USB controller: Intel Corporation Atom processor C2000 USB
> Enhanced Host Controller (rev 02)
> 00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
> SATA2 Controller (rev 02)
> 00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
> SATA3 Controller (rev 02)
> 00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
> 00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
> 01:00.0 Ethernet controller: Broadcom Corporation Device b854 (rev 03)
> 
> 
> # lsscsi
> [0:0:0:0]    disk    ATA      InnoDisk Corp. - 604   /dev/sda

Can you please verify whether 818831c8b22f ("libata: implement
SECURITY PROTOCOL IN/OUT") is the culprit?  ie. try to boot the commit
to verify that the problem is there, and try the one prior?

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1721951

On 8/28/17 1:59 PM, Tejun Heo wrote:
> Can you please verify whether 818831c8b22f ("libata: implement
> SECURITY PROTOCOL IN/OUT") is the culprit?  ie. try to boot the commit
> to verify that the problem is there, and try the one prior?

That commit is the problem. a0fd2454a36ffab2ce39b3a91c1385a5f98e63f0
works fine.

[toc] | [prev] | [next] | [standalone]

#1721979

Hello,

On Mon, Aug 28, 2017 at 02:26:52PM -0600, David Ahern wrote:
> On 8/28/17 1:59 PM, Tejun Heo wrote:
> > Can you please verify whether 818831c8b22f ("libata: implement
> > SECURITY PROTOCOL IN/OUT") is the culprit?  ie. try to boot the commit
> > to verify that the problem is there, and try the one prior?
> 
> That commit is the problem. a0fd2454a36ffab2ce39b3a91c1385a5f98e63f0
> works fine.

Christoph, is there anything we can do to further gate issuing of the
offending command?  Otherwise, we might have to go for whitelist
instead.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1722442

On Mon, Aug 28, 2017 at 02:22:25PM -0700, Tejun Heo wrote:
> Hello,
> 
> On Mon, Aug 28, 2017 at 02:26:52PM -0600, David Ahern wrote:
> > On 8/28/17 1:59 PM, Tejun Heo wrote:
> > > Can you please verify whether 818831c8b22f ("libata: implement
> > > SECURITY PROTOCOL IN/OUT") is the culprit?  ie. try to boot the commit
> > > to verify that the problem is there, and try the one prior?
> > 
> > That commit is the problem. a0fd2454a36ffab2ce39b3a91c1385a5f98e63f0
> > works fine.
> 
> Christoph, is there anything we can do to further gate issuing of the
> offending command?  Otherwise, we might have to go for whitelist
> instead.

We could try to check the IDENTIFY DEVICE word, but given that it has
a dual meaning in older spec versions I don't really like the idea
either.  Untested patch below as I'm not near my OPAL capable drive.

Also most recent ATA features seem to be keyed off a log page of some
sort, so we'll run into more problems like this.

---
From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Tue, 29 Aug 2017 14:35:50 +0200
Subject: libata: check for trusted computing in IDENTIFY DEVICE data

ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
the IDENTIFY DEVICE data.  Check this before issuing a READ LOG PAGE
command to avoid issues with buggy devices.  The only downside is that
we can't support Security Send / Receive for a device with an older
revision due to the conflicting use of this field in earlier
specifications.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/ata/libata-core.c |  3 +++
 include/linux/ata.h       | 10 +++++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 697f5f896b19..ca57b03ab950 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -2413,6 +2413,9 @@ static void ata_dev_config_trusted(struct ata_device *dev)
 	u64 trusted_cap;
 	unsigned int err;
 
+	if (!ata_id_has_trusted(dev->id))
+		return;
+
 	if (!ata_identify_page_supported(dev, ATA_LOG_SECURITY)) {
 		ata_dev_warn(dev,
 			     "Security Log not supported\n");
diff --git a/include/linux/ata.h b/include/linux/ata.h
index e65ae4b2ed48..c7a353825450 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -60,7 +60,8 @@ enum {
 	ATA_ID_FW_REV		= 23,
 	ATA_ID_PROD		= 27,
 	ATA_ID_MAX_MULTSECT	= 47,
-	ATA_ID_DWORD_IO		= 48,
+	ATA_ID_DWORD_IO		= 48,	/* before ATA-8 */
+	ATA_ID_TRUSTED		= 48,	/* ATA-8 and later */
 	ATA_ID_CAPABILITY	= 49,
 	ATA_ID_OLD_PIO_MODES	= 51,
 	ATA_ID_OLD_DMA_MODES	= 52,
@@ -889,6 +890,13 @@ static inline bool ata_id_has_dword_io(const u16 *id)
 	return id[ATA_ID_DWORD_IO] & (1 << 0);
 }
 
+static inline bool ata_id_has_trusted(const u16 *id)
+{
+	if (ata_id_major_version(id) <= 7)
+		return false;
+	return id[ATA_ID_TRUSTED] & (1 << 0);
+}
+
 static inline bool ata_id_has_unload(const u16 *id)
 {
 	if (ata_id_major_version(id) >= 7 &&
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]

#1722538

Hello,

On Tue, Aug 29, 2017 at 02:42:06PM +0200, Christoph Hellwig wrote:
> We could try to check the IDENTIFY DEVICE word, but given that it has
> a dual meaning in older spec versions I don't really like the idea
> either.  Untested patch below as I'm not near my OPAL capable drive.

I see.

> Also most recent ATA features seem to be keyed off a log page of some
> sort, so we'll run into more problems like this.

:(

> From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Tue, 29 Aug 2017 14:35:50 +0200
> Subject: libata: check for trusted computing in IDENTIFY DEVICE data
> 
> ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> the IDENTIFY DEVICE data.  Check this before issuing a READ LOG PAGE
> command to avoid issues with buggy devices.  The only downside is that
> we can't support Security Send / Receive for a device with an older
> revision due to the conflicting use of this field in earlier
> specifications.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

David, can you please see whether this patch resolves your issue?

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1722557

On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> ---
> From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Tue, 29 Aug 2017 14:35:50 +0200
> Subject: libata: check for trusted computing in IDENTIFY DEVICE data
> 
> ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> the IDENTIFY DEVICE data.  Check this before issuing a READ LOG PAGE
> command to avoid issues with buggy devices.  The only downside is that
> we can't support Security Send / Receive for a device with an older
> revision due to the conflicting use of this field in earlier
> specifications.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/ata/libata-core.c |  3 +++
>  include/linux/ata.h       | 10 +++++++++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 697f5f896b19..ca57b03ab950 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -2413,6 +2413,9 @@ static void ata_dev_config_trusted(struct ata_device *dev)
>  	u64 trusted_cap;
>  	unsigned int err;
>  
> +	if (!ata_id_has_trusted(dev->id))
> +		return;
> +
>  	if (!ata_identify_page_supported(dev, ATA_LOG_SECURITY)) {
>  		ata_dev_warn(dev,
>  			     "Security Log not supported\n");
> diff --git a/include/linux/ata.h b/include/linux/ata.h
> index e65ae4b2ed48..c7a353825450 100644
> --- a/include/linux/ata.h
> +++ b/include/linux/ata.h
> @@ -60,7 +60,8 @@ enum {
>  	ATA_ID_FW_REV		= 23,
>  	ATA_ID_PROD		= 27,
>  	ATA_ID_MAX_MULTSECT	= 47,
> -	ATA_ID_DWORD_IO		= 48,
> +	ATA_ID_DWORD_IO		= 48,	/* before ATA-8 */
> +	ATA_ID_TRUSTED		= 48,	/* ATA-8 and later */
>  	ATA_ID_CAPABILITY	= 49,
>  	ATA_ID_OLD_PIO_MODES	= 51,
>  	ATA_ID_OLD_DMA_MODES	= 52,
> @@ -889,6 +890,13 @@ static inline bool ata_id_has_dword_io(const u16 *id)
>  	return id[ATA_ID_DWORD_IO] & (1 << 0);
>  }
>  
> +static inline bool ata_id_has_trusted(const u16 *id)
> +{
> +	if (ata_id_major_version(id) <= 7)
> +		return false;
> +	return id[ATA_ID_TRUSTED] & (1 << 0);
> +}
> +
>  static inline bool ata_id_has_unload(const u16 *id)
>  {
>  	if (ata_id_major_version(id) >= 7 &&
> 

That works for me.

Tested-by: David Ahern <dsahern@gmail.com>

[toc] | [prev] | [next] | [standalone]

#1722571

On Tue, Aug 29, 2017 at 09:08:05AM -0600, David Ahern wrote:
> On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> > ---
> > From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> > From: Christoph Hellwig <hch@lst.de>
> > Date: Tue, 29 Aug 2017 14:35:50 +0200
> > Subject: libata: check for trusted computing in IDENTIFY DEVICE data
> > 
> > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> > the IDENTIFY DEVICE data.  Check this before issuing a READ LOG PAGE
> > command to avoid issues with buggy devices.  The only downside is that
> > we can't support Security Send / Receive for a device with an older
> > revision due to the conflicting use of this field in earlier
> > specifications.

Christoph, I'm gonna revert the horkage patch and apply this one.  If
you can think of a better way to do this, please let me know.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1722578

Hello, Henrique.

On Tue, Aug 29, 2017 at 12:51:02PM -0300, Henrique de Moraes Holschuh wrote:
> > > > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> > > > the IDENTIFY DEVICE data.  Check this before issuing a READ LOG PAGE
> > > > command to avoid issues with buggy devices.  The only downside is that
> > > > we can't support Security Send / Receive for a device with an older
> > > > revision due to the conflicting use of this field in earlier
> > > > specifications.
> > 
> > Christoph, I'm gonna revert the horkage patch and apply this one.  If
> > you can think of a better way to do this, please let me know.
> 
> The one thing that comes to mind would be an additional patch to allow
> people with ATA-7 to bypass the identify device data, and rely just on
> the read log page check, based on a kernel command line parameter.
> 
> If we get enough sucessful reports to make it worth it, an whitelist
> could be added...

If the ones we miss are the ones based on old revisions, does it
matter?  If we have to, we can just whitelist those devices and I
don't expect there to be many.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1722591

On Tue, 29 Aug 2017, Tejun Heo wrote:
> On Tue, Aug 29, 2017 at 12:51:02PM -0300, Henrique de Moraes Holschuh wrote:
> > > > > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> > > > > the IDENTIFY DEVICE data.  Check this before issuing a READ LOG PAGE
> > > > > command to avoid issues with buggy devices.  The only downside is that
> > > > > we can't support Security Send / Receive for a device with an older
> > > > > revision due to the conflicting use of this field in earlier
> > > > > specifications.
> > > 
> > > Christoph, I'm gonna revert the horkage patch and apply this one.  If
> > > you can think of a better way to do this, please let me know.
> > 
> > The one thing that comes to mind would be an additional patch to allow
> > people with ATA-7 to bypass the identify device data, and rely just on
> > the read log page check, based on a kernel command line parameter.
> > 
> > If we get enough sucessful reports to make it worth it, an whitelist
> > could be added...
> 
> If the ones we miss are the ones based on old revisions, does it
> matter?  If we have to, we can just whitelist those devices and I

Well, only if the opal functionality would actually be worth something
on those old revisions I guess.  It is certainly possible that it would
be better off disabled.

> don't expect there to be many.

Indeed, but we will not get much on the way of people testing this if we
don't give them a kernel parameter ;-)

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#1722580

On Tue, 29 Aug 2017, Tejun Heo wrote:
> On Tue, Aug 29, 2017 at 09:08:05AM -0600, David Ahern wrote:
> > On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> > > ---
> > > From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> > > From: Christoph Hellwig <hch@lst.de>
> > > Date: Tue, 29 Aug 2017 14:35:50 +0200
> > > Subject: libata: check for trusted computing in IDENTIFY DEVICE data
> > > 
> > > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> > > the IDENTIFY DEVICE data.  Check this before issuing a READ LOG PAGE
> > > command to avoid issues with buggy devices.  The only downside is that
> > > we can't support Security Send / Receive for a device with an older
> > > revision due to the conflicting use of this field in earlier
> > > specifications.
> 
> Christoph, I'm gonna revert the horkage patch and apply this one.  If
> you can think of a better way to do this, please let me know.

The one thing that comes to mind would be an additional patch to allow
people with ATA-7 to bypass the identify device data, and rely just on
the read log page check, based on a kernel command line parameter.

If we get enough sucessful reports to make it worth it, an whitelist
could be added...

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#1722564

On Tue, Aug 29, 2017 at 02:42:06PM +0200, Christoph Hellwig wrote:
> From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Tue, 29 Aug 2017 14:35:50 +0200
> Subject: libata: check for trusted computing in IDENTIFY DEVICE data
> 
> ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> the IDENTIFY DEVICE data.  Check this before issuing a READ LOG PAGE
> command to avoid issues with buggy devices.  The only downside is that
> we can't support Security Send / Receive for a device with an older
> revision due to the conflicting use of this field in earlier
> specifications.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Applied to libata/for-4.13-fixes.

Thanks.

-- 
tejun

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web