From: "Philip R. Auld" <pauld@egenera.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Alan Stern <stern@rowland.harvard.edu>,
James Bottomley <James.Bottomley@SteelEye.com>,
SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] SCSI: sanitize INQUIRY strings
Date: Mon, 21 Aug 2006 14:51:52 -0400 [thread overview]
Message-ID: <20060821185152.GF29299@vienna.egenera.com> (raw)
In-Reply-To: <20060821182745.GB24068@parisc-linux.org>
Rumor has it that on Mon, Aug 21, 2006 at 12:27:45PM -0600 Matthew Wilcox said:
> On Mon, Aug 21, 2006 at 02:11:32PM -0400, Philip R. Auld wrote:
> > As far as I can tell Alan is not trying to "ascertain the intention"
> > of the firmware engineer, drug-crazed or otherwise. He is making sure
> > that the array of bytes is printable. You, I think, are trying to
> > get him to interepret the out-of-spec values. I think that's a
> > mistake. It's not a string so NUL byte termination does not
> > apply. It's an array of what should be printable characters
> > of the specified length.
>
> The device is out of spec. The question is how to handle it.
I think we agree here.
> Alan thinks that a NUL should be treated as a space.
Alan seems to think, and I agree, that the NUL should be
treated as all the other non-printing characters. No special case,
no guessing.
>I think that a NUL
> indicates the engineer didn't read the spec and intended the string to
> stop there, probably padding with garbage.
>
This is trying to guess what the engineer really meant, though. What
if the engineer meant it to be a token separator?
> Let's take the case of a fictional device that has a vendor string
>
> TJD\0Hje9
>
> I say that should be printed as "TJD ". You say that should be
> printed as "TJD Hje9".
Sure, but what if the Hje9 is not garbage. It's still available in the
proposed patch. It's lost if you overwrite it with spaces. Maybe the
TJD Hje9 requires special handling :)
If it turns out to be garbage couldn't the blacklist entry be set to TJD
and only match the first 3 characters? (I haven't looked at how the
comparison is made).
Indeed it may look better treating the NUL as the end, but I'm arguing
that assuming anything about the intent of the engineer who wrote the
out of spec code is probably a mistake.
Cheers,
Phil
--
Philip R. Auld, Ph.D. Egenera, Inc.
Software Architect 165 Forest St.
(508) 858-2628 Marlboro, MA 01752
next prev parent reply other threads:[~2006-08-21 18:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-21 16:03 [PATCH] SCSI: sanitize INQUIRY strings Alan Stern
2006-08-21 16:14 ` Matthew Wilcox
2006-08-21 16:52 ` Alan Stern
2006-08-21 17:35 ` Matthew Wilcox
2006-08-21 18:11 ` Philip R. Auld
2006-08-21 18:27 ` Matthew Wilcox
2006-08-21 18:51 ` Philip R. Auld [this message]
2006-08-21 19:11 ` Alan Stern
2006-08-21 19:53 ` Alan Stern
2006-08-21 18:31 ` Alan Stern
2006-08-21 18:42 ` Matthew Wilcox
2006-08-21 19:08 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060821185152.GF29299@vienna.egenera.com \
--to=pauld@egenera.com \
--cc=James.Bottomley@SteelEye.com \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox