`git submodule update --init` gives "fatal: Could not read from remote repository." about reopt

[travitch]

The CFI instruction support is missing in the disassembler and being tracked in GaloisInc/flexdis86#9. I don't have a timeline but would also like to get to that soon.

[joehendrix]

Would prebuilt binaries or containers (e.g. docker images) make trying out reopt easier for you? I can switch the urls by default for those without Github accounts, but I'm not sure how many people will be served by compiling from source versus us just putting prebuilt images up.

[mewmew]

Hi @joehendrix,

Thanks for giving this some thought. I prefer the source build, and have reopt working on my development laptop.

This issue was mostly to give a heads up that git clone --recursive (and other Git submodule commands) may not work for users that have no configured Git SSH key; which is probably fine. The alternative would be to set the origin of submodules to use https://github.com/org/repo.git schema instead of [email protected]:org/repo.git. The trade-off is whether to make it easier for developers of reopt or first time users without Git keys (of which there are likely fewer). Personally, I think it makes more sense to have the experience optimized for developers of reopt.

That being said, providing access to e.g. Docker images with re-build environment of reopt would certainly be useful for people that want to try out the project without having to configure the build environment. The two are not mutually exclusive :)

Cheers,
Robin

[joehendrix]

I'm going to update the readme to address this for now. I plan to continue making the tool more robust before making it easy for people to run into problems running the tool.

[mewmew]

I'm going to update the readme to address this for now. I plan to continue making the tool more robust before making it easy for people to run into problems running the tool.

Thanks @joehendrix!

On a related note, regarding the robustness of reopt, I tried lifting a sample binary the other day but reopt failed with an error since the binary contained Control Flow Integrity enforcement instructions; in particular reopt did not seem to know how to handle the ENDBR64 instruction (or ENDBR32) of Intel CET (Control-flow Enhancement Technology) [1]. Most lifters handle these instructions as NOP instructions, as they don't perform any operation except enforcing control-flow restrictions. When lifting to LLVM IR, such restrictions may already be enforced by the language (depending on how indirect branches are modelled).

Is there any ongoing work to add support for the CET instructions to reopt?

Cheers,
Robin

[mewmew]

Thanks Tristan! Good to know.

[travitch]

@mewmew I've added support in the relevant core tools (flexdis86 and macaw) for the endbr instructions. As you note, they are currently treated as no-ops. This support is enough for many cases, but I've noticed that some newer compilers are generating a new variant of indirect jump (the notrack prefix, which disables CFI checking for a given jump). Macaw does not have support for those yet.

[mewmew]

Thanks for keeping me updated @travitch! Glad to see support for endbr having landed in the disassembler used by reopt. Did not know there was a notrack prefix. Hopefully my sample binaries will work now with endbr. We'll see!

Cheers,
Robin

[travitch]

Just to be clear, I think we still need to update reopt to take advantage of the change - it might just be a matter of updating submodules, but I'm not sure offhand

[mewmew]

Just to be clear, I think we still need to update reopt to take advantage of the change - it might just be a matter of updating submodules, but I'm not sure offhand

Sure. I'll probably give this a try in a week or two. So no rush.