Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization ofthe SG_IO command whitelist (CVE-2012-4542))

From: Tejun Heo
Date: Fri May 24 2013 - 04:03:37 EST


On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>> The same filtering table being applied to different classes of
>> hardware is a software bug, but my point is that the practive
>> essentially entrusts non-insignificant part of security enforcement to
>> the hardware itself. The variety of hardware in question is very wide
>> and significant portion has historically been known to be flaky.
>
> Unproven theory, and contradicted by actual practice. Bugs are more
> common in the handling of borderline conditions, not in the handling of
> unimplemented commands.
>
> If you want to be secure aginst buggy firmware, the commands you have to
> block are READ and WRITE. Check out the list of existing USB quirks.

Well, I'd actually much prefer disabling CDB whitelisting for all !MMC
devices if at all possible. You're basically arguing that because what
we have is already broken, it should be okay to break it further.
Also, RW commands having more quirks doesn't necessarily indicate that
they tend to be more broken. They just get hammered on a lot in
various ways so problems on those commands tend to be more noticeable.

> You need to allow more commands.
> The count-me-out knob allows all commands.
> You cannot always allow all commands.
> Ergo, you cannot always use the count-me-out knob.

The thing is that both approaches aren't perfect here so you can make
similar type of argument from the other side. If the system wants to
give out raw hardware access to VMs, requiring it to delegate the
device fully could be reasonable. Not ideal but widening direct
command access by default is pretty nasty too.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/