BTW, I have verified that these options all work as described and the options are recognized and processed properly by Windows, and that BinScope is happy:
Failed checks d:\source\sqlite\sqlite3.dll - SafeSEHCheck ( FAIL ) Passed checks d:\source\sqlite\sqlite3.dll - NXCheck ( PASS ) d:\source\sqlite\sqlite3.dll - DBCheck ( PASS ) (Note, position independent code (PIC) is by definition loadable at any base. Microsoft is just several decades behind in generating position independent code.) --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-----Original Message----- >From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- >bounces at mailinglists.sqlite.org] On Behalf Of Keith Medcalf >Sent: Thursday, 2 April, 2015 17:43 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >NXCheck - DBCheck > > >add the following linker options with MinGW: > >-static-libgcc -Wl,-Bstatic,--nxcompat,--dynamicbase,--export-all-symbols > >You may or may not need -static-libgcc or the linker -Bstatic options >unless you are also enabling things that require MingW DLL runtime >support (such as using the -mthreads option to make the DLL thread >exception safe). > >-Wl,--nxcompat,--dynamicbase,--export-all-symbols,--large-address-aware > >Sets the NXCOMPAT and DYNAMICBASE (ASLR) flags on the output of the >linker (so you can add them to the shell tool and other pre-built >executables as well). Files also need to export the symbol table (hence >the --export-all-symbols). --large-address-aware sets the (you guessed >it) large address aware flag which basically means that you are using >unsigned pointers and not signed pointers (that is, you understand that >neither disk space nor memory comes in negative sizes) and don't diddle >with your pointers (eg, assigning magical meaning to bits in the >pointer). This allows use of more than 2GB of virtual address space per >process on systems that support it (ie, 32-bit userland on a 64-bit >Windows -- on 64-bit Windows windows does not co-habitate with 32-bit >processes, instead a wee trampoline is installed in the top 100MB or so >of the virtual space to thunk back and forth to the OS -- making it >impossible to insert code into the OS from a 32-bit process, while 64-bit >processes on 64 > -bit windows have full and complete access to the OS as it resides in >each processes address space) or if the /3GB boot option is set on 32-bit >OSes (so the OS is forced to shoehorn into the top 1GB of each process). > >The only thing this does not fix is the Exception Handlers. But that >particular protection is not implemented by gcc (not needed because of >non-ill-conceived design?). However, you might still want to add - >mthreads and the static linking options to the build so that the GCC >threadsafe exception handlers are used. > >--- >Theory is when you know everything but nothing works. Practice is when >everything works but no one knows why. Sometimes theory and practice are >combined: nothing works and no one knows why. > >>-----Original Message----- >>From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- >>bounces at mailinglists.sqlite.org] On Behalf Of Richard Hipp >>Sent: Thursday, 2 April, 2015 14:25 >>To: General Discussion of SQLite Database >>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >>NXCheck - DBCheck >> >>On 4/2/15, Random Coder <random.coder at gmail.com> wrote: >>> >>> I'd recommend the SQLite team turn them on for the version of the DLL >>> they distribute, but I'm honestly not sure if there are negative side >>> effects to doing so. >> >>That's not possible, unfortunately, We compile the published DLL >>(the 32-bit DLL at least) with MinGW so that they will work on older >>versions of Windows. If we used a recent MSVC then the resulting DLL >>will not work on WinXP, I am told. >> >>If the published DLL is not to your liking, it is simple to make your >>own. I suggest you do so. You can start with the amalgamated source >>code file "sqlite3.c". All you need is to compile that one file into >>a DLL that the security checker approves of. How hard can that be? >> >>-- >>D. Richard Hipp >>drh at sqlite.org >>_______________________________________________ >>sqlite-users mailing list >>sqlite-users at mailinglists.sqlite.org >>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > >_______________________________________________ >sqlite-users mailing list >sqlite-users at mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
