LLD: CET shadow stack support on Windows

[penzn]

Summary

This patch implements CET Shadow Stack (Intel Controlflow Enforcement Technology) support on Windows.

Windows support for CET is limited to shadow stack, which is enabled by setting a PE bit in the linker.

Docs:

• MSVC linker flag: https://docs.microsoft.com/en-us/cpp/build/reference/cetcompat?view=vs-2019
• IMAGE_DLLCHARACTERISTICS_EX_CET_COMPAT PE bit: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#extended-dll-characteristics

[craig.topper]

Can you reupload the patch with full context. Using -U999999 on your diff command

[penzn]

Full(er) patch for the same change.

[mstorsjo]

lld/MinGW/Options.td

105 ↗

(On Diff #230720)

FWIW, if you want the option to actually have any effect when passed to the mingw driver, you need a couple lines in MinGW/Driver.cpp (and a corresponding test in test/MinGW/driver.test).

[penzn]

lld/MinGW/Options.td

105 ↗

(On Diff #230720)

Good point, thank you. That is intentional - I noticed that other MSVC security flags have no effect in MinGW driver.

There is a patch for GNU-compatible linker on Linux, D59780, though I am not sure if we can simply wire those options to COFF implementation introduced here. The goal of this patch is to support the VS-compatible flag.

I might be wrong with my assumptions on MinGW driver, any clarification would be greatly appreciated.

[mstorsjo]

lld/MinGW/Options.td

105 ↗

(On Diff #230720)

Well, some of them, like nxcompat, are enabled by default within lld, and I'm not sure there's any GNU linker option to disable it, so therefore we don't actually act upon that option, while other flags like dynamicbase do exist and are forwarded.

As there's no predecent for these options being used in the wild with GNU ld for mingw so far, you could just omit it from this file if you aren't planning on hooking it up, as it won't be necessary for compatibility with existing projects built for mingw.

But I presume it could make sense to enable this flag in mingw configurations as well (would it?), and in that case, hooking it up with the same option name as for the ELF frontend, forwarding it to the link/COFF style flag name would be most welcome.

[ruiu]

llvm/test/tools/llvm-readobj/coff-cet-compat.test

11–15

It looks like there are still a few unused bit in the real DLLCharacteristics bit (https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#dll-characteristics), so it is a bit odd that Microsoft chose to define an "extended" DLLCharacteristics field now, but well, if they chose this format we'll have to follow.

Are AddressOfRawData and PointerToRawData significant for ExtendedCharacteristics entries? I'd b tempted to fill them with zero, as they don't seem to make any meaning in this context.

[penzn]

lld/MinGW/Options.td

105 ↗

(On Diff #230720)

GNU would have its own CET flags, there is an effort to port them to LLD in D59780. I can remove the flag from MinGW to avoid confusion, though I don't feel strongly either way. What do you think?

llvm/test/tools/llvm-readobj/coff-cet-compat.test

11–15

Yep, I am also not sure why this was necessary either, may be they are seeing some important use for the new field (right now it a can only contain this bit).

AddressOfRawData and PointerToRawData are coming from MSVC linker, I think that is where the bit is stored. I don't know if it is possible to "inline" it into the entry somehow:

If the Type field is set to IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS, the debug raw data contains extended DLL characteristics bits. [...]

[ruiu]

llvm/test/tools/llvm-readobj/coff-cet-compat.test

11–15

I mean my question is what values does MSVC link.exe sets to AddressOfRawData and PointerToRawData?

[mstorsjo]

lld/MinGW/Options.td

105 ↗

(On Diff #230720)

Yes, I'd prefer to not add any code for the MinGW driver until it does something meaningful in this case.

[penzn]

Remove unused MinGW flag

[penzn]

lld/MinGW/Options.td

105 ↗

(On Diff #230720)

Done. We can revisit this in a separate patch - and tie Windows CET functionality to shadowstack option in GNU-style flag.

llvm/test/tools/llvm-readobj/coff-cet-compat.test

11–15

I think it allocates a 4-byte value, sets CET bit in it, and points both AddressOfRawData and PointerToRawData to it. At least that what it looks like from the outside, though I can be wrong.

[ruiu]

LGTM with these fixes.

lld/COFF/Writer.cpp

172

The constructor should take uint32 instead of unsigned.

173

C -> c

175–177

Let's just return 4.

180

Likewise, I'd replace sizeof() with 4.

180

B -> buf

183

Characteristics -> characteristics

957

Break this line so that it fits within 80 columns.

llvm/tools/llvm-readobj/COFFDumper.cpp

751

80 cols

753

80 cols

[penzn]

Incorporate review feedback

[penzn]

Thank you!

lld/COFF/Writer.cpp

175–177

Just curious, why this way - easier to read?

[ruiu]

lld/COFF/Writer.cpp

175–177

Yeah. If we return 4 the size of this record is obviously 4 bytes. Since this class is so small, I don't think that we need any abstraction to hide the magic number.

[penzn]

Can you help me merge this? I don't have commit access.

[ruiu]

Could you tell me about how you generated has_cet.exe? I wonder if there's a way to create an executable in the test instead of submitting a binary file to the repository.

[jhenderson]

In D70606#1778998, @ruiu wrote:

Could you tell me about how you generated has_cet.exe? I wonder if there's a way to create an executable in the test instead of submitting a binary file to the repository.

On this topic, yaml2obj has COFF support, although I don't know if that's sufficient for your use case here.

[penzn]

In D70606#1778998, @ruiu wrote:

Could you tell me about how you generated has_cet.exe? I wonder if there's a way to create an executable in the test instead of submitting a binary file to the repository.

It is a dummy executable (along the lines of int main() {return 0;}) built with Visual Studio 2019. This was inspired by the existing llvm-readobj PDB test which checks has_pdb.exe.

In D70606#1779258, @jhenderson wrote:

On this topic, yaml2obj has COFF support, although I don't know if that's sufficient for your use case here.

yaml2obj does not yet have CET flag support. What is the preferred path in this situation? We can add it, but it would be only used in this test.

[ruiu]

In D70606#1780090, @penzn wrote:

In D70606#1778998, @ruiu wrote:

Could you tell me about how you generated has_cet.exe? I wonder if there's a way to create an executable in the test instead of submitting a binary file to the repository.

It is a dummy executable (along the lines of int main() {return 0;}) built with Visual Studio 2019. This was inspired by the existing llvm-readobj PDB test which checks has_pdb.exe.

In D70606#1779258, @jhenderson wrote:

On this topic, yaml2obj has COFF support, although I don't know if that's sufficient for your use case here.

yaml2obj does not yet have CET flag support. What is the preferred path in this situation? We can add it, but it would be only used in this test.

I'd prefer enhancing yaml2obj tool so that it can emit the extended characteristics field if it is not too hard.

[jhenderson]

In D70606#1779258, @jhenderson wrote:

On this topic, yaml2obj has COFF support, although I don't know if that's sufficient for your use case here.

yaml2obj does not yet have CET flag support. What is the preferred path in this situation? We can add it, but it would be only used in this test.

I'd prefer enhancing yaml2obj tool so that it can emit the extended characteristics field if it is not too hard.

In general, I'm always in favour of enhancing the tool where possible. Binary files are always opaque and hard to understand what is in them, so yaml2obj should be extended if it's sensible to do so. The more we do that, the less easier future tests will be to write!

[penzn]

yaml2obj is capable of producing binary .rdata section (which would host CET bit) from hex, but not individual debug directories that would go into it. Looks like all the tests dealing wit debug directories are using pre-built binaries - codeview tests are a good example).

[penzn]

@ruiu can we separate enhancing yaml2obj from this change? I would be more than happy to help with implementing debug directory support as a separate change, to avoid making this change much more involved.

[penzn]

Expanding on my previous comment. In its current state yaml2obj is not aware of the section contents, and I think adding this functionality would be a bit more involved than the code we have in this review so far.

Quick rundown of what would be needed for yaml2obj change:

• Define YAML syntax for debug entries
• Support debug directory and its contents inside section mapping in ObjectYAML
  • Need to represent the structure from Debug section down to individual debug records
• Change other tests which depend on debug directory structure

We should probably discuss details. For example, can debug directory support in ObjectYAML take inspiration from LLD or would that make testing moot? Would ObjectYAML need any tests for this new functionality?

Do you mind if we move ObjectYAML discussion elsewhere? What would be a good place for it, llvm-dev?

As for this change, another option is to use yaml2obj, but output debug directory as a hex section in the YAML file. However this would inconsistent with codeview tests, maybe it would be better to change everything at once when yaml2obj is ready.

[jhenderson]

In D70606#1873185, @penzn wrote:

Expanding on my previous comment. In its current state yaml2obj is not aware of the section contents, and I think adding this functionality would be a bit more involved than the code we have in this review so far.

Quick rundown of what would be needed for yaml2obj change:

• Define YAML syntax for debug entries
• Support debug directory and its contents inside section mapping in ObjectYAML
  • Need to represent the structure from Debug section down to individual debug records
• Change other tests which depend on debug directory structure

We should probably discuss details. For example, can debug directory support in ObjectYAML take inspiration from LLD or would that make testing moot? Would ObjectYAML need any tests for this new functionality?

Do you mind if we move ObjectYAML discussion elsewhere? What would be a good place for it, llvm-dev?

As for this change, another option is to use yaml2obj, but output debug directory as a hex section in the YAML file. However this would inconsistent with codeview tests, maybe it would be better to change everything at once when yaml2obj is ready.

I'm not sure I really know enough about the intricacies here to provide good feedback. I do think splitting out any yaml2obj functionality into a separate change makes sense though. When it comes to using a hex section/adding yaml2obj support for that section type, my opinion is that if the section only needs to be a few bytes long, it's fine, but if it's more than that and the hex contents are essentially unreadable, then there's no benefit in using yaml2obj at all. If you want to continue the discussion separately, llvm-dev is probably the best place for it.

[penzn]

I've started the discussion on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2020-March/139706.html

@ruiu should we merge this change in the meantime? When yaml2obj change would happen it would be pretty straightforward to change the test introduced here.

[ruiu]

LGTM with this change.

As to how to test this, I'm fine with checking in a binary file until you extend yaml2obj so that the tool can produce an ExtendedDLLCharacterstics section. It isn't ideal but we already have a few binary files in our test suite.

lld/COFF/Writer.cpp

180

You should use write32le to guarantee that you are writing the four bytes in the little-endian order. Windows machines are all little-endian, but if you by any chance cross-build a Windows binary on a big-endian machine (e.g. creating an UEFI or Windows binary on PPC32BE using lld), this code would write a word in a wrong order. I believe there's a PPC big-endian bot, so this code would fail on the bot if you check this in as-is.

[penzn]

Use write32le to set extended DLL characteristics.

[penzn]

Another minor edit, I moved COFF test files for llvm-readobj to the directory where the rest of them are now.

In D70606#1904783, @ruiu wrote:

LGTM with this change.

As to how to test this, I'm fine with checking in a binary file until you extend yaml2obj so that the tool can produce an ExtendedDLLCharacterstics section. It isn't ideal but we already have a few binary files in our test suite.

Thank you! Made the change. I don't have commit rights, help with the merge will be greatly appreciated.

[jhenderson]

Looks like there's a lot of clang-format issues in this that need addressing before this gets committed?

[ruiu]

I tried to apply your patch to submit, but it looks like your test file (llvm/test/tools/llvm-readobj/COFF/Inputs/has_cet.exe) cannot be downloaded from Phabricator. Can you upload a file somewhere and send me the URL? Or you can encode with base64 and send it to me via email.

[penzn]

Formatting; also instructions on building test image.

base64 encoding attached, also made a gist for it: https://gist.github.com/penzn/0c512ba24f615b91c2bccbcc38bfd933

I am trying to attach unencoded file here as well, let's see if Phabricator would agree.

has_cet.exe91 KBDownload

has_cet.base64123 KBDownload

[MaskRay]

llvm/test/tools/llvm-readobj/COFF/cetcompat.test

4 ↗

(On Diff #250117)

We should avoid a checked-in binary if possible. Can't it be synthesized from a YAML file?

[ruiu]

That's discussed on llvm-dev, and I think that even though we should ideally extend
the tool to handle the new bit, it shouldn't block this patch. This patch adds a missing
flag that was added to MSVC link.exe recently.

[penzn]

I had to edit the comment above, looks like I took snapshot from directory when I was reproducing build instructions, instead of actual test directory. Now the exe and base64 encoding above (in the gist as well) are correct and the test should pass.

llvm/test/tools/llvm-readobj/COFF/cetcompat.test

4 ↗

(On Diff #250117)

Not at this stage, yaml2obj still needs work to support it. As @ruiu pointed out there is discussion on llvm-dev about making that change.

lld/COFF/Config.h

struct Configuration {
   uint32_t majorImageVersion = 0;
   uint32_t minorImageVersion = 0;
   uint32_t majorOSVersion = 6;
   uint32_t minorOSVersion = 0;
   uint32_t timestamp = 0;
   uint32_t functionPadMin = 0;
   bool dynamicBase = true;
   bool allowBind = true;
+  bool cetCompat = false;
   bool nxCompat = true;
   bool allowIsolation = true;
   bool terminalServerAware = true;
   bool largeAddressAware = false;
   bool highEntropyVA = false;
   bool appContainer = false;
   bool mingw = false;
   bool warnMissingOrderSymbol = true;

lld/COFF/Driver.cpp

void LinkerDriver::link(ArrayRef<const char *> argsArr) {
   config->allowIsolation =
       args.hasFlag(OPT_allowisolation, OPT_allowisolation_no, true);
   config->incremental =
       args.hasFlag(OPT_incremental, OPT_incremental_no,
                    !config->doGC && !config->doICF && !args.hasArg(OPT_order) &&
                        !args.hasArg(OPT_profile));
   config->integrityCheck =
       args.hasFlag(OPT_integritycheck, OPT_integritycheck_no, false);
+  config->cetCompat = args.hasFlag(OPT_cetcompat, OPT_cetcompat_no, false);
   config->nxCompat = args.hasFlag(OPT_nxcompat, OPT_nxcompat_no, true);
   for (auto *arg : args.filtered(OPT_swaprun))
     parseSwaprun(arg->getValue());
   config->terminalServerAware =
       !config->dll && args.hasFlag(OPT_tsaware, OPT_tsaware_no, true);
   config->debugDwarf = debug == DebugKind::Dwarf;
   config->debugGHashes = debug == DebugKind::GHash;
   config->debugSymtab = debug == DebugKind::Symtab;

lld/COFF/Options.td

 
 defm allowbind : B<"allowbind", "Enable DLL binding (default)",
                    "Disable DLL binding">;
 defm allowisolation : B<"allowisolation", "Enable DLL isolation (default)",
                         "Disable DLL isolation">;
 defm appcontainer : B<"appcontainer",
                       "Image can only be run in an app container",
                       "Image can run outside an app container (default)">;
+defm cetcompat : B<"cetcompat", "Mark executable image as compatible with Control-flow Enforcement Technology (CET) Shadow Stack",
+                  "Don't mark executable image as compatible with Control-flow Enforcement Technology (CET) Shadow Stack (default)">;
 defm dynamicbase : B<"dynamicbase", "Enable ASLR (default unless /fixed)",
                      "Disable ASLR (default when /fixed)">;
 defm fixed : B<"fixed", "Disable base relocations",
                "Enable base relocations (default)">;
 defm highentropyva : B<"highentropyva",
                        "Enable 64-bit ASLR (default on 64-bit)",
                        "Disable 64-bit ASLR">;
 defm incremental : B<"incremental",

lld/COFF/Writer.cpp

 OutputSection *Chunk::getOutputSection() const {
   return osidx == 0 ? nullptr : outputSections[osidx - 1];
 }
 
 namespace {
 
 class DebugDirectoryChunk : public NonSectionChunk {
 public:
-  DebugDirectoryChunk(const std::vector<Chunk *> &r, bool writeRepro)
+  DebugDirectoryChunk(const std::vector<std::pair<COFF::DebugType, Chunk *>> &r, bool writeRepro)
       : records(r), writeRepro(writeRepro) {}
 
   size_t getSize() const override {
     return (records.size() + int(writeRepro)) * sizeof(debug_directory);
   }
 
   void writeTo(uint8_t *b) const override {
     auto *d = reinterpret_cast<debug_directory *>(b);
 
-    for (const Chunk *record : records) {
-      OutputSection *os = record->getOutputSection();
-      uint64_t offs = os->getFileOff() + (record->getRVA() - os->getRVA());
-      fillEntry(d, COFF::IMAGE_DEBUG_TYPE_CODEVIEW, record->getSize(),
-                record->getRVA(), offs);
+    for (const std::pair<COFF::DebugType, Chunk *> record : records) {
+      Chunk *c = record.second;
+      OutputSection *os = c->getOutputSection();
+      uint64_t offs = os->getFileOff() + (c->getRVA() - os->getRVA());
+      fillEntry(d, record.first, c->getSize(),
+                c->getRVA(), offs);
       ++d;
     }
 
     if (writeRepro) {
       // FIXME: The COFF spec allows either a 0-sized entry to just say
       // "the timestamp field is really a hash", or a 4-byte size field
       // followed by that many bytes containing a longer hash (with the
       // lowest 4 bytes usually being the timestamp in little-endian order).
void fillEntry(debug_directory *d, COFF::DebugType debugType, size_t size,
     d->SizeOfData = size;
     d->AddressOfRawData = rva;
     d->PointerToRawData = offs;
 
     timeDateStamps.push_back(&d->TimeDateStamp);
   }
 
   mutable std::vector<support::ulittle32_t *> timeDateStamps;
-  const std::vector<Chunk *> &records;
+  const std::vector<std::pair<COFF::DebugType, Chunk *>> &records;
   bool writeRepro;
 };
 
 class CVDebugRecordChunk : public NonSectionChunk {
 public:
   size_t getSize() const override {
     return sizeof(codeview::DebugInfo) + config->pdbAltPath.size() + 1;
   }
 
   void writeTo(uint8_t *b) const override {
     // Save off the DebugInfo entry to backfill the file signature (build id)
     // in Writer::writeBuildId
     buildId = reinterpret_cast<codeview::DebugInfo *>(b);
 
     // variable sized field (PDB Path)
     char *p = reinterpret_cast<char *>(b + sizeof(*buildId));
     if (!config->pdbAltPath.empty())
       memcpy(p, config->pdbAltPath.data(), config->pdbAltPath.size());
     p[config->pdbAltPath.size()] = '\0';
   }
 
   mutable codeview::DebugInfo *buildId = nullptr;
 };
 
+class ExtendedDllCharacteristicsChunk : public NonSectionChunk {
+public:
+  ExtendedDllCharacteristicsChunk(unsigned C)
+      : Characteristics(C) {}
+
+  size_t getSize() const override {
+    return sizeof(Characteristics);
+  }
+
+  void writeTo(uint8_t *B) const override {
+    memcpy(B, &Characteristics, sizeof(ExtendedDLLCharacteristics));
+  }
+
+  uint32_t Characteristics = 0;
+};
+
 // PartialSection represents a group of chunks that contribute to an
 // OutputSection. Collating a collection of PartialSections of same name and
 // characteristics constitutes the OutputSection.
 class PartialSectionKey {
 public:
   StringRef name;
   unsigned characteristics;
 
private:
   Chunk *edataEnd = nullptr;
   Chunk *iatStart = nullptr;
   uint64_t iatSize = 0;
   DelayLoadContents delayIdata;
   EdataContents edata;
   bool setNoSEHCharacteristic = false;
 
   DebugDirectoryChunk *debugDirectory = nullptr;
-  std::vector<Chunk *> debugRecords;
+  std::vector<std::pair<COFF::DebugType, Chunk *>> debugRecords;
   CVDebugRecordChunk *buildId = nullptr;
   ArrayRef<uint8_t> sectionTable;
 
   uint64_t fileSize;
   uint32_t pointerToSymbolTable = 0;
   uint64_t sizeOfImage;
   uint64_t sizeOfHeaders;
 
void Writer::createMiscChunks() {
   // Create thunks for locally-dllimported symbols.
   if (!symtab->localImportChunks.empty()) {
     for (Chunk *c : symtab->localImportChunks)
       rdataSec->addChunk(c);
   }
 
   // Create Debug Information Chunks
   OutputSection *debugInfoSec = config->mingw ? buildidSec : rdataSec;
-  if (config->debug || config->repro) {
+  if (config->debug || config->repro || config->cetCompat) {
     debugDirectory = make<DebugDirectoryChunk>(debugRecords, config->repro);
+    debugDirectory->setAlignment(4);
     debugInfoSec->addChunk(debugDirectory);
   }
 
   if (config->debug) {
     // Make a CVDebugRecordChunk even when /DEBUG:CV is not specified.  We
     // output a PDB no matter what, and this chunk provides the only means of
     // allowing a debugger to match a PDB and an executable.  So we need it even
     // if we're ultimately not going to write CodeView data to the PDB.
     buildId = make<CVDebugRecordChunk>();
-    debugRecords.push_back(buildId);
+    debugRecords.push_back({COFF::IMAGE_DEBUG_TYPE_CODEVIEW, buildId});
+  }
+
+  if (config->cetCompat) {
+    ExtendedDllCharacteristicsChunk *extendedDllChars = make<ExtendedDllCharacteristicsChunk>(IMAGE_DLL_CHARACTERISTICS_EX_CET_COMPAT);
+    debugRecords.push_back({COFF::IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS, extendedDllChars});
+  }
 
-    for (Chunk *c : debugRecords)
-      debugInfoSec->addChunk(c);
+  if (debugRecords.size() > 0) {
+    for (std::pair<COFF::DebugType, Chunk *> r : debugRecords)
+      debugInfoSec->addChunk(r.second);
   }
 
   // Create SEH table. x86-only.
   if (config->safeSEH)
     createSEHTable();
 
   // Create /guard:cf tables if requested.
   if (config->guardCF != GuardCFLevel::Off)

lld/test/COFF/options.test

 # RUN: lld-link /out:%t.exe /entry:main /nxcompat %t.obj
 # RUN: llvm-readobj --file-headers %t.exe | FileCheck -check-prefix=NXCOMPAT %s
 NXCOMPAT: IMAGE_DLL_CHARACTERISTICS_NX_COMPAT
 
 # RUN: lld-link /out:%t.exe /nxcompat:no /out:%t.exe /entry:main %t.obj
 # RUN: llvm-readobj --file-headers %t.exe | FileCheck -check-prefix=NONXCOMPAT %s
 NONXCOMPAT-NOT: IMAGE_DLL_CHARACTERISTICS_NX_COMPAT
 
+# RUN: lld-link /out:%t.exe /entry:main /cetcompat %t.obj
+# RUN: llvm-readobj --coff-debug-directory %t.exe | FileCheck -check-prefix=CETCOMPAT %s
+CETCOMPAT: IMAGE_DLL_CHARACTERISTICS_EX_CET_COMPAT
+
+# RUN: lld-link /out:%t.exe /entry:main %t.obj
+# RUN: llvm-readobj --coff-debug-directory %t.exe | FileCheck -check-prefix=NONCETCOMPAT %s
+# RUN: lld-link /out:%t.exe /entry:main /cetcompat:no %t.obj
+# RUN: llvm-readobj --coff-debug-directory %t.exe | FileCheck -check-prefix=NONCETCOMPAT %s
+NONCETCOMPAT-NOT: IMAGE_DLL_CHARACTERISTICS_EX_CET_COMPAT
+
 # RUN: lld-link /out:%t.exe /entry:main /swaprun:CD %t.obj
 # RUN: llvm-readobj --file-headers %t.exe | FileCheck -check-prefix=SWAPCD %s
 # RUN: lld-link /out:%t.exe /entry:main /swaprun:cd,net %t.obj
 # RUN: llvm-readobj --file-headers %t.exe | FileCheck -check-prefix=SWAPCD %s
 SWAPCD: IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP
 
 # RUN: lld-link /out:%t.exe /entry:main %t.obj
 # RUN: llvm-readobj --file-headers %t.exe | FileCheck -check-prefix=NOSWAPCD %s

llvm/include/llvm/BinaryFormat/COFF.h

enum DLLCharacteristics : unsigned {
   ///< A WDM driver.
   IMAGE_DLL_CHARACTERISTICS_WDM_DRIVER = 0x2000,
   ///< Image supports Control Flow Guard.
   IMAGE_DLL_CHARACTERISTICS_GUARD_CF = 0x4000,
   /// Terminal Server aware.
   IMAGE_DLL_CHARACTERISTICS_TERMINAL_SERVER_AWARE = 0x8000
 };
 
+enum ExtendedDLLCharacteristics : unsigned {
+  /// Image is CET compatible
+  IMAGE_DLL_CHARACTERISTICS_EX_CET_COMPAT = 0x0001
+};
+
 enum DebugType : unsigned {
   IMAGE_DEBUG_TYPE_UNKNOWN = 0,
   IMAGE_DEBUG_TYPE_COFF = 1,
   IMAGE_DEBUG_TYPE_CODEVIEW = 2,
   IMAGE_DEBUG_TYPE_FPO = 3,
   IMAGE_DEBUG_TYPE_MISC = 4,
   IMAGE_DEBUG_TYPE_EXCEPTION = 5,
   IMAGE_DEBUG_TYPE_FIXUP = 6,
   IMAGE_DEBUG_TYPE_OMAP_TO_SRC = 7,
   IMAGE_DEBUG_TYPE_OMAP_FROM_SRC = 8,
   IMAGE_DEBUG_TYPE_BORLAND = 9,
   IMAGE_DEBUG_TYPE_RESERVED10 = 10,
   IMAGE_DEBUG_TYPE_CLSID = 11,
   IMAGE_DEBUG_TYPE_VC_FEATURE = 12,
   IMAGE_DEBUG_TYPE_POGO = 13,
   IMAGE_DEBUG_TYPE_ILTCG = 14,
   IMAGE_DEBUG_TYPE_MPX = 15,
   IMAGE_DEBUG_TYPE_REPRO = 16,
+  IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS = 20,
 };
 
 enum BaseRelocationType : unsigned {
   IMAGE_REL_BASED_ABSOLUTE = 0,
   IMAGE_REL_BASED_HIGH = 1,
   IMAGE_REL_BASED_LOW = 2,
   IMAGE_REL_BASED_HIGHLOW = 3,
   IMAGE_REL_BASED_HIGHADJ = 4,

llvm/test/tools/llvm-readobj/coff-cet-compat.test

+RUN: llvm-readobj --coff-debug-directory %p/Inputs/has_cet.exe | FileCheck %s
+
+CHECK:  DebugEntry {
+CHECK:    Characteristics: 0x0
+CHECK:    TimeDateStamp: 2019-06-20 20:45:09 (0x5D0BF055)
+CHECK:    MajorVersion: 0x0
+CHECK:    MinorVersion: 0x0
+CHECK:    Type: ExtendedDLLCharacteristics (0x14)
+CHECK:    SizeOfData: 0x4
+CHECK:    AddressOfRawData: 0x146A8
+CHECK:    PointerToRawData: 0x138A8
+CHECK:    ExtendedCharacteristics [ (0x1)
+CHECK:      IMAGE_DLL_CHARACTERISTICS_EX_CET_COMPAT (0x1)
+CHECK:    ]
+CHECK:    RawData (
+CHECK:      0000: 01000000                             |....|
+CHECK:    )
+CHECK:  }
+

llvm/tools/llvm-readobj/COFFDumper.cpp

static const EnumEntry<COFF::DLLCharacteristics> PEDLLCharacteristics[] = {
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_DLL_CHARACTERISTICS_NO_SEH               ),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_DLL_CHARACTERISTICS_NO_BIND              ),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_DLL_CHARACTERISTICS_APPCONTAINER         ),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_DLL_CHARACTERISTICS_WDM_DRIVER           ),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_DLL_CHARACTERISTICS_GUARD_CF             ),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_DLL_CHARACTERISTICS_TERMINAL_SERVER_AWARE),
 };
 
+static const EnumEntry<COFF::ExtendedDLLCharacteristics> PEExtendedDLLCharacteristics[] = {
+  LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_DLL_CHARACTERISTICS_EX_CET_COMPAT),
+};
+
 static const EnumEntry<COFF::SectionCharacteristics>
 ImageSectionCharacteristics[] = {
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_SCN_TYPE_NOLOAD           ),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_SCN_TYPE_NO_PAD           ),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_SCN_CNT_CODE              ),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_SCN_CNT_INITIALIZED_DATA  ),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_SCN_CNT_UNINITIALIZED_DATA),
   LLVM_READOBJ_ENUM_ENT(COFF, IMAGE_SCN_LNK_OTHER             ),
static const EnumEntry<COFF::COMDATType> ImageCOMDATSelect[] = {
   { "SameSize"    , COFF::IMAGE_COMDAT_SELECT_SAME_SIZE    },
   { "ExactMatch"  , COFF::IMAGE_COMDAT_SELECT_EXACT_MATCH  },
   { "Associative" , COFF::IMAGE_COMDAT_SELECT_ASSOCIATIVE  },
   { "Largest"     , COFF::IMAGE_COMDAT_SELECT_LARGEST      },
   { "Newest"      , COFF::IMAGE_COMDAT_SELECT_NEWEST       }
 };
 
 static const EnumEntry<COFF::DebugType> ImageDebugType[] = {
-  { "Unknown"    , COFF::IMAGE_DEBUG_TYPE_UNKNOWN       },
-  { "COFF"       , COFF::IMAGE_DEBUG_TYPE_COFF          },
-  { "CodeView"   , COFF::IMAGE_DEBUG_TYPE_CODEVIEW      },
-  { "FPO"        , COFF::IMAGE_DEBUG_TYPE_FPO           },
-  { "Misc"       , COFF::IMAGE_DEBUG_TYPE_MISC          },
-  { "Exception"  , COFF::IMAGE_DEBUG_TYPE_EXCEPTION     },
-  { "Fixup"      , COFF::IMAGE_DEBUG_TYPE_FIXUP         },
-  { "OmapToSrc"  , COFF::IMAGE_DEBUG_TYPE_OMAP_TO_SRC   },
-  { "OmapFromSrc", COFF::IMAGE_DEBUG_TYPE_OMAP_FROM_SRC },
-  { "Borland"    , COFF::IMAGE_DEBUG_TYPE_BORLAND       },
-  { "Reserved10" , COFF::IMAGE_DEBUG_TYPE_RESERVED10    },
-  { "CLSID"      , COFF::IMAGE_DEBUG_TYPE_CLSID         },
-  { "VCFeature"  , COFF::IMAGE_DEBUG_TYPE_VC_FEATURE    },
-  { "POGO"       , COFF::IMAGE_DEBUG_TYPE_POGO          },
-  { "ILTCG"      , COFF::IMAGE_DEBUG_TYPE_ILTCG         },
-  { "MPX"        , COFF::IMAGE_DEBUG_TYPE_MPX           },
-  { "Repro"      , COFF::IMAGE_DEBUG_TYPE_REPRO         },
+  { "Unknown"             , COFF::IMAGE_DEBUG_TYPE_UNKNOWN                     },
+  { "COFF"                , COFF::IMAGE_DEBUG_TYPE_COFF                        },
+  { "CodeView"            , COFF::IMAGE_DEBUG_TYPE_CODEVIEW                    },
+  { "FPO"                 , COFF::IMAGE_DEBUG_TYPE_FPO                         },
+  { "Misc"                , COFF::IMAGE_DEBUG_TYPE_MISC                        },
+  { "Exception"           , COFF::IMAGE_DEBUG_TYPE_EXCEPTION                   },
+  { "Fixup"               , COFF::IMAGE_DEBUG_TYPE_FIXUP                       },
+  { "OmapToSrc"           , COFF::IMAGE_DEBUG_TYPE_OMAP_TO_SRC                 },
+  { "OmapFromSrc"         , COFF::IMAGE_DEBUG_TYPE_OMAP_FROM_SRC               },
+  { "Borland"             , COFF::IMAGE_DEBUG_TYPE_BORLAND                     },
+  { "Reserved10"          , COFF::IMAGE_DEBUG_TYPE_RESERVED10                  },
+  { "CLSID"               , COFF::IMAGE_DEBUG_TYPE_CLSID                       },
+  { "VCFeature"           , COFF::IMAGE_DEBUG_TYPE_VC_FEATURE                  },
+  { "POGO"                , COFF::IMAGE_DEBUG_TYPE_POGO                        },
+  { "ILTCG"               , COFF::IMAGE_DEBUG_TYPE_ILTCG                       },
+  { "MPX"                 , COFF::IMAGE_DEBUG_TYPE_MPX                         },
+  { "Repro"               , COFF::IMAGE_DEBUG_TYPE_REPRO                       },
+  { "ExtendedDLLCharacteristics", COFF::IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS },
 };
 
 static const EnumEntry<COFF::WeakExternalCharacteristics>
 WeakExternalCharacteristics[] = {
   { "NoLibrary", COFF::IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY },
   { "Library"  , COFF::IMAGE_WEAK_EXTERN_SEARCH_LIBRARY   },
   { "Alias"    , COFF::IMAGE_WEAK_EXTERN_SEARCH_ALIAS     }
 };
if (D.Type == COFF::IMAGE_DEBUG_TYPE_CODEVIEW) {
       DictScope PDBScope(W, "PDBInfo");
       W.printHex("PDBSignature", DebugInfo->Signature.CVSignature);
       if (DebugInfo->Signature.CVSignature == OMF::Signature::PDB70) {
         W.printBinary("PDBGUID", makeArrayRef(DebugInfo->PDB70.Signature));
         W.printNumber("PDBAge", DebugInfo->PDB70.Age);
         W.printString("PDBFileName", PDBFileName);
       }
     } else if (D.SizeOfData != 0) {
-      // FIXME: Type values of 12 and 13 are commonly observed but are not in
-      // the documented type enum.  Figure out what they mean.
+      // FIXME: Data visualization for IMAGE_DEBUG_TYPE_VC_FEATURE and
+      // IMAGE_DEBUG_TYPE_POGO?
       ArrayRef<uint8_t> RawData;
       if (std::error_code EC = Obj->getRvaAndSizeAsBytes(D.AddressOfRawData,
                                                          D.SizeOfData, RawData))
         reportError(errorCodeToError(EC), Obj->getFileName());
+      if (D.Type == COFF::IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS) {
+        // FIXME right now the only possible value would fit in 8 bits, but that might change in the future
+        uint16_t Characteristics = RawData[0];
+        W.printFlags ("ExtendedCharacteristics", Characteristics, makeArrayRef(PEExtendedDLLCharacteristics));
+      }
       W.printBinaryBlock("RawData", RawData);
     }
   }
 }
 
 void COFFDumper::printRVATable(uint64_t TableVA, uint64_t Count,
                                uint64_t EntrySize, PrintExtraCB PrintExtra) {
   uintptr_t TableStart, TableEnd;