> -----Original Message----- > From: Antoine Tenart <antoine.tenart@xxxxxxxxxxx> > Sent: Wednesday, July 31, 2019 4:46 PM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Cc: Antoine Tenart <antoine.tenart@xxxxxxxxxxx>; Pascal van Leeuwen > <pascalvanl@xxxxxxxxx>; linux-crypto@xxxxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx; > davem@xxxxxxxxxxxxx > Subject: Re: [PATCHv2 3/3] crypto: inside-secure - add support for using the EIP197 > without vendor firmware > > On Wed, Jul 31, 2019 at 02:23:27PM +0000, Pascal Van Leeuwen wrote: > > > From: Antoine Tenart <antoine.tenart@xxxxxxxxxxx> > > > > > What happens if i < 2 ? > > > > > Ok, I did not consider that as it can't happen for any kind of legal FW. But it > > wouldn't be pretty (neither would 2 itself, BTW). I could throw an error for it > > but it wouldn't make that much sense as we don't do any checks on the firm- > > ware *contents* either ... So either way, if your firmware file is no good, you > > have a problem ... > > The thing is to avoid doing harm to the kernel if a single driver can't > work as expected, especially when we have an user input (the firmware). > The firmware being a valid one is another topic. But honestly I'm not > sure if a wrong returned value would change anything here, apart from > not probing the driver successfully as we know something went wrong. > Initially I thought it would hang (as the HW would hang for sure), but on second observation the driver already has a nice time-out mechanism on the firmware startup, so it would just throw a nice error and bail out. Same as it would do for a e.g. a corrupted image. So I think this is just fine. > Thanks, > Antoine > > -- > Antoine Ténart, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
