pragma directive to turn buffer security (/GS) on or off

  • Thread starter Thread starter George M. Garner Jr.
  • Start date Start date
G

George M. Garner Jr.

Is there a pragma directive to turn buffer security (/GS) on or off. I see
the runtime_checks and check_stack pragmas. But there doesn't appear to be
anything comparable for buffer security.

Thanks,

George.
 
No there is not. That is by design since the reason this feature is there is
because humans aren't good at analyzing what is exploitable in the first
place so /GS offers an additional level of protection when your source
review was flawed.

Can you give some more details as to the specific scenario you want to
disable these checks for?

Ronald Laeremans
Visual C++ team
 
Ronald,
Can you give some more details as to the specific scenario you want to
disable these checks for? <
Click to expand...

Yes. Call gates seem to trip the buffer security code. This is true even
if the ring0 code does nothing more than save registers and flags and
restore them. Here is some pseudo-code.

template<class _TYPE1, class _TYPE2>
static bool __stdcall call_ring0(WORD wSegment, _TYPE1 Arg1, _TYPE2 Arg2 =
(_TYPE2)0)
{
bool bResult;
WORD farcall[3];

_ASSERTE(wSegment !=0);
farcall[2] = wSegment;

STATIC_CHECK(sizeof(Arg1) <= sizeof(int),
Argument_is_not_an_integral_type);
STATIC_CHECK(sizeof(Arg2) <= sizeof(int),
Argument_is_not_an_integral_type);

_asm mov edx, Arg1
_asm mov ecx, Arg2
_asm call fword ptr [farcall]
_asm mov eax, edx
_asm mov bResult, al

return bResult;
} <-- Buffer security warning here.

void __declspec(naked) ring0_func()
{
_asm {
pushad
pushf
cli
popf
popad
sti
retf
}

}

Note that this is not general use software and yes I know that using call
gates is not generally a good idea. It does seem that it should be possible
for an engineer to turn the feature on or off at compile time (but not at
runtime) in a specific instance to meet special needs.

Regards,

George.
 
Hi George,

Sorry for the delay.

Which version of the compiler are you seeing this with? We have looked at
the 8.0 (Whidbey) compiler and we indeed have introduced a bug in there that
we discovered thanks to your post. But I take it you are seeing this issue
with a released compiler? Ca you provide me the info you get when you
execute:

cl /Bv

Thanks!

Ronald

George M. Garner Jr. said:
Ronald,
Can you give some more details as to the specific scenario you want to
disable these checks for? <
Click to expand...

Yes. Call gates seem to trip the buffer security code. This is true even
if the ring0 code does nothing more than save registers and flags and
restore them. Here is some pseudo-code.

template<class _TYPE1, class _TYPE2>
static bool __stdcall call_ring0(WORD wSegment, _TYPE1 Arg1, _TYPE2 Arg2 =
(_TYPE2)0)
{
bool bResult;
WORD farcall[3];

_ASSERTE(wSegment !=0);
farcall[2] = wSegment;

STATIC_CHECK(sizeof(Arg1) <= sizeof(int),
Argument_is_not_an_integral_type);
STATIC_CHECK(sizeof(Arg2) <= sizeof(int),
Argument_is_not_an_integral_type);

_asm mov edx, Arg1
_asm mov ecx, Arg2
_asm call fword ptr [farcall]
_asm mov eax, edx
_asm mov bResult, al

return bResult;
} <-- Buffer security warning here.

void __declspec(naked) ring0_func()
{
_asm {
pushad
pushf
cli
popf
popad
sti
retf
}

}

Note that this is not general use software and yes I know that using call
gates is not generally a good idea. It does seem that it should be
possible for an engineer to turn the feature on or off at compile time
(but not at runtime) in a specific instance to meet special needs.

Regards,

George.

Ronald Laeremans said:
No there is not. That is by design since the reason this feature is there
is because humans aren't good at analyzing what is exploitable in the
first place so /GS offers an additional level of protection when your
source review was flawed.

Can you give some more details as to the specific scenario you want to
disable these checks for?

Ronald Laeremans
Visual C++ team
Click to expand...
Click to expand...
 
Ronald,

Sorry to take so long getting back to you. Unfortunately, I am no longer
able to reproduce the problem. But a lot has changed in the interim. I am
now two builds down the road on the operating system, etc. etc. I am glad
that I was able to help you discover the bug in Whitbey. Here is the
information that you requested:

C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE>"C:\Program
Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl" /Bv
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

Compiler Passes:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe:
Version 13.10.3077.0
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\c1.dll:
Version 13.10.3077.0
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\c1xx.dll:
Version 13.10.3077.0
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\c2.dll:
Version 13.10.3077.0
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe:
Version 7.10.3077.0
C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\mspdb71.dll:
Version 7.10.3077.0

Regards,

George.
 
Back
Top