Re: [PATCH v1 1/2] RISC-V: skip parsing multi-letter extensions starting with caps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 26, 2023 at 01:47:39PM +0100, Conor Dooley wrote:
> On Wed, Apr 26, 2023 at 02:18:52PM +0200, Andrew Jones wrote:
> > On Wed, Apr 26, 2023 at 11:43:24AM +0100, Conor Dooley wrote:
> > > Yangyu Chen reported that if an multi-letter extension begins with a
> > > capital letter the parser will treat the remainder of that multi-letter
> > > extension as single-letter extensions.
> > 
> > I think the problem is that the parser doesn't completely abort when
> > it sees something it doesn't understand. Continuing is risky since
> > it may be possible to compose an invalid string that gets the parser
> > to run off the rails.
> 
> Usually I am of the opinion that we should not seek the validate the dt
> in the kernel, since there are tools for doing so *cough* dt-validate
> *cough*. This one seemed like low hanging fruit though, since the parser
> handles having capital letters in any of the other places after the
> rv##, but falls over pretty badly for this particular issue.
> 
> In general, I don't think we need to be concerned about anything that
> fails dt-validate though, you kinda need to trust that that is correct.
> I'd argue that we might even do too much validation in the parser at
> present.
> Is there some attack vector, or ACPI related consideration, that I am
> unaware of that makes this risky?

C language + string processing == potential attack vector

> 
> > How about completely aborting, noisily, when the string doesn't match
> > expectations, falling back to a default string such as rv64ima instead.
> > That also ought to get faster corrections of device trees.
> 
> I did this first actually, but I was afraid that it would cause
> regressions?
> 
> If you have riscv,isa = "rv64imafdc_Zifencei_zicbom", yes that is
> invalid and dt-validate would have told you so, but at present that
> would be parsed as "rv64imafdc_zicbom" which is a perfect description of
> the hardware in question (since the meaning of i was set before RVI made
> a hames of things).
> 
> So that's why I opted to not do some sort of pr_err/BUG()/WARN() and
> try to keep processing the string. I'm happy to abort entirely on
> reaching a capital if people feel there's unlikely to be a fallout from
> that.

There might be fallout, but the kernel needs to defend itself. IMO, if
the kernel doesn't know how to parse something, then it should stop
trying to immediately, either with a BUG(), refusing to accept any
part of it, by fallbacking back to a default, or by only accepting what
it believes it parsed correctly.

The third option is probably a reasonable choice in this case.

Thanks,
drew



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux