vendor.sh: prevent double-nuke

where the nuke command is used, we need the files to be
there; if they're not, it will try to nuke them, which will result
in an error in most cases, but there may be some cases where that
isn't true, for instance if only the Intel ME is needed; it'll be
writing zeroes over zeroes.

we want to only allow technically correct behaviour, because
technically correct is the best kind of correct.

it is theoretically possible that a double-nuke might affect
certain behaviours unpredictably. for example, if vendor.sh
later integrates another tool that works whereby the same command
inserts or nukes depending on a certain condition, but with the
same command, and where that command would return zero in both
cases.

this is a preventative bug fix, because it fixes an issue that
does not yet actually occur in practise.

Signed-off-by: Leah Rowe <leah@libreboot.org>

include/vendor.sh

@@ -565,11 +565,23 @@ patch_rom()
 {
 	rom="$1"
 
+	# regarding ifs below:
+	# if a hash file exists, we only want to allow inject.
+	# if a hash file is missing, we only want to allow nuke.
+	# this logical rule prevents double-nuke and double-inject
+
+	# if injecting without a hash file
 	if [ "$has_hashes" != "y" ] && [ "$nukemode" != "nuke" ]; then
 		printf "inject: '%s' has no hash file. Skipping.\n" \
 		    "$archive" 1>&2
 		return 1
 	fi
+	# nuking *with* a hash file, i.e. nuking what was nuked before
+	if [ "$has_hashes" = "y" ] && [ "$nukemode" = "nuke" ]; then
+		printf "inject nuke: '%s' has a hash file. Skipping nuke." \
+		    "$archive" 1>&2
+		return 1
+	fi
 
 	[ -n "$CONFIG_HAVE_REFCODE_BLOB" ] && inject "fallback/refcode" \
 	    "$CONFIG_REFCODE_BLOB_FILE" "stage"