Enable TPM before TPM Update section

[EskimoRuler]

Hey texhex,

I am currently testing BiosSledgehammer and am finding it to be an awesome tool, so thank you for that.

I'm running into an issue while testing out different scenarios while running BiosSledgehammer 5.1.2.

On my two test HP ProDesk 400 G3 DM BIOS ver 2.22 , I'm testing a scenarios where the TPM is currently set to the below TPM Device == Hidden TPM State == Disable TPM Activation Policy == F1 to boot ( I just want to assume the worst case when running the tool, I'm sure we may never run into this though)

So the first thing I found is that it takes two Runs of the tool to fully enable the TPM. The first run will set the TPM Device == Available and Activate Policy == No prompts, but will error on the TPM State == Enable. Then after a reboot, the TPM State == Enable will be successful.

This is fine as I'm going to run this in a TS multiple times, but the issue I have is since the TPM-Update process comes before the BIOS-Settings, the script will error and exit since it cannot detect a TPM. This meaning the BIOS-Settings will never take effect no matter how many times I run the tool, and it will eventually error on the Enable-Bitlocker step since the TPM never gets enabled.

I can get around this by having two BiosSledgehammer packages, one that just does BIOS Settings, and the other that can contain everything else. But I can see this being difficult to maintain two packages of this over time.

My question is do I have something configured wrong, or is there a way around this?

[texhex]

Thanks for the report and no, you didn't do anything wrong. This configuration is indeed a dead end, as even TPM-BIOS-Settings.txt does not help in this case as this file will only be applied when a TPM was detected. Which will never happen when the TPM is hidden because the script dies before.

The only solution right now is indeed to have two installations where the first only changes the TPM settings with BIOS-Settings.txt and the second one is the "full" version that includes the rest. There is currently a change requested for a similar problem with BIOS updates (see #78), maybe we can use something similar here.

However, this one is will be more complicated because the change requires a reboot. Let me think about this some days, I do not have any idea how to solve this in a way that does not make it more complicate.

[EskimoRuler]

OK thanks for the confirmation. I was happy I could make it work with the two packages, but it left me thinking I could have something wrong.

I was thinking either have the bios settings run before the updates and at the end. That would solve my problem with the TPM needing to be enabled because the first run would set a couple parameters, error on TPM Check. Then run again finish enabling the TPM, possibly error on TPM check if the system requires a reboot to fully enable the TPM, but then should be successful on the 3rd run.

But I'm not sure if that would solve your BIOS-Update issue as the update could run even if the settings was changed before and requires a restart to take effect.

Maybe a switch on the script to have it only run specific processes?

[texhex]

My solution would look like this:

For every update section we have (BIOS-Update, ME-Update and TPM-Update), we would support two additional "Prepare" files. Those files would be execute before the update handling starts and are meant to prepare the computer in order to make the update possible.

They differ from the already existing *-BIOS-Settings.txt files as they would execute always and if a change is detected, a restart is requested. If no change to the current BIOS settings is detected, the next file is processed. In your case, with a complete locked TPM, the process would be like:

TPM-BIOS-Settings-Pre1.txt is executed.

TPM Device == Available 
Activate Policy == No prompts

After the files is executed, BIOS Sledgehammer detects that BIOS settings were changed and requests a reboot. On the next run, TPM-BIOS-Settings-Pre1.txt is executed again and no changes are detected.

TPM-BIOS-Settings-Pre2.txt is executed.

TPM State == Enable

After the files is executed, BIOS Sledgehammer detects that BIOS settings were changed and requests a reboot.

On the next run, TPM-BIOS-Settings-Pre1.txt is executed (no change, no reboot), then TPM-BIOS-Settings-Pre2.txt is executed, again no change, so no reboot.

Now the handling of TPM-Update.txt starts which will work because the TPM is both available and enabled. The existing settings we have in TPM-BIOS-Settings.txt are executed only when an update is required (as it is today) because it doesn't make any sense to change them in case no update is required.

There are only some disadvantages I see with this approach:

• We will have additional reboots and therefore the staging of a machine will take longer
• The BIOS settings in the -Pre*.txt files will be executed every time, extending the runtime of the script as well
• In case the operator uses an incorrect setting in those new files (e.g. a text setting like Ownership Tag), we will have a reboot loop. That's because "touching" this field, even with the same text as before, is considered a change.

Please let me know what you think.

[texhex]

@EskimoRuler Could you please check if my proposed solution make sense from your point of view?

[texhex]

@EskimoRuler Any updates?

[EskimoRuler]

@texhex I apologize for my lack of response on this.

I again want to say your tool works great, I really appreciate the work that you have put into this. So I've done some small deployments with your tool using two packages. One that just does BIOS Settings and the other does BIOS Updates. I run the Settings Package twice, and the BIOS Package once. I've just opted to tackle the TPM updates in the future right now.

Your solution would definitely work, but I can see the disadvantages for sure, and The additional Config files will start adding up too.

I still like the idea of having a parameter(s) to run only BIOS-Settings, TPM-Update, BIOS-Updates, etc. You could maintain one package for all, and for the first couple runs I would just specify BIOS-Settings.

What I do to save a little time is use the return codes to determine if I need a reboot between the two BIOS-Settings and the BIOS-Update. If I get anything other than 0 on the BIOS-Settings, I reboot, I add the 666 code in the Success Codes for the TS Step. And I only reboot after a BIOS-Update if it returns 3010.

[texhex]

Thanks for the update, let me think a bit about it, maybe I can add it in a way it does not make things more complicated that they are already.

Regarding the possibility to start certain sections with parameters: Please explain what the advantages of this would be, I don't get it right now. The sequence they are started should make sense from my point of view.

[texhex]

@EskimoRuler I have thought about using a different approach for this to avoid all the extra files, but I came up empty. The only idea I had was to specify somehow an order with the settings file itself. Although this would reduce the number of files, it would actually complicate things. So given that you now use a different solution and nobody else requests a solution for this, I would like to skip this change for now.

However, I'm still interested in why you want to have a parameter to start a specif section.

[texhex]

@EskimoRuler I'm closing this issue for now. Please feel free to reopen it if you think we should make a code change here.

[ghost]

hey folks i bought a renewed SF315-52 and found that it has no tpm (bios says its not installed) but for some reason it is enabled by default... how is that? if it is not installed how it can be enabled, disabled, cleared? what if it has been switched off in the shop, can i re-enable it?