anti-debugging | debugging techniques | Code Inspection library

Intel is pretty clear about it:

An attempt to read or write the debug registers from any other privilege level generates a general-protection exception (#GP).

So reading or writing a debug register when not running at CPL 0 will raise an exception, independently of the GD flag.

In fact, I've analyzed quite a bit of malwares and none of them access the debug registers directly. They get the current thread context (GetThreadContext or NtGetContextThread or similar WOW64 variants) and check the values of the debug registers from there, note that it is the Windows' kernel that read the debug register in this case. This antidebug trick can be worked around manually (with a breakpoint on the API retrieving the context) or with a debugger plugin. Malwares running at CPL 0 could use the GD flag but I've never found one so far.

Answering your title question, any read or write access (at CPL 0) to a debug register will raise a #GP if GD is set. I have not tested it but considering its intended use (to support hardware debugger emulator), the idea is to "virtualize" the debug registers. The hardware debugger emulated in software can then use the debug register even if the OS debugged is already using them. This is done by faulting on every access and properly swapping in and out the OS vs emulator values.

If only writes were faulting the emulator could not prevent the debugged OS from reading an incorrect value (placed there by the emulator) from a debug register.

Enables (when set) debug-register protection, which causes a debug exception to be generated prior to any MOV instruction that accesses a debug register.
When such a condition is detected, the BD flag in debug status register DR6 is set prior to generating the exception. This condition is provided to support in-circuit emulators. When the emulator needs to access the debug registers, emulator software can set the GD flag to prevent interference from the program currently executing on the processor.
The processor clears the GD flag upon entering to the debug exception handler, to allow the handler access to the debug registers.

This is the defacto antidebug reference by Peter Ferrie, it's an amazing resource: https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf

It contains almost every known anti-debug method, you can use this reference and tick each method off your list until you find the ones that are implemented, the book should also help you easily mitigate each method as well.

Per our conversation in the comments, the answer to your question was that the process was hooking both DbgBreakPoint and DbgUiRemoteBreakig. Patching them enabled you to then attach a debugger.