Re: [flashrom] [PATCH] Refactor the -p internal:mainboard handling.

[Carl-Daniel Hailfinger]

Am 15.08.2012 04:29 schrieb Stefan Tauner:
> On Wed, 15 Aug 2012 02:03:29 +0200
> Carl-Daniel Hailfinger  wrote:
> > Am 13.08.2012 02:51 schrieb Stefan Tauner:
> > > This patch gets rid of some global variables and makes lots of bits along
> > > the code path that control the board enable execution more generic and
> > > clearer. From now on flashrom also abort on a few occasions that should be
> > > safer for the user. For example we abort if he specifies the mainboard (enable)
> > > but we can not find the enable function.
> > >
> > > Parts of the board_match_cbname refactoring were done by Carl-Daniel.
> > >
> > > FIXME: manpage
> > >
> > > Signed-off-by: Stefan Tauner 
> > > Signed-off-by: Carl-Daniel Hailfinger
> >
> > Acked-by: Carl-Daniel Hailfinger 
> > with a few comments and if you fix the manpage.
> >
> > BIG FAT NOTE: You do not have to change all the stuff mentioned in the
> > review (because that would mean I have to review the patch again), but
> > it would be nice to have the review comments addressed in a followup patch.
> > > diff --git a/board_enable.c b/board_enable.c
> > > index 9c16905..22d4072 100644
> > > --- a/board_enable.c
> > > +++ b/board_enable.c
> > > @@ -25,6 +25,7 @@
> > >   */
> > >
> > > #include <string.h>
> > > +#include <stdlib.h>
> > >  #include "flash.h"
> > >  #include "programmer.h"
> > >  #include "hwaccess.h"
> > > @@ -2443,41 +2444,63 @@ const struct board_match board_matches[] = {
> > >    {     0,      0,      0,      0,       0,      0,      0,      0, NULL,         NULL, NULL,           P3, NULL,          NULL,                    0,   NT, NULL}, /* end marker */
> > >  };
> > >
> > > +/* Parse the <vendor>:<board> string specified by the user as part of -p internal:mainboard=<vendor>:<board>.
> > > Parameters vendor and model will be overwritten. Returns 0 on success.
> > > Note: strtok modifies the original string, so we work on a copy and allocate memory for the results.
> > > */
> > >
> > > +int board_parse_parameter(const char *boardstring, const char **vendor, const char **model)
> > > +{
> > > /* strtok may modify the original string. */
> > > char *tempstr = strdup(boardstring);
> > > char *tempstr2 = NULL;
> > > strtok(tempstr, ":");
> > > tempstr2 = strtok(NULL, ":");
> > > if (tempstr == NULL || tempstr2 == NULL) {
> > > free(tempstr);
> >
> > While freeing only tempstr is correct, it's not obvious.
>
> it is not?
> then maybe my naivety guided me well :)
> tempstr is the only one that is newly allocated up to this point.
> strtok does modify the given string but not allocate a new one... i
> thought?

Well, it was not obvious when I reviewed the code late at night ;-)
> > […]
> > > ret = unsafe_board_handler(board);
> >
> > Side note: unsafe_board_handler is a pretty dumb name. Yes, it's my
> > fault. Still... check_unsafe_board_enable() or something similar would
> > be a better name.
>
> is_board_enable_(un)safe()?

Yes. I would pick is_board_enable_safe(), but I'm fine with either of
your suggestions.
> > > -int show_id(uint8_t *bios, int size)
> > > +/* Tries to find coreboot IDs in the supplied image and compares them to the current IDs.
> > > Returns...
> > > -1	if IDs in the image do not match the IDs embedded in the current firmware,
> > > 0	if the IDs could not be found in the image or if they match correctly.
> > > */
> > >
> > > +int cb_check_image(uint8_t *image, int size)
> >
> > cb_check_image_matches_board would be a better name IMHO.
>
> it reflects the current behavior better, yes.
> but OTOH it seems to have started as a function that was just showing
> the ID and the name was not changed until now, although the behavior
> changed a lot. i dont like to name functions too precisely because
> it can easily become wrong :)
> also, it is much longer and now there is a comment explaining exactly
> what it does in case someone does not know.

I envision lots of similar functions in the future, e.g. for checking
the PCI ID embedded in an option ROM file against the PCI ID of the
target device. check_image_matches_optionrom_pcidevice() and
check_image_matches_board_awardbios() and
check_image_matches_board_coreboot()... so the name I suggested isn't
optimal either.
If we use check_image_matches_ as prefix, we'd have a consistent prefix
for any such future functions.
Your choice.
> > > {
> > > const char *image_vendor = NULL;
> > > const char *image_model = NULL;
> > > unsigned int *walk;
> > > unsigned int mb_part_offset, mb_vendor_offset;
> > > char *mb_part, *mb_vendor;
> > > mainboard_vendor = def_name;
> > > mainboard_part = def_name;
> > > walk = (unsigned int *)(bios + size - 0x10);
> > > walk = (unsigned int *)(image + size - 0x10);
> > > walk--;
> >
> > The two lines above made me scream WTF?!?
> > Since you're already fixing that code, can you please merge them into one?
> > walk = (unsigned int *)(image + size - 0x14);
>
> I am deliberately not *fixing* the cbtale.c code (and i wont in the near
> future). in this case i have no idea if your change is even correct.
> what if sizeof(int) != 4? is the next item still at x - 0x14 then and
> the current code is wrong or would your change break the now correct
> code? or am i missing something? :)

