* boot failure with 4.13.0-rc6 due to ATA errors @ 2017-08-28 18:40 David Ahern 2017-08-28 19:59 ` Tejun Heo 0 siblings, 1 reply; 12+ messages in thread From: David Ahern @ 2017-08-28 18:40 UTC (permalink / raw) To: Tejun Heo, linux-ide; +Cc: LKML 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-28 18:40 boot failure with 4.13.0-rc6 due to ATA errors David Ahern @ 2017-08-28 19:59 ` Tejun Heo 2017-08-28 20:26 ` David Ahern 0 siblings, 1 reply; 12+ messages in thread From: Tejun Heo @ 2017-08-28 19:59 UTC (permalink / raw) To: David Ahern; +Cc: linux-ide, LKML, Christoph Hellwig (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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-28 19:59 ` Tejun Heo @ 2017-08-28 20:26 ` David Ahern 2017-08-28 21:22 ` Tejun Heo 0 siblings, 1 reply; 12+ messages in thread From: David Ahern @ 2017-08-28 20:26 UTC (permalink / raw) To: Tejun Heo; +Cc: linux-ide, LKML, Christoph Hellwig 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-28 20:26 ` David Ahern @ 2017-08-28 21:22 ` Tejun Heo 2017-08-29 12:42 ` Christoph Hellwig 0 siblings, 1 reply; 12+ messages in thread From: Tejun Heo @ 2017-08-28 21:22 UTC (permalink / raw) To: David Ahern; +Cc: linux-ide, LKML, Christoph Hellwig 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-28 21:22 ` Tejun Heo @ 2017-08-29 12:42 ` Christoph Hellwig 2017-08-29 14:27 ` Tejun Heo ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Christoph Hellwig @ 2017-08-29 12:42 UTC (permalink / raw) To: Tejun Heo; +Cc: David Ahern, linux-ide, LKML, Christoph Hellwig, Robert Elliott 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-29 12:42 ` Christoph Hellwig @ 2017-08-29 14:27 ` Tejun Heo 2017-08-29 15:08 ` David Ahern 2017-08-29 15:38 ` Tejun Heo 2 siblings, 0 replies; 12+ messages in thread From: Tejun Heo @ 2017-08-29 14:27 UTC (permalink / raw) To: Christoph Hellwig; +Cc: David Ahern, linux-ide, LKML, Robert Elliott 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-29 12:42 ` Christoph Hellwig 2017-08-29 14:27 ` Tejun Heo @ 2017-08-29 15:08 ` David Ahern 2017-08-29 15:30 ` Tejun Heo 2017-08-29 15:38 ` Tejun Heo 2 siblings, 1 reply; 12+ messages in thread From: David Ahern @ 2017-08-29 15:08 UTC (permalink / raw) To: Christoph Hellwig, Tejun Heo; +Cc: linux-ide, LKML, Robert Elliott 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-29 15:08 ` David Ahern @ 2017-08-29 15:30 ` Tejun Heo 2017-08-29 15:51 ` Henrique de Moraes Holschuh 0 siblings, 1 reply; 12+ messages in thread From: Tejun Heo @ 2017-08-29 15:30 UTC (permalink / raw) To: David Ahern; +Cc: Christoph Hellwig, linux-ide, LKML, Robert Elliott 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-29 15:30 ` Tejun Heo @ 2017-08-29 15:51 ` Henrique de Moraes Holschuh 2017-08-29 15:55 ` Tejun Heo 0 siblings, 1 reply; 12+ messages in thread From: Henrique de Moraes Holschuh @ 2017-08-29 15:51 UTC (permalink / raw) To: Tejun Heo; +Cc: David Ahern, Christoph Hellwig, linux-ide, LKML, Robert Elliott 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-29 15:51 ` Henrique de Moraes Holschuh @ 2017-08-29 15:55 ` Tejun Heo 2017-08-29 16:02 ` Henrique de Moraes Holschuh 0 siblings, 1 reply; 12+ messages in thread From: Tejun Heo @ 2017-08-29 15:55 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: David Ahern, Christoph Hellwig, linux-ide, LKML, Robert Elliott 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-29 15:55 ` Tejun Heo @ 2017-08-29 16:02 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 12+ messages in thread From: Henrique de Moraes Holschuh @ 2017-08-29 16:02 UTC (permalink / raw) To: Tejun Heo; +Cc: David Ahern, Christoph Hellwig, linux-ide, LKML, Robert Elliott 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: boot failure with 4.13.0-rc6 due to ATA errors 2017-08-29 12:42 ` Christoph Hellwig 2017-08-29 14:27 ` Tejun Heo 2017-08-29 15:08 ` David Ahern @ 2017-08-29 15:38 ` Tejun Heo 2 siblings, 0 replies; 12+ messages in thread From: Tejun Heo @ 2017-08-29 15:38 UTC (permalink / raw) To: Christoph Hellwig; +Cc: David Ahern, linux-ide, LKML, Robert Elliott 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-08-29 16:02 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-28 18:40 boot failure with 4.13.0-rc6 due to ATA errors David Ahern 2017-08-28 19:59 ` Tejun Heo 2017-08-28 20:26 ` David Ahern 2017-08-28 21:22 ` Tejun Heo 2017-08-29 12:42 ` Christoph Hellwig 2017-08-29 14:27 ` Tejun Heo 2017-08-29 15:08 ` David Ahern 2017-08-29 15:30 ` Tejun Heo 2017-08-29 15:51 ` Henrique de Moraes Holschuh 2017-08-29 15:55 ` Tejun Heo 2017-08-29 16:02 ` Henrique de Moraes Holschuh 2017-08-29 15:38 ` Tejun Heo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).