Re: How to enable GCC Asan dynamic shadow address?

[Yuri Gribov]

On Thu, Jun 1, 2017 at 9:40 AM, steven shi  wrote:
> Hello,
> I'm trying to enable the gcc asan on my bare-mental firmware after llvm. I
> need to set the GCC Asan shadow memory value dynamically, but I cannot find
> proper gcc build option to do it. With Clang, I can use "-mllvm
> -asan-force-dynamic-shadow=true" build option and assign the dynamic shadow
> address in the module entry as "__asan_shadow_memory_dynamic_address =
> DynamicShadowAddress". What's the equivalent build option in gcc?

AFAIK this isn't supported in GCC and I'm not sure that this works in
Clang either. AArch64 folks asked for dynamic shadow but Asan
developers were concerned about potential performance implications so
it went nowhere...

-I

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable GCC Asan dynamic shadow address?

[steven shi]

Clang does works, at least for X64, and I have depended on it to enable the 
LLVM Asan in my Uefi firmware.  I can see the related patch is here: 
https://reviews.llvm.org/D23354. Although this patch say it is for Windows 
64bits, but I think this patch is architecture independent, isn't it?

The dynamic shadow address is very important for my firmware enabling, 
because my firmware directly map virtual address to physical, and it 
doesn't have sophisticated memory page managements. The Asan shadow memory is 
allocated according to platform memory real size which could be different 
from boot to boot and different from platform to platform. Set the dynamic 
shadow address is the easiest way to enable Asan in my firmware. 

Does Asan developers have plan to port the D23354 patch to gcc main trunk? 
The D23354 functionality already meet my firmware requirement. I guess it 
should not too difficult. 

Thanks
Steven

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable GCC Asan dynamic shadow address?

[Yuri Gribov]

On Thu, Jun 1, 2017 at 11:51 AM, steven shi  wrote:
> Clang does works, at least for X64, and I have depended on it to enable the
> LLVM Asan in my Uefi firmware.  I can see the related patch is here:
> https://reviews.llvm.org/D23354. Although this patch say it is for Windows
> 64bits, but I think this patch is architecture independent, isn't it?
>
> The dynamic shadow address is very important for my firmware enabling,
> because my firmware directly map virtual address to physical, and it doesn't
> have sophisticated memory page managements. The Asan shadow memory is
> allocated according to platform memory real size which could be different
> from boot to boot and different from platform to platform. Set the dynamic
> shadow address is the easiest way to enable Asan in my firmware.

Yup, many people have expressed desire for dynamic shadow for similar reasons.

> Does Asan developers have plan to port the D23354 patch to gcc main trunk?
> The D23354 functionality already meet my firmware requirement. I guess it
> should not too difficult.

Cc Max.

-Y

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable GCC Asan dynamic shadow address?

[Maxim Ostapenko]

Hi,

четверг, 1 июня 2017 г., 14:27:16 UTC+3 пользователь Yuri Gribov написал:
>
> On Thu, Jun 1, 2017 at 11:51 AM, steven shi  > wrote: 
> > Clang does works, at least for X64, and I have depended on it to enable 
> the 
> > LLVM Asan in my Uefi firmware.  I can see the related patch is here: 
> > https://reviews.llvm.org/D23354. Although this patch say it is for 
> Windows 
> > 64bits, but I think this patch is architecture independent, isn't it? 
> > 
> > The dynamic shadow address is very important for my firmware enabling, 
> > because my firmware directly map virtual address to physical, and it 
> doesn't 
> > have sophisticated memory page managements. The Asan shadow memory is 
> > allocated according to platform memory real size which could be 
> different 
> > from boot to boot and different from platform to platform. Set the 
> dynamic 
> > shadow address is the easiest way to enable Asan in my firmware. 
>
> Yup, many people have expressed desire for dynamic shadow for similar 
> reasons. 
>
> > Does Asan developers have plan to port the D23354 patch to gcc main 
> trunk? 
> > The D23354 functionality already meet my firmware requirement. I guess 
> it 
> > should not too difficult. 
>
> Cc Max. 
>

