search for: no_pie

Yes, we have no ASRL with -no_pie. Can we disable ASRL even with -pie? On linux we can do it with "setarch x86_64 -R". Another question: if asan would require -no_pie on Mac, will this be a serious limitation? Thanks, --kcc On Fri, Dec 9, 2011 at 11:07 AM, Eric Christopher <echristo at apple.com>wrote: >...

On Fri, Dec 9, 2011 at 11:16 AM, Eric Christopher <echristo at apple.com>wrote: > > On Dec 9, 2011, at 11:12 AM, Kostya Serebryany wrote: > > > Yes, we have no ASRL with -no_pie. > > Can we disable ASRL even with -pie? > > On linux we can do it with "setarch x86_64 -R". > > > > You asked about link time. Now it sounds like you're talking about runtime? > Link time is of course better. But if there is a syscall (like the one used by...

On Dec 9, 2011, at 11:12 AM, Kostya Serebryany wrote: > Yes, we have no ASRL with -no_pie. > Can we disable ASRL even with -pie? > On linux we can do it with "setarch x86_64 -R". > You asked about link time. Now it sounds like you're talking about runtime? > Another question: if asan would require -no_pie on Mac, will this be a serious limitation? >...

On Dec 9, 2011, at 11:23 AM, Kostya Serebryany wrote: > > > On Fri, Dec 9, 2011 at 11:16 AM, Eric Christopher <echristo at apple.com> wrote: > > On Dec 9, 2011, at 11:12 AM, Kostya Serebryany wrote: > > > Yes, we have no ASRL with -no_pie. > > Can we disable ASRL even with -pie? > > On linux we can do it with "setarch x86_64 -R". > > > > You asked about link time. Now it sounds like you're talking about runtime? > > Link time is of course better. > But if there is a syscall (like the...

...PIE from .o files compiled with -mdy- namic-no-pic. That means the codegen is less optimal, but the address randomization adds some security. When targeting Mac OS X 10.7 or later PIE is the default for main executa- bles. -no_pie Do not make a position independent executable (PIE). This is the default, when targeting 10.6 and earlier. On Dec 9, 2011, at 11:02 AM, Kostya Serebryany wrote: > +llvmdev > > Question to MacOS gurus: is there a way to disable ASLR (address space layout randomizati...

+llvmdev Question to MacOS gurus: is there a way to disable ASLR (address space layout randomization) on Darwin at link time instead of doing setenv("DYLD_NO_PIE", "1", 1); and reexec? Thanks, --kcc On Fri, Dec 9, 2011 at 4:28 AM, Alexander Potapenko <glider at google.com>wrote: > The attached patch introduces the disable_aslr option (off by default) > and the corresponding AsanDisableAslr function that should disable the >...

...: > > On Dec 9, 2011, at 11:23 AM, Kostya Serebryany wrote: > > > > On Fri, Dec 9, 2011 at 11:16 AM, Eric Christopher <echristo at apple.com>wrote: > >> >> On Dec 9, 2011, at 11:12 AM, Kostya Serebryany wrote: >> >> > Yes, we have no ASRL with -no_pie. >> > Can we disable ASRL even with -pie? >> > On linux we can do it with "setarch x86_64 -R". >> > >> >> You asked about link time. Now it sounds like you're talking about >> runtime? >> > > Link time is of course better. >...

...rst glance this appears to work, but when linking the object file I get the warning: ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in <...>. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie This novice developer thought that the solution would be: engineBuilder.setRelocationModel(Reloc::PIC_); However this has no diff in the resulting object file. Have I overlooked something simple? Is this feature not supported and I need to link with -Wl,-no_pie? Thanks in advance! v/r Josh...

...really don't like >   1. 3 different cases for 3 different flavors of MacOS. How are we goring > to support it? The first is Leopard, which we don't want to support at all. Maybe we should check that in some other place. The second is Snow Leopard, where ASLR is controlled by the DYLD_NO_PIE env var, which is read by the dynamic loader. The third is Lion, which does not support DYLD_NO_PIE, but instead supports a flag I've mentioned above. I suppose further Mac OS releases will support only this way. There also is the MH_PIE bit in the Mach-O header, which we can flip to disable A...

Hey All, [NOTE: crossposting between freebsd-current@, freebsd-security@, and freebsd-stable at . Please forgive me if crossposting is frowned upon.] Address Space Layout Randomization, or ASLR for short, is an exploit mitigation technology. It helps secure applications against low-level exploits. A popular secure implementation is known as PaX ASLR, which is a third-party patch for Linux. Our

Hey All, [NOTE: crossposting between freebsd-current@, freebsd-security@, and freebsd-stable at . Please forgive me if crossposting is frowned upon.] Address Space Layout Randomization, or ASLR for short, is an exploit mitigation technology. It helps secure applications against low-level exploits. A popular secure implementation is known as PaX ASLR, which is a third-party patch for Linux. Our

.... 3 different cases for 3 different flavors of MacOS. How are we > goring > > to support it? > The first is Leopard, which we don't want to support at all. Maybe we > should check that in some other place. > The second is Snow Leopard, where ASLR is controlled by the > DYLD_NO_PIE env var, which is read by the dynamic loader. > The third is Lion, which does not support DYLD_NO_PIE, but instead > supports a flag I've mentioned above. I suppose further Mac OS > releases will support only this way. > > There also is the MH_PIE bit in the Mach-O header, which...

The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch

The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch

The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch

The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch

...l: Added HTMLTextAreaElement::get_form implementation. Jactry Zeng (1): mshtml/tests: Fix typo. Julian R?ger (1): po: Update German translation. Ken Thomases (2): wined3d: Fix subtraction of resource size from used adapter memory. configure: For Mac, link wineloader with -no_pie if it's available. Matteo Bruni (9): gdi32: Don't overflow the buffer in GetGlyphOutline. gdi32/tests: Add a test for GetGlyphOutline with an insufficient buffer. wined3d: Fail to create shaders using more than the supported number of constants. d3d9/tests: Add some...

> On Jun 14, 2017, at 2:47 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On 15 Jun 2017, at 6:50 AM, Louis Gerbarg <lgerbarg at apple.com <mailto:lgerbarg at apple.com>> wrote: >> >>> >>> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have