Neutralizing *and* shrinking / moving IME?

[amit4z]

I've noticed skulls only sets Intel ME's disable flag, and removes it's rw permissions (on the chip's file-system?), via me_cleaner?

external_install_bottom.sh:

if [ "$me_clean" -gt 0 ] ; then ${ME_CLEANER_PATH} -d -S -O "${TEMP_DIR}"/work.rom "${TEMP_DIR}"/test1.rom else cp "${TEMP_DIR}"/test1.rom "${TEMP_DIR}"/work.rom fi

$ python me_cleaner.py -h: ...

-d, --descriptor
remove the ME/TXE Read/Write permissions to the other regions on the flash from the Intel Flash Descriptor (requires a full dump)

-S, --soft-disable in addition to the usual operations on the ME/TXE firmware, set the MeAltDisable bit or the HAP bit to ask Intel ME/TXE to disable itself after the hardware initialization (requires a full dump)

-O output_file, --output output_file save the modified image in a separate file, instead of modifying the original file

Is there a reason not to repartition and shrink it too?

-r, --relocate relocate the FTPR partition to the top of the ME region to save even more space

-t, --truncate truncate the empty part of the firmware (requires a separated ME/TXE image or --extract-me)

-D output_descriptor, --extract-descriptor output_descriptor extract the flash descriptor from a full dump; when used with --truncate save a descriptor with adjusted regions start and end

-M output_me_image, --extract-me output_me_image extract the ME firmware from a full dump; when used with --truncate save a truncated ME/TXE image

(maybe -c would come in handy for skulls too?)

-c, --check verify the integrity of the fundamental parts of the firmware and exit

Could I safely add these options to external_install_bottom.sh, as suggested here:

https://github.com/corna/me_cleaner/wiki/External-flashing If you instead want to recover the extra ROM space (which is a considerable amount of space, ~1 MB or ~5 MB, depending on the firmware type): $ python me_cleaner.py -S -r -t -d -O out.bin -D ifd_shrinked.bin -M me_shrinked.bin original_dump.bin

https://mail.coreboot.org/pipermail/coreboot/2018-April/086642.html "By the way, with the last ROM IFB + GBE + cleaned relocated ME use less than 100K of flash out of the available 12M (the rest is filled with 0xff and coreboot). 11.9M is a lot of space to play with."

16bit.io/16bit.io.html Security concerns aside, the ME also takes up 5.2MB of precious space on my SPI chip, which I was able to reduce to 90kB using me_cleaner. It's important to also update your firmware layout to shrink the ME "partition" so that you can take advantage of the additional space.

or would this mess up your provided roms?

It would be great if you could add and hardware-flash-test these options in skulls! I could sure sleep a lot easier with IME reduced to a pile of dust and the rest of the precious space filled up with my nifty boot-images! :)

Thanks so much! (and so sorry for all the text! :))

[merge]

technically, you can add the options to relocate and make space for the bios. There is a reason we don't do that here: We don't want to be dependent on having me_cleaner applied (if not really necessary). It's an option, but our image should fit either way, so we don't gain anything.

[amit4z]

I take it the (skulls-)image would just be restructured by --relocate, and the --truncate means the additional free space (former IME-parts) would get overwritten with garbage or zeroes at flashing, if I don't put any images there?

technically, you can add the options to relocate and make space for the bios.

In external_install_bottom.sh can I then safely replace the line ${ME_CLEANER_PATH} -d -S -O "${TEMP_DIR}"/work.rom "${TEMP_DIR}"/test1.rom with ${ME_CLEANER_PATH} -S -r -t -d -c -O "${TEMP_DIR}"/work.rom "${TEMP_DIR}"/test1.rom -D ifd_shrinked.bin -M me_shrinked.bin and be sure that I don't mess anything up?

Or do i also have to

Rebuild coreboot selecting ifd_shrinked.bin as IFD_BIN_PATH, me_shrinked.bin as ME_BIN_PATH and increasing CBFS_SIZE accordingly and flash the resulting image. (me_cleaner: Internal flashing with coreboot)

by using skulls' build.sh semi-manually, or by building from scratch? (which I'm not sure how to (especially the CBFS_SIZE), and wanted to avoid that by using skulls in the first place :( )

Could you please test this in practice first? I would be so grateful, as I'm an utter novice and afraid of trashing my computer.

We don't want to be dependent on having me_cleaner applied (if not really necessary).

What do you mean by dependent? Couldn't you just add it as an extended e.g. external_install_bottom.sh -me option, which would be passing all the parameters $ python me_cleaner.py -S -r -t -d -c -O out.bin -D ifd_shrinked.bin -M me_shrinked.bin original_dump.bin (and if needed also supplying a me_cleaned skulls-image), for users who want to recover the space?

Or is there a risk in applying me_cleaner?

Would it be possible to apply sudo ./external_install_bottom.sh -m -k as it is today, and internally/sofware-flash the above laters (e.g. with a newer x230_skulls.sh version), or does me_cleaner's --relocate and --truncate etc need to be done by hardware-flashing once again?

Also, would it be possible for skulls to have an option to add free boot-images/coreboot-payloads like Memtest86+, iPXE netboot, FreeDOS, Hardware Detection Tool and the likes in the future? I suppose this is not something that can easily be added from SeaBIOS alone, after flashing?

[fhvyhjriur]

It would be more simple (this is what skulls is about) when skulls does that by default like the prebuild heads-maximized. Thats why i talk about it here: https://github.com/merge/skulls/issues/178

Then also the installation is much more simple and only requires flashrom as software to flash both prebuild files for the top and the bottom chip.