AFAIK there aren't any plans on implementing dynamic shadow on GCC side. 
But we can consider it, the patch shouldn't be hard to implement.

-Maxim
 

>
> -Y 
>

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable GCC Asan dynamic shadow address?

[steven shi]

Hi Max,
Thanks in advance. My firmware users use gcc much more than clang, so I 
appreciate if you could give priority to the gcc dynamic shadow feature. 

Thanks
Steven

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable GCC Asan dynamic shadow address?

[Maxim Ostapenko]

Hi,

On 01/06/17 13:51, steven shi wrote:
Clang does works, at least for X64, and I have depended on it to 
enable the LLVM Asan in my Uefi firmware.  I can see the related patch 
is here: https://reviews.llvm.org/D23354. Although this patch say it 
is for Windows 64bits, but I think this patch is architecture 
independent, isn't it?


The dynamic shadow address is very important for my firmware enabling, 
because my firmware directly map virtual address to physical, and it 
doesn't have sophisticated memory page managements. The Asan shadow 
memory is allocated according to platform memory real size which could 
be different from boot to boot and different from platform to 
platform. Set the dynamic shadow address is the easiest way to enable 
Asan in my firmware.


Does Asan developers have plan to port the D23354 patch to gcc main 
trunk? The D23354 functionality already meet my firmware requirement. 
I guess it should not too difficult.


AFAIK neither ASan nor GCC developers have plans to implement dynamic 
shadow address at GCC side.




Thanks
Steven
--
You received this message because you are subscribed to the Google 
Groups "address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to address-sanitizer+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable GCC Asan dynamic shadow address?

[steven shi]

Hi Yuri,
I'm trying to use the Kasan -fasan-shadow-offset option to work around the 
Asan fixed shadow offset issue in gcc. I see you enabled it with this patch 
https://patchwork.ozlabs.org/patch/402873/. 
 If it works, I will replace 
the Asan with Kasan in my firmware. 

I have two questions about Kasan:
1. Besides the different run-time libraries for OS kernel and application, 
is there other difference between Kasan and Asan, especially in the 
instrumentation part?
2. I need to disable Kasan and -fasan-shadow-offset when compile my 
instrumentation library (e.g. __asan_store8). How to force to 
override/disable the -fasan-shadow-offset option if I have enabled it in 
parent compile options?  Now,  I enable the -fno-sanitize=address 
-fsanitize=kernel-address -fasan-shadow-offset=0x12345678 in parent compile 
options for all modules, and add the -fno-sanitize=all to disable them in 
instrumentation library. But the instrumentation library compile fail with 
"cc1: error: -fasan-shadow-offset should only be used with 
-fsanitize=kernel-address". How could I disable the 
-fsanitize=kernel-address and -fasan-shadow-offset options together?


Thanks
Steven 

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable GCC Asan dynamic shadow address?

[Yuri Gribov]

On Fri, Jun 9, 2017 at 5:51 AM, steven shi  wrote:
> Hi Yuri,
> I'm trying to use the Kasan -fasan-shadow-offset option to work around the
> Asan fixed shadow offset issue in gcc. I see you enabled it with this patch
> https://patchwork.ozlabs.org/patch/402873/. If it works, I will replace the
> Asan with Kasan in my firmware.

Hi Steven,

Note that this flag only allows you to set fixed offset (in contrast,
dynamic offset allows the selection to be done at runtime). This may
or may not be enough for your case.

> I have two questions about Kasan:
> 1. Besides the different run-time libraries for OS kernel and application,
> is there other difference between Kasan and Asan, especially in the
> instrumentation part?

The one (and AFAIR only) change is that KAsan enables
-fsanitize-recover=address by default (so it calls callbacks like
__asan_report_storeX_noabort rather than __asan_report_storeX).