OK, I can fix this in a followup patch.
> > > if ((*walk) == 0 || ((*walk) & 0x3ff) != 0) {
> > > /* We might have an NVIDIA chipset BIOS which stores the ID information somewhere else. */
> > > walk = (unsigned int *)(bios + size - 0x80);
> > > /* We might have an NVIDIA chipset which stores the ID information somewhere else. */
> >
> > Actually, "BIOS" wasn't that wrong... let me rephrase the comment so
> > that others may have a chance to understand the reason:
> >
> > /* Some NVIDIA chipsets store chipset soft straps (IIRC Hypertransport
> > init info etc.) in flash at exactly the location where coreboot image
> > size, coreboot vendor name pointer and coreboot board name pointer are
> > usually stored. In this case coreboot uses an alternate location for the
> > coreboot image data. */
>
> i dont see how this makes BIOS less wrong, but thank you very much for
> the clarification!

You could leave the comment here alone, and I could send a separate
patch with the offset fixups I suggested and with the new comment I
suggested. Your choice.
> > > msg_pdbg("coreboot last image size (not ROM size) is %d bytes.\n", *walk);
> > > mainboard_part = strdup(mb_part);
> > > mainboard_vendor = strdup(mb_vendor);
> > > msg_pdbg("Manufacturer: %s\n", mainboard_vendor);
> > > msg_pdbg("Mainboard ID: %s\n", mainboard_part);
> > > image_vendor = strdup(mb_vendor);
> > > image_model = strdup(mb_part);
> >
> > If the image looks like a coreboot image according to our checks, but
> > it's malformed (or not a coreboot image), checking string length with
> > if (strnlen(mb_vendor, mb_vendor_offset) < mb_vendor_offset)
> > and aborting otherwise may be a good idea to avoid segfaults. Can be
> > done in a followup patch, though.
>
> yes, indeed.
> as mentioned above i dont want to touch any of this code. i have seen
> enough of it that i know that i would have to study coreboot's code and
> then rewrite half of this file before i am satisfied. do not want. i
> deem it almost useless... who uses coreboot, flashes the wrong image
> and is not able to recover afterwards? - someone who deserves it. ;)

