Problems when building NT kernel drivers with GCC / LD

Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

Hello!

I tried to develop simple NT kernel driver and build it via GNU GCC, LD
and mingw-w64 ecosystem but due to issues with compiler and linker, it
is not possible to generate final .sys binary without adding workarounds
or postprocessing resulted PE .sys binary.

I'm sending this email to all parties (binutils = linker, gcc = compiler,
mingw-w64 = runtime) which are involved in building process of NT kernel
driver (which is just native PE binary) and I would like to describe
existing issues and ask if you can come up with fixes.

For demonstration I created very simple NT kernel driver which can be
compiled by MSVC compiler without any issues, so you can directly look
at the code and play with it: https://github.com/pali/secure-giveio
I have there also GNUmakefile which uses GNU tools for compilation and
tries to workaround issues.

Here is the list of those GCC / LD issues which I observed during
development and compilation of NT kernel drivers:

* GCC does not support __declspec(code_seg("segname")) declarator for
  specifying name of PE/COFF segment name. But instead GCC supports
  different syntax __declspec(section("segname")) for this thing.

  I thought that GCC added __declspec support for compatibility with
  other PE/COFF compilers. But because declarators are different it just
  means that __declspec segment name is not compatible neither with MSVC.

  If the GCC's intention of __declspec is compatibility support then it
  would be really really useful to have support for __declspec(code_seg
  instead of custom __declspec(section syntax supported only by GCC.

  As a workaround to have driver compilable by both MSVC and GCC it is
  needed to add #ifdef for GCC compiler.

* LD --dynamicbase is not working correctly. If used for PE executables
  (not dynamic libraries) then it does *not* generate relocation info.
  And without relocation info in PE binary, it is not possible to
  relocate base address. Which makes dynamic base non-working.

  As a workaround GCC -pie can be used to generate relocation info (but
  it is buggy too, see below).

* GCC -pie is unusable. It automatically generates export symbol table
  even when PE binary must not export anything. This applies for Native
  PE executables used as NT kernel .sys drivers. Normally only dynamic
  libraries export symbols, so by default for executables should not
  symbol table. Or at least there should be a flag which can disable
  doing it.

  I tried to workaround it via LD --exclude-all-symbols, but it is also
  not usable, see below.

* LD --exclude-all-symbols has issues for Native PE executables. It
  causes generation of empty export table and puts name of the output
  executable/driver (-o) as name of the export library. PE executables
  which are in shared address space (e.g. NT driver executables) should
  really do not be treated as libraries with library name (unless
  explicitly asked for such thing).

  As a workaround I had to create a custom linker script which discards
  that nonsense export table by completely dropping .edata section.

* LD puts discardable init sections in the middle of the PE binary. This
  is really stupid as loaded PE binary waste memory space. Discardable
  init sections should be at the end of the PE binary.

  As a workaround I used custom linker script.

* GCC or LD (not sure who) sets memory alignment characteristics
  (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
  These characteristics should be only in COFF object files, not
  executable binaries. Specially they should not be in NT kernel
  drivers.

* GCC or LD (not sure who) sets data characteristics
  (IMAGE_SCN_CNT_INITIALIZED_DATA) for executable PE code sections.
  Code sections should not be really marked as data, only as a code
  (IMAGE_SCN_CNT_CODE).

* GCC or LD (not sure who) sets memory writable characteristics
  (IMAGE_SCN_MEM_WRITE) into the read-only resources PE sections.
  Read-only sections of final PE executable really should not marked as
  writable.

* GCC or LD (not sure who) does *not* set memory discardable
  characteristic (IMAGE_SCN_MEM_DISCARDABLE) for sections used only
  during initial phase in NT kernel driver PE executables. This applies
  for .idata, INIT and .rsrc sections. Without that characteristic there
  is wasting of kernel memory.

* GCC or LD (not sure who) does *not* set memory not_paged
  characteristics (IMAGE_SCN_MEM_NOT_PAGED) for PE sections which must
  not be paged in NT kernel driver executables. Basically most sections
  should must not be paged unless explicitly asked/marked. By default
  just section with name PAGE could be paged and therefore only this
  section does not have to have IMAGE_SCN_MEM_NOT_PAGED.

Last five issues I was not able to workaround neither via gcc or ld
flags and neither via linker script. For example MSVC link.exe linker
has switch /SECTION: which can be used to specify above characteristics
specific section. But whatever I tried to do in GNU linker script, I was
not able to set and fix those characteristics. For this reason I wrote
custom application which post-process built PE executable and fix
section characteristics, which GNU GCC/LD generated incorrectly.

Then I have there rather small but sometimes annoying objcopy issue.
objcopy does not respect --disable-deterministic-archives or
--preserve-dates switches and always deletes PE date/timestamp from
executable. I was not able to find any switch which can tell objcopy to
preserve PE date/timestamp. LD has flag --insert-timestamp for this
thing, and this LD switch is working.


Could you please look at those issues? Is there something which can be
done to fix them? Because it is really stop-blocker for building even
simple NT kernel drivers via open source GNU tools. Basically one main
problem - generate relocation info for native executable - just reveal
chain of other issues.

NT kernel .sys drivers are just simple Native PE executables (like
ordinary .exe executables) but with relocation info (like .dll
libraries) with fixed entry point, linked to ntoskrnl and have some
characteristics.

Following gcc flags produce such executable (but with above issues):

  -Wl,--subsystem,native
  -Wl,--dynamicbase -Wl,--nxcompat
  -Wl,--image-base,0x10000 -Wl,--stack,0x40000
  -Wl,--section-alignment,0x1000 -Wl,--file-alignment,0x200
  -Wl,--disable-auto-import -Wl,--disable-stdcall-fixup
  -nostartfiles -nodefaultlibs -nostdlib
  -lntoskrnl

Note that entry point is always stdcall "DriverEntry" function. And
because of symbol mangling, its symbol name is "_DriverEntry@8" for IX86
and "DriverEntry" for AMD64. LD switch --entry= takes symbol name, not
function name. So it would be a nice feature to allow specifying entry
point via GCC/LD also as function name (without mangling) to have just

  -Wl,--entry=DriverEntry

parameter for gcc for all 32-bit and 64-bit builds.

And also it would be a nice to have some GCC flag which sets all above
flags required for compiling NT kernel driver. Like there is -mdll for
compiling DLL libraries or -mwindows for generating GUI WIN32
executables. For example MSVC link.exe has for this switch /DRIVER.

If you have some questions then please let me know. I think that it
would be really useful if GNU tools would be able to build NT kernel
drivers without needs for hacks.

Re: [Mingw-w64-public] Problems when building NT kernel drivers with GCC / LD

[Martin Storsjö]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Sun, 30 Oct 2022, Pali Rohár wrote:

> * LD --dynamicbase is not working correctly. If used for PE executables
>  (not dynamic libraries) then it does *not* generate relocation info.
>  And without relocation info in PE binary, it is not possible to
>  relocate base address. Which makes dynamic base non-working.

I don't know about the rest, but this one sounds familiar to me. But IIRC 
this one was fixed semi-recently (1-2 years ago), while making 
--dynamicbase the default.

I think it was fixed in this binutils commit:

commit 514b4e191d5f46de8e142fe216e677a35fa9c4bb
Author: Jeremy Drake <sourceware-bugzilla@jdrake.com>
Date:   Thu Aug 27 12:58:27 2020 +0100

     Change the default characteristics of DLLs built by the linker to more 
secure settings.

This commit is included in binutils 2.36 and later.

// Martin

Re: [Mingw-w64-public] Problems when building NT kernel drivers with GCC / LD

[ralph engels]

i think most of it stems from binutils tools being geared towards linux 
driver development ? and since noone before has shown much interrest in 
developing drivers for windows using the gnu tools. I also think that 
there might be some pitfalls -> incompatible exception models for one 
(most mingw based compilers today use dwarf unwinders for 32 bit maybe a 
few who use sjlj) the problem with that is that atleast 32 bit windows 
cannot do anything with this exception model sjlj is a little better in 
that regard but still. If done in pure C or asm it could work if those 
options were avaliable but it does limit the scope i think.

Den 30-10-2022 kl. 08:06 skrev Martin Storsjö:
> On Sun, 30 Oct 2022, Pali Rohár wrote:
>
>> * LD --dynamicbase is not working correctly. If used for PE executables
>>  (not dynamic libraries) then it does *not* generate relocation info.
>>  And without relocation info in PE binary, it is not possible to
>>  relocate base address. Which makes dynamic base non-working.
>
> I don't know about the rest, but this one sounds familiar to me. But 
> IIRC this one was fixed semi-recently (1-2 years ago), while making 
> --dynamicbase the default.
>
> I think it was fixed in this binutils commit:
>
> commit 514b4e191d5f46de8e142fe216e677a35fa9c4bb
> Author: Jeremy Drake <sourceware-bugzilla@jdrake.com>
> Date:   Thu Aug 27 12:58:27 2020 +0100
>
>     Change the default characteristics of DLLs built by the linker to 
> more secure settings.
>
> This commit is included in binutils 2.36 and later.
>
> // Martin
>
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: Problems when building NT kernel drivers with GCC / LD

[Jan Beulich]

On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
> * GCC or LD (not sure who) sets memory alignment characteristics
>   (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
>   These characteristics should be only in COFF object files, not
>   executable binaries. Specially they should not be in NT kernel
>   drivers.

Like Martin pointed out in reply for another item, I'm pretty sure
this one was taken care of in bfd already (and iirc is in 2.39). You
fail to mention at all what versions of the various components you
use. I guess before reporting such a long list of issue you would
have wanted to test at least with the most recent releases of each
of the involved components. I wouldn't exclude some further items
could then be scratched off your list.

Jan

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

On Monday 31 October 2022 10:55:59 Jan Beulich wrote:
> On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
> > * GCC or LD (not sure who) sets memory alignment characteristics
> >   (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
> >   These characteristics should be only in COFF object files, not
> >   executable binaries. Specially they should not be in NT kernel
> >   drivers.
> 
> Like Martin pointed out in reply for another item, I'm pretty sure
> this one was taken care of in bfd already (and iirc is in 2.39). You
> fail to mention at all what versions of the various components you
> use.

Ou, sorry for that. I take care to write issues in all details and
totally forgot to write such important information like tool versions.

Now I retested all issues on Debian 11 which has LD 2.35.2 and GCC
10.2.1 and all issues are there still valid except data characteristic
IMAGE_SCN_CNT_INITIALIZED_DATA for code sections IMAGE_SCN_CNT_CODE.

I can easily retest it with LD 2.39 and GCC 10.3.0 which is in Debian
testing.

> I guess before reporting such a long list of issue you would
> have wanted to test at least with the most recent releases of each
> of the involved components. I wouldn't exclude some further items
> could then be scratched off your list.
> 
> Jan

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

On Saturday 05 November 2022 01:57:49 Pali Rohár wrote:
> On Monday 31 October 2022 10:55:59 Jan Beulich wrote:
> > On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
> > > * GCC or LD (not sure who) sets memory alignment characteristics
> > >   (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
> > >   These characteristics should be only in COFF object files, not
> > >   executable binaries. Specially they should not be in NT kernel
> > >   drivers.
> > 
> > Like Martin pointed out in reply for another item, I'm pretty sure
> > this one was taken care of in bfd already (and iirc is in 2.39). You
> > fail to mention at all what versions of the various components you
> > use.
> 
> Ou, sorry for that. I take care to write issues in all details and
> totally forgot to write such important information like tool versions.
> 
> Now I retested all issues on Debian 11 which has LD 2.35.2 and GCC
> 10.2.1 and all issues are there still valid except data characteristic
> IMAGE_SCN_CNT_INITIALIZED_DATA for code sections IMAGE_SCN_CNT_CODE.
> 
> I can easily retest it with LD 2.39 and GCC 10.3.0 which is in Debian
> testing.

Retested with LD 2.39 and GCC 10.3.0 which is in Debian testing and
following problems are additionally fixed: --exclude-all-symbols,
--dynamicbase and IMAGE_SCN_ALIGN_MASK (which you mentioned above). All
other still reminds.

Do you need some other information?

> > I guess before reporting such a long list of issue you would
> > have wanted to test at least with the most recent releases of each
> > of the involved components. I wouldn't exclude some further items
> > could then be scratched off your list.
> > 
> > Jan

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

On Saturday 05 November 2022 02:26:52 Pali Rohár wrote:
> On Saturday 05 November 2022 01:57:49 Pali Rohár wrote:
> > On Monday 31 October 2022 10:55:59 Jan Beulich wrote:
> > > On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
> > > > * GCC or LD (not sure who) sets memory alignment characteristics
> > > >   (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
> > > >   These characteristics should be only in COFF object files, not
> > > >   executable binaries. Specially they should not be in NT kernel
> > > >   drivers.
> > > 
> > > Like Martin pointed out in reply for another item, I'm pretty sure
> > > this one was taken care of in bfd already (and iirc is in 2.39). You
> > > fail to mention at all what versions of the various components you
> > > use.
> > 
> > Ou, sorry for that. I take care to write issues in all details and
> > totally forgot to write such important information like tool versions.
> > 
> > Now I retested all issues on Debian 11 which has LD 2.35.2 and GCC
> > 10.2.1 and all issues are there still valid except data characteristic
> > IMAGE_SCN_CNT_INITIALIZED_DATA for code sections IMAGE_SCN_CNT_CODE.
> > 
> > I can easily retest it with LD 2.39 and GCC 10.3.0 which is in Debian
> > testing.
> 
> Retested with LD 2.39 and GCC 10.3.0 which is in Debian testing and
> following problems are additionally fixed: --exclude-all-symbols,
> --dynamicbase and IMAGE_SCN_ALIGN_MASK (which you mentioned above). All
> other still reminds.
> 
> Do you need some other information?

Hello! I would like to ask if you need some other details or something
else for these issues.

> > > I guess before reporting such a long list of issue you would
> > > have wanted to test at least with the most recent releases of each
> > > of the involved components. I wouldn't exclude some further items
> > > could then be scratched off your list.
> > > 
> > > Jan

Re: Problems when building NT kernel drivers with GCC / LD

[Jan Beulich]

On 20.11.2022 14:10, Pali Rohár wrote:
> On Saturday 05 November 2022 02:26:52 Pali Rohár wrote:
>> On Saturday 05 November 2022 01:57:49 Pali Rohár wrote:
>>> On Monday 31 October 2022 10:55:59 Jan Beulich wrote:
>>>> On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
>>>>> * GCC or LD (not sure who) sets memory alignment characteristics
>>>>>   (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
>>>>>   These characteristics should be only in COFF object files, not
>>>>>   executable binaries. Specially they should not be in NT kernel
>>>>>   drivers.
>>>>
>>>> Like Martin pointed out in reply for another item, I'm pretty sure
>>>> this one was taken care of in bfd already (and iirc is in 2.39). You
>>>> fail to mention at all what versions of the various components you
>>>> use.
>>>
>>> Ou, sorry for that. I take care to write issues in all details and
>>> totally forgot to write such important information like tool versions.
>>>
>>> Now I retested all issues on Debian 11 which has LD 2.35.2 and GCC
>>> 10.2.1 and all issues are there still valid except data characteristic
>>> IMAGE_SCN_CNT_INITIALIZED_DATA for code sections IMAGE_SCN_CNT_CODE.
>>>
>>> I can easily retest it with LD 2.39 and GCC 10.3.0 which is in Debian
>>> testing.
>>
>> Retested with LD 2.39 and GCC 10.3.0 which is in Debian testing and
>> following problems are additionally fixed: --exclude-all-symbols,
>> --dynamicbase and IMAGE_SCN_ALIGN_MASK (which you mentioned above). All
>> other still reminds.
>>
>> Do you need some other information?
> 
> Hello! I would like to ask if you need some other details or something
> else for these issues.

Well, generally speaking it might help if you could provide smallish
testcases for every item individually. But then, with you replying to
me specifically, perhaps you're wrongly assuming that I would be
planning to look into addressing any or all of these? My earlier reply
was merely to point out that _some_ work has already been done ...

Jan

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
> On 20.11.2022 14:10, Pali Rohár wrote:
> > On Saturday 05 November 2022 02:26:52 Pali Rohár wrote:
> >> On Saturday 05 November 2022 01:57:49 Pali Rohár wrote:
> >>> On Monday 31 October 2022 10:55:59 Jan Beulich wrote:
> >>>> On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
> >>>>> * GCC or LD (not sure who) sets memory alignment characteristics
> >>>>>   (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
> >>>>>   These characteristics should be only in COFF object files, not
> >>>>>   executable binaries. Specially they should not be in NT kernel
> >>>>>   drivers.
> >>>>
> >>>> Like Martin pointed out in reply for another item, I'm pretty sure
> >>>> this one was taken care of in bfd already (and iirc is in 2.39). You
> >>>> fail to mention at all what versions of the various components you
> >>>> use.
> >>>
> >>> Ou, sorry for that. I take care to write issues in all details and
> >>> totally forgot to write such important information like tool versions.
> >>>
> >>> Now I retested all issues on Debian 11 which has LD 2.35.2 and GCC
> >>> 10.2.1 and all issues are there still valid except data characteristic
> >>> IMAGE_SCN_CNT_INITIALIZED_DATA for code sections IMAGE_SCN_CNT_CODE.
> >>>
> >>> I can easily retest it with LD 2.39 and GCC 10.3.0 which is in Debian
> >>> testing.
> >>
> >> Retested with LD 2.39 and GCC 10.3.0 which is in Debian testing and
> >> following problems are additionally fixed: --exclude-all-symbols,
> >> --dynamicbase and IMAGE_SCN_ALIGN_MASK (which you mentioned above). All
> >> other still reminds.
> >>
> >> Do you need some other information?
> > 
> > Hello! I would like to ask if you need some other details or something
> > else for these issues.
> 
> Well, generally speaking it might help if you could provide smallish
> testcases for every item individually.

I have already provided simple test case - simple driver - it is linked
in the first email.

> But then, with you replying to
> me specifically, perhaps you're wrongly assuming that I would be
> planning to look into addressing any or all of these? My earlier reply
> was merely to point out that _some_ work has already been done ...

I added into CC also gcc, ld and mingw mailing list. If this is not
enough, could you tell me who to contact about those issues?

Re: Problems when building NT kernel drivers with GCC / LD

[Jan Beulich]

On 26.11.2022 20:04, Pali Rohár wrote:
> On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
>> But then, with you replying to
>> me specifically, perhaps you're wrongly assuming that I would be
>> planning to look into addressing any or all of these? My earlier reply
>> was merely to point out that _some_ work has already been done ...
> 
> I added into CC also gcc, ld and mingw mailing list. If this is not
> enough, could you tell me who to contact about those issues?

That's probably enough, sure. I merely tried to set expectations right,
since you did reply To: me (and lists were only on Cc: - it being the
other way around would have demonstrated that you're not asking me
specifically).

Jan

Re: Problems when building NT kernel drivers with GCC / LD

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Mon, 28 Nov 2022, 08:08 Jan Beulich via Gcc, <gcc@gcc.gnu.org> wrote:

> On 26.11.2022 20:04, Pali Rohár wrote:
> > On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
> >> But then, with you replying to
> >> me specifically, perhaps you're wrongly assuming that I would be
> >> planning to look into addressing any or all of these? My earlier reply
> >> was merely to point out that _some_ work has already been done ...
> >
> > I added into CC also gcc, ld and mingw mailing list. If this is not
> > enough, could you tell me who to contact about those issues?
>
> That's probably enough, sure. I merely tried to set expectations right,
> since you did reply To: me (and lists were only on Cc: - it being the
> other way around would have demonstrated that you're not asking me
> specifically).
>

That's just how most mailers do "Reply All", I don't think it out implies
anything. Removing the Cc list and *only* replying to you would be
different.

Re: Problems when building NT kernel drivers with GCC / LD

[Jan Beulich]

On 28.11.2022 09:40, Jonathan Wakely wrote:
> On Mon, 28 Nov 2022, 08:08 Jan Beulich via Gcc, <gcc@gcc.gnu.org> wrote:
> 
>> On 26.11.2022 20:04, Pali Rohár wrote:
>>> On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
>>>> But then, with you replying to
>>>> me specifically, perhaps you're wrongly assuming that I would be
>>>> planning to look into addressing any or all of these? My earlier reply
>>>> was merely to point out that _some_ work has already been done ...
>>>
>>> I added into CC also gcc, ld and mingw mailing list. If this is not
>>> enough, could you tell me who to contact about those issues?
>>
>> That's probably enough, sure. I merely tried to set expectations right,
>> since you did reply To: me (and lists were only on Cc: - it being the
>> other way around would have demonstrated that you're not asking me
>> specifically).
>>
> 
> That's just how most mailers do "Reply All", I don't think it out implies
> anything.

I know mailers behave that way. But when replying you can adjust To:
vs Cc:. That's what I'm doing all the time (or at least I'm trying to
remember to do so), because it makes a difference to me whether mail
is sent To: me vs I'm only being Cc:-ed. Otherwise - why do we have
To: and Cc: as different categories?

> Removing the Cc list and *only* replying to you would be different.

Sure - that would have meant sending private mail, which is yet worse.

Jan

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

Hello! I would like to remind this thread for gcc/binutils developers.
Most of these issues are still present and cause problems for compiling
native PE binary. If you have questions or you need any other information
please let me know.

On Sunday 30 October 2022 02:06:11 Pali Rohár wrote:
> Hello!
> 
> I tried to develop simple NT kernel driver and build it via GNU GCC, LD
> and mingw-w64 ecosystem but due to issues with compiler and linker, it
> is not possible to generate final .sys binary without adding workarounds
> or postprocessing resulted PE .sys binary.
> 
> I'm sending this email to all parties (binutils = linker, gcc = compiler,
> mingw-w64 = runtime) which are involved in building process of NT kernel
> driver (which is just native PE binary) and I would like to describe
> existing issues and ask if you can come up with fixes.
> 
> For demonstration I created very simple NT kernel driver which can be
> compiled by MSVC compiler without any issues, so you can directly look
> at the code and play with it: https://github.com/pali/secure-giveio
> I have there also GNUmakefile which uses GNU tools for compilation and
> tries to workaround issues.
> 
> Here is the list of those GCC / LD issues which I observed during
> development and compilation of NT kernel drivers:
> 
> * GCC does not support __declspec(code_seg("segname")) declarator for
>   specifying name of PE/COFF segment name. But instead GCC supports
>   different syntax __declspec(section("segname")) for this thing.
> 
>   I thought that GCC added __declspec support for compatibility with
>   other PE/COFF compilers. But because declarators are different it just
>   means that __declspec segment name is not compatible neither with MSVC.
> 
>   If the GCC's intention of __declspec is compatibility support then it
>   would be really really useful to have support for __declspec(code_seg
>   instead of custom __declspec(section syntax supported only by GCC.
> 
>   As a workaround to have driver compilable by both MSVC and GCC it is
>   needed to add #ifdef for GCC compiler.
> 
> * LD --dynamicbase is not working correctly. If used for PE executables
>   (not dynamic libraries) then it does *not* generate relocation info.
>   And without relocation info in PE binary, it is not possible to
>   relocate base address. Which makes dynamic base non-working.
> 
>   As a workaround GCC -pie can be used to generate relocation info (but
>   it is buggy too, see below).
> 
> * GCC -pie is unusable. It automatically generates export symbol table
>   even when PE binary must not export anything. This applies for Native
>   PE executables used as NT kernel .sys drivers. Normally only dynamic
>   libraries export symbols, so by default for executables should not
>   symbol table. Or at least there should be a flag which can disable
>   doing it.
> 
>   I tried to workaround it via LD --exclude-all-symbols, but it is also
>   not usable, see below.
> 
> * LD --exclude-all-symbols has issues for Native PE executables. It
>   causes generation of empty export table and puts name of the output
>   executable/driver (-o) as name of the export library. PE executables
>   which are in shared address space (e.g. NT driver executables) should
>   really do not be treated as libraries with library name (unless
>   explicitly asked for such thing).
> 
>   As a workaround I had to create a custom linker script which discards
>   that nonsense export table by completely dropping .edata section.
> 
> * LD puts discardable init sections in the middle of the PE binary. This
>   is really stupid as loaded PE binary waste memory space. Discardable
>   init sections should be at the end of the PE binary.
> 
>   As a workaround I used custom linker script.
> 
> * GCC or LD (not sure who) sets memory alignment characteristics
>   (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
>   These characteristics should be only in COFF object files, not
>   executable binaries. Specially they should not be in NT kernel
>   drivers.
> 
> * GCC or LD (not sure who) sets data characteristics
>   (IMAGE_SCN_CNT_INITIALIZED_DATA) for executable PE code sections.
>   Code sections should not be really marked as data, only as a code
>   (IMAGE_SCN_CNT_CODE).
> 
> * GCC or LD (not sure who) sets memory writable characteristics
>   (IMAGE_SCN_MEM_WRITE) into the read-only resources PE sections.
>   Read-only sections of final PE executable really should not marked as
>   writable.
> 
> * GCC or LD (not sure who) does *not* set memory discardable
>   characteristic (IMAGE_SCN_MEM_DISCARDABLE) for sections used only
>   during initial phase in NT kernel driver PE executables. This applies
>   for .idata, INIT and .rsrc sections. Without that characteristic there
>   is wasting of kernel memory.
> 
> * GCC or LD (not sure who) does *not* set memory not_paged
>   characteristics (IMAGE_SCN_MEM_NOT_PAGED) for PE sections which must
>   not be paged in NT kernel driver executables. Basically most sections
>   should must not be paged unless explicitly asked/marked. By default
>   just section with name PAGE could be paged and therefore only this
>   section does not have to have IMAGE_SCN_MEM_NOT_PAGED.
> 
> Last five issues I was not able to workaround neither via gcc or ld
> flags and neither via linker script. For example MSVC link.exe linker
> has switch /SECTION: which can be used to specify above characteristics
> specific section. But whatever I tried to do in GNU linker script, I was
> not able to set and fix those characteristics. For this reason I wrote
> custom application which post-process built PE executable and fix
> section characteristics, which GNU GCC/LD generated incorrectly.
> 
> Then I have there rather small but sometimes annoying objcopy issue.
> objcopy does not respect --disable-deterministic-archives or
> --preserve-dates switches and always deletes PE date/timestamp from
> executable. I was not able to find any switch which can tell objcopy to
> preserve PE date/timestamp. LD has flag --insert-timestamp for this
> thing, and this LD switch is working.
> 
> 
> Could you please look at those issues? Is there something which can be
> done to fix them? Because it is really stop-blocker for building even
> simple NT kernel drivers via open source GNU tools. Basically one main
> problem - generate relocation info for native executable - just reveal
> chain of other issues.
> 
> NT kernel .sys drivers are just simple Native PE executables (like
> ordinary .exe executables) but with relocation info (like .dll
> libraries) with fixed entry point, linked to ntoskrnl and have some
> characteristics.
> 
> Following gcc flags produce such executable (but with above issues):
> 
>   -Wl,--subsystem,native
>   -Wl,--dynamicbase -Wl,--nxcompat
>   -Wl,--image-base,0x10000 -Wl,--stack,0x40000
>   -Wl,--section-alignment,0x1000 -Wl,--file-alignment,0x200
>   -Wl,--disable-auto-import -Wl,--disable-stdcall-fixup
>   -nostartfiles -nodefaultlibs -nostdlib
>   -lntoskrnl
> 
> Note that entry point is always stdcall "DriverEntry" function. And
> because of symbol mangling, its symbol name is "_DriverEntry@8" for IX86
> and "DriverEntry" for AMD64. LD switch --entry= takes symbol name, not
> function name. So it would be a nice feature to allow specifying entry
> point via GCC/LD also as function name (without mangling) to have just
> 
>   -Wl,--entry=DriverEntry
> 
> parameter for gcc for all 32-bit and 64-bit builds.
> 
> And also it would be a nice to have some GCC flag which sets all above
> flags required for compiling NT kernel driver. Like there is -mdll for
> compiling DLL libraries or -mwindows for generating GUI WIN32
> executables. For example MSVC link.exe has for this switch /DRIVER.
> 
> If you have some questions then please let me know. I think that it
> would be really useful if GNU tools would be able to build NT kernel
> drivers without needs for hacks.

Re: Problems when building NT kernel drivers with GCC / LD

[Nick Clifton]

Hi Pali,

> Hello! I would like to remind this thread for gcc/binutils developers.
> Most of these issues are still present and cause problems for compiling
> native PE binary. If you have questions or you need any other information
> please let me know.

Have bug reports been filed for the individual issues ?  If not, please
could they be created.  The URLs for filing bugs are:

   https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils
   https://gcc.gnu.org/bugzilla/enter_bug.cgi

It would *really* help if the bug reports include a simple test case
to reproduce the specific problems.

If it is not clear which tool is the source of the problem, then I would
suggest choosing the binutils first.  If it turns out that specific issue
is actually caused by a problem in gcc, the bug report can always be moved
later on.

Cheers
   Nick

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

On Tuesday 03 January 2023 11:06:26 Nick Clifton wrote:
> Hi Pali,
> 
> > Hello! I would like to remind this thread for gcc/binutils developers.
> > Most of these issues are still present and cause problems for compiling
> > native PE binary. If you have questions or you need any other information
> > please let me know.
> 
> Have bug reports been filed for the individual issues ?  If not, please
> could they be created.  The URLs for filing bugs are:
> 
>   https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils
>   https://gcc.gnu.org/bugzilla/enter_bug.cgi
> 
> It would *really* help if the bug reports include a simple test case
> to reproduce the specific problems.
> 
> If it is not clear which tool is the source of the problem, then I would
> suggest choosing the binutils first.  If it turns out that specific issue
> is actually caused by a problem in gcc, the bug report can always be moved
> later on.
> 
> Cheers
>   Nick
> 

Hello! Just for a record, I filled individual issues to bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=30004
https://sourceware.org/bugzilla/show_bug.cgi?id=30139
https://sourceware.org/bugzilla/show_bug.cgi?id=30140
https://sourceware.org/bugzilla/show_bug.cgi?id=30141
https://sourceware.org/bugzilla/show_bug.cgi?id=30142
https://sourceware.org/bugzilla/show_bug.cgi?id=30143
https://sourceware.org/bugzilla/show_bug.cgi?id=30144
https://sourceware.org/bugzilla/show_bug.cgi?id=30145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108852

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

On Monday 20 February 2023 19:25:22 Pali Rohár wrote:
> On Tuesday 03 January 2023 11:06:26 Nick Clifton wrote:
> > Hi Pali,
> > 
> > > Hello! I would like to remind this thread for gcc/binutils developers.
> > > Most of these issues are still present and cause problems for compiling
> > > native PE binary. If you have questions or you need any other information
> > > please let me know.
> > 
> > Have bug reports been filed for the individual issues ?  If not, please
> > could they be created.  The URLs for filing bugs are:
> > 
> >   https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils
> >   https://gcc.gnu.org/bugzilla/enter_bug.cgi
> > 
> > It would *really* help if the bug reports include a simple test case
> > to reproduce the specific problems.
> > 
> > If it is not clear which tool is the source of the problem, then I would
> > suggest choosing the binutils first.  If it turns out that specific issue
> > is actually caused by a problem in gcc, the bug report can always be moved
> > later on.
> > 
> > Cheers
> >   Nick
> > 
> 
> Hello! Just for a record, I filled individual issues to bugzilla:
> https://sourceware.org/bugzilla/show_bug.cgi?id=30004
> https://sourceware.org/bugzilla/show_bug.cgi?id=30139
> https://sourceware.org/bugzilla/show_bug.cgi?id=30140
> https://sourceware.org/bugzilla/show_bug.cgi?id=30141
> https://sourceware.org/bugzilla/show_bug.cgi?id=30142
> https://sourceware.org/bugzilla/show_bug.cgi?id=30143
> https://sourceware.org/bugzilla/show_bug.cgi?id=30144
> https://sourceware.org/bugzilla/show_bug.cgi?id=30145
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108851
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108852

Hello! Should I do something more regarding these issues?

Re: Problems when building NT kernel drivers with GCC / LD

[Nick Clifton]

Hi Pali,

>> Hello! Just for a record, I filled individual issues to bugzilla:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30004
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30139
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30140
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30141
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30142
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30143
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30144
>> https://sourceware.org/bugzilla/show_bug.cgi?id=30145
> 
> Hello! Should I do something more regarding these issues?

Hitting me with a big hammer ?

*sigh* I was really hoping that someone else would step up to look at these
issues as I am not a Windows expert.

It looks like the first one (30004) has been fixed, and 30140 may have been
resolved - assuming that you agree with the explanation in comment #2.  But
the others all need addressing.  I will try to make time for them in the next
few weeks.

If you do have any suggestions for fixes to any of these problems, please do
feel free to add them to the relevant bug reports.

Cheers
   Nick

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

On Wednesday 12 April 2023 10:53:32 Nick Clifton wrote:
> Hi Pali,
> 
> > > Hello! Just for a record, I filled individual issues to bugzilla:
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30004
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30139
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30140
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30141
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30142
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30143
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30144
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=30145
> > 
> > Hello! Should I do something more regarding these issues?
> 
> Hitting me with a big hammer ?
> 
> *sigh* I was really hoping that someone else would step up to look at these
> issues as I am not a Windows expert.

Hello! Sorry I did not want to bother you. I sent email to mailing
lists, hoping that some Windows expert look at it.

> It looks like the first one (30004) has been fixed, and 30140 may have been
> resolved - assuming that you agree with the explanation in comment #2.  But
> the others all need addressing.  I will try to make time for them in the next
> few weeks.

And something was moved to gcc. I was in impression that this is just
one "big" project, but I see that gcc and binutils are like more
separated projects with separate bug trackers. And I'm not always sure
which code part belongs to which project... So excuse me if I put
something into incorrect issue tracker.

> If you do have any suggestions for fixes to any of these problems, please do
> feel free to add them to the relevant bug reports.

Of course! I will put comments into tickets and also test new patches.

> Cheers
>   Nick
> 
> 
> 

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

Hello, I would like to remind that the first gcc bug from the list in
previous email has not received any comment yet. It is this one:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
Do you need some more details, or something else for it?

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár]

On Sunday 07 January 2024 02:55:09 Pali Rohár wrote:
> Hello, I would like to remind that the first gcc bug from the list in
> previous email has not received any comment yet. It is this one:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
> Do you need some more details, or something else for it?

Hello, I put comment in that bug report. Can you look at it?