> 2. I need to disable Kasan and -fasan-shadow-offset when compile my
> instrumentation library (e.g. __asan_store8). How to force to
> override/disable the -fasan-shadow-offset option if I have enabled it in
> parent compile options?  Now,  I enable the -fno-sanitize=address
> -fsanitize=kernel-address -fasan-shadow-offset=0x12345678 in parent compile
> options for all modules, and add the -fno-sanitize=all to disable them in
> instrumentation library. But the instrumentation library compile fail with
> "cc1: error: -fasan-shadow-offset should only be used with
> -fsanitize=kernel-address". How could I disable the
> -fsanitize=kernel-address and -fasan-shadow-offset options together?

I believe the best approach is simply to not enable Asan flags in
instrumentation library. I.e. have CFLAGS_NO_ASAN and use that in
instrumentation lib. BTW you don't need -fsanitize=address if you
enabled -fsanitize=kernel-address.

-Y

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable GCC Asan dynamic shadow address?

[steven shi]

Hi Yuri,

>
> > Note that this flag only allows you to set fixed offset (in contrast, 
> > dynamic offset allows the selection to be done at runtime). This may 
> > or may not be enough for your case. 
>
 
It is not perfect but really works for me. I have enabled gcc Kasan on my 
Uefi firmware today :) Thank you! 
I found I only need -fasan-shadow-offset for the fake stack red-zone in 
fact. You know, my firmware is self-contained, and I implement all the 
instrumentation library myself. So, no problem for the global variable and 
heap buffer shadow memory mapping. Only the stack instrumentation 
implementations are offered by compiler directly, which use the fixed 
offset for the shadow memory. If I disable the stack buffer protection, I 
can use both Asan and Kasan actually.  Now, I have to set the 
-fasan-shadow-offset with Kasan in build time to enable the stack buffer 
protection. It is not perfect, but can work at least.

BTW, since my Uefi firmware (a.k.a bios)  use the same Kasan as Linux 
kernel, I'm thinking whether it make sense if we enable the Kasan for the 
whole Linux booting process. I could reserve a fixed range physical memory 
as shadow memory according to config (dynamic is also ok for me, and I can 
pass this info through Uefi interface to Linux). The Linux boot loader and 
other kernel necessary modules can rebuild against the fixed shadow memory. 
This way can let the Kasan work through the all the flow from memory HW is 
ready to OS boot up. Does it make sense?

Thanks
Steven


-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to enable GCC Asan dynamic shadow address?

[Yuri Gribov]

On Mon, Jun 12, 2017 at 9:23 AM, steven shi  wrote:
> Hi Yuri,
>>
>>
>> > Note that this flag only allows you to set fixed offset (in contrast,
>> > dynamic offset allows the selection to be done at runtime). This may
>> > or may not be enough for your case.
>
>
> It is not perfect but really works for me. I have enabled gcc Kasan on my
> Uefi firmware today :) Thank you!
> I found I only need -fasan-shadow-offset for the fake stack red-zone in
> fact. You know, my firmware is self-contained, and I implement all the
> instrumentation library myself. So, no problem for the global variable and
> heap buffer shadow memory mapping. Only the stack instrumentation
> implementations are offered by compiler directly, which use the fixed offset
> for the shadow memory. If I disable the stack buffer protection, I can use
> both Asan and Kasan actually.  Now, I have to set the -fasan-shadow-offset
> with Kasan in build time to enable the stack buffer protection. It is not
> perfect, but can work at least.
>
> BTW, since my Uefi firmware (a.k.a bios)  use the same Kasan as Linux
> kernel, I'm thinking whether it make sense if we enable the Kasan for the
> whole Linux booting process. I could reserve a fixed range physical memory
> as shadow memory according to config (dynamic is also ok for me, and I can
> pass this info through Uefi interface to Linux). The Linux boot loader and
> other kernel necessary modules can rebuild against the fixed shadow memory.
> This way can let the Kasan work through the all the flow from memory HW is
> ready to OS boot up. Does it make sense?

Cc Andrew (he's KAsan implementor so has more informed opinion).

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.