OK, I will send a patch for it.
> > > msg_pdbg("Manufacturer: %s\n", image_vendor);
> > >
> > > msg_pdbg("Mainboard ID: %s\n", image_model);
> > >
> > > /* If these are not set, the coreboot table was not found. */
> > > if (!lb_vendor || !lb_part) {
> > > msg_pinfo("Note: If the following flash access fails, try "
> > > 	  "-p internal:mainboard=<vendor>:<mainboard>.\n");
> > > if (!cb_vendor || !cb_model)
> > > return 0;
> > >
> > > }
> > >
> > > /* These comparisons are case insensitive to make things a little less user^Werror prone. */
> > >
> > > if (!strcasecmp(mainboard_vendor, lb_vendor) &&
> > >    !strcasecmp(mainboard_part, lb_part)) {
> > > msg_pdbg("This firmware image matches this mainboard.\n");
> > > if (!strcasecmp(image_vendor, cb_vendor) && !strcasecmp(image_model, cb_model)) {
> > > msg_pdbg2("This coreboot image matches this mainboard.\n");
> > > } else {
> > > if (force_boardmismatch) {
> > > 	msg_pinfo("WARNING: This firmware image does not "
> > > 	       "seem to fit to this machine - forcing it.\n");
> > > } else {
> > > 	msg_pinfo("ERROR: Your firmware image (%s:%s) does not appear to\n"
> > > 		  "       be correct for the detected mainboard (%s:%s)\n\n"
> > > 		  "Override with -p internal:boardmismatch=force to ignore the board name\n"
> > > 		  "in the firmware image or override the detected mainboard with\n"
> > > 		  "-p internal:mainboard=<vendor>:<mainboard>.\n\n",
> > > 		  mainboard_vendor, mainboard_part, lb_vendor, lb_part);
> > > 	return 1;
> > > }
> > > msg_pinfo("WARNING: This coreboot image (%s:%s) does not appear to\n"
> > > 	  "         be correct for the detected mainboard (%s:%s).\n",
> > > 	  image_vendor, image_model, cb_vendor, cb_model);
> > > return -1;
> > >
> > > }
> > >
> > > return 0;
> > >
> > > @@ -242,22 +206,15 @@ static void find_mainboard(struct lb_record *ptr, unsigned long addr)
> >
> > find_mainboard is a misnomer... it should be
> > get_mainboard_from_cb_record or something like that, and the addr
> > parameter was never used since the code was first committed. Followup
> > patch, no need to complicate this one.
>
> true, but OTOH it is just a static method...

My concern was code readability, not public interfaces. You're right
that this code fortunately isn't called from outside this file. To be
honest, this file is probably (except layout.c) the least modified file
since flashrom development started.
> > […]
> > > *vendor = cb_vendor;
> > > *model = cb_model;
> >
> > I'm not totally happy with those static variables, but I can't offer a
> > better suggestion (unless we want to extend struct flashctx with
> > board/device matching info, but anything like that should be a separate
> > patch.
>
> yes... but the problem is that cb_check_image is called in doit() and
> there is no easy and sane way to get that information there.
> OTOH i dont like that special case in doit anyway. it is necessary
> because the image is read in there and hence is not available earlier
> (at programmer init time).

Mh yes.
> any changes in this regard would conflict with the layout patch set so
> let's postpone this discussion for now. and the situation improved a lot
> already anyway (Eigenlob duftet ausgezeichnet! :)

Aaaaaargh, don't remind me of the layout patches. That will be the most
painful review ever.
> > > diff --git a/flashrom.c b/flashrom.c
> > > index 9544155..c39c12c 100644
> > > --- a/flashrom.c
> > > +++ b/flashrom.c
> > > @@ -1814,11 +1814,15 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it,
> > >    	}
> > >
> > > #if CONFIG_INTERNAL == 1
> > > if (programmer == PROGRAMMER_INTERNAL)
> > > 	if (show_id(newcontents, size)) {
> > > if (programmer == PROGRAMMER_INTERNAL && cb_check_image(newcontents, size) < 0) {
> > > 	if (force_boardmismatch) {
> > > 		msg_pinfo("Proceeding anyway because user forced us to.\n");
> > > 	} else {
> > > 		msg_perr("Aborting. You can override this with -p internal:boardmismatch=force.\n");
> >
> > 112 column limit...
>
> fixed
> > > diff --git a/internal.c b/internal.c
> > > index 3ecc348..b1686aa 100644
> > > --- a/internal.c
> > > +++ b/internal.c
> > > @@ -249,10 +256,20 @@ int internal_init(void)
> > >    }
> > >
> > > #if defined(__i386__) || defined(__x86_64__)
> > > /* We look at the cbtable first to see if we need a
> > > * mainboard specific flash enable sequence.
> > > */
> > > coreboot_init();
> > > if (cb_parse_table(&cb_vendor, &cb_model) == 0) { /* coreboot IDs valid */
> > > /* if no -p internal:mainboard was given but there are valid coreboot IDs then use those */
> >
> > Please capitalize first word and finish with full stop. Otherwise you'll
> > see an instant followup commit by Uwe changing it. ;-)
>
> if it motivates him to look at flashrom code again, then maybe i should
> keep it that way :P

Heh.
> > > if (board_vendor == NULL || board_model == NULL) {
> >
> > Is it even possible that only one of board_vendor/board_model is NULL?
>
> no, it should not be possible. OTOH '&&' wouldnt be 'more' correct
> either, but i want to check both variables... mostly for
> consistency/symmetry i guess :)

Good idea.
> > > 	board_vendor = cb_vendor;
> > > 	board_model = cb_model;
> > > } else if (strcasecmp(board_vendor, cb_vendor) || strcasecmp(board_model, cb_model)) {
> > > 	msg_pinfo("WARNING: The mainboard IDs set by -p internal:mainboard (%s:%s) do not\n"
> > > 		  "         match the current coreboot IDs of the mainboard (%s:%s).\n",
> > > 		  board_vendor, board_model, cb_vendor, cb_model);
> > > 	if (!force_boardmismatch)
> > > 		return 1;
> > > 	msg_pinfo("Continuing anyway.\n");
> > > }
> > >
> > > }
> > >
> > > dmi_init();
> > >
> > > @@ -321,12 +338,11 @@ int internal_init(void)
> > >    init_superio_ite();
> > >  #endif
> > > board_flash_enable(lb_vendor, lb_part);
> > > if (board_flash_enable(board_vendor, board_model)) {
> > > msg_perr("Aborting to be safe.\n");
> > > return 1;
> > > }
> > > /* Even if chipset init returns an error code, we don't want to abort.
> > > * The error code might have been a warning only.
> >
> > The two lines above still make sense AFAICS.
>
> no, but it did not change with this patch. it has been wrong for a
> while i guess. first of all the location is wrong. secondly it is not
> true: we DO abort in some cases. and there is a comment explaining this
> there already:
>    /* try to enable it. Failure IS an option, since not all motherboards
>     * really need this to be done, etc., etc.
>     */
>    ret = chipset_flash_enable();
>
> this could be improved though. :)
>
> i have put it back anyway for now because it is unrelated and can
> easily be removed in my tested_stuff branch... just tell me if you are
> convinced please.

Convinced.
> > Thanks for cleaning up this code!
>
> i would lie if i would write "my pleasure", but i am sure reviewing
> this was similarly dreadful. :) thanks for the review!
> i still need to refine the manpage... so no commit yet.

Thanks for all the work you did!

Regards,
Carl-Daniel