Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752572AbdH2PvM (ORCPT ); Tue, 29 Aug 2017 11:51:12 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:50017 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751670AbdH2PvK (ORCPT ); Tue, 29 Aug 2017 11:51:10 -0400 X-ME-Sender: X-Sasl-enc: YgUv3mKgk8ZyrNDKrXQyRBE/rUDAquYMI2NkBWqpvHrE 1504021869 Date: Tue, 29 Aug 2017 12:51:02 -0300 From: Henrique de Moraes Holschuh To: Tejun Heo Cc: David Ahern , Christoph Hellwig , linux-ide@vger.kernel.org, LKML , Robert Elliott Subject: Re: boot failure with 4.13.0-rc6 due to ATA errors Message-ID: <20170829155102.vgbzyh7fhjrurdhl@khazad-dum.debian.net> References: <3117ae58-d432-101e-3f0b-68d72fdee28b@gmail.com> <20170828195916.GA491396@devbig577.frc2.facebook.com> <37033f6d-2ad0-7817-10b5-cbd7ff565624@gmail.com> <20170828212225.GB491396@devbig577.frc2.facebook.com> <20170829124206.GA26738@lst.de> <20170829153037.GN491396@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170829153037.GN491396@devbig577.frc2.facebook.com> X-GPG-Fingerprint1: 4096R/0x0BD9E81139CB4807: C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1263 Lines: 28 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 > > > 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