similar to: fno-stack-protector

On Tue, Jul 14, 2020 at 02:08:36PM +0200, Joerg Roedel wrote: > From: Joerg Roedel <jroedel at suse.de> > > The code inserted by the stack protector does not work in the early > boot environment because it uses the GS segment, at least with memory > encryption enabled. Make sure the early code is compiled without this > feature enabled. > > Signed-off-by: Joerg

On Tue, Apr 28, 2020 at 11:28 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Joerg Roedel <jroedel at suse.de> > > The code inserted by the stack protector does not work in the early > boot environment because it uses the GS segment, at least with memory > encryption enabled. Make sure the early code is compiled without this > feature enabled. > >

From: Joerg Roedel <jroedel at suse.de> The code inserted by the stack protector does not work in the early boot environment because it uses the GS segment, at least with memory encryption enabled. Make sure the early code is compiled without this feature enabled. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/Makefile | 4 ++++ 1 file changed, 4 insertions(+)

From: Joerg Roedel <jroedel at suse.de> The code inserted by the stack protector does not work in the early boot environment because it uses the GS segment, at least with memory encryption enabled. Make sure the early code is compiled without this feature enabled. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/Makefile | 4 ++++ 1 file changed, 4 insertions(+)

On Tue, Apr 28, 2020 at 11:28 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Joerg Roedel <jroedel at suse.de> > > The code inserted by the stack protector does not work in the early > boot environment because it uses the GS segment, at least with memory > encryption enabled. Make sure the early code is compiled without this > feature enabled. > >

On Tue, Apr 28, 2020 at 05:16:45PM +0200, Joerg Roedel wrote: > From: Joerg Roedel <jroedel at suse.de> > > The code inserted by the stack protector does not work in the early > boot environment because it uses the GS segment, at least with memory > encryption enabled. Can you elaborate on why is that a problem? The stack cookie is not generated that early yet so it should

On Tue, May 19, 2020 at 09:58:18AM -0400, Brian Gerst wrote: > On Tue, Apr 28, 2020 at 11:28 AM Joerg Roedel <joro at 8bytes.org> wrote: > The proper fix would be to initialize MSR_GS_BASE earlier. That'll mean to initialize it two times during boot, as the first C function with stack-protection is called before the kernel switches to its high addresses (early_idt_setup

The __restore_processor_state() fn restores %gs on resume from S3. As such, it cannot be protected by the stack-protector guard since %gs will not be correct on function entry. There are only a few other fns in this file and it should not negatively impact kernel security that they will also have the stack-protector guard removed (and so it's not worth moving them to another file). Without

The __restore_processor_state() fn restores %gs on resume from S3. As such, it cannot be protected by the stack-protector guard since %gs will not be correct on function entry. There are only a few other fns in this file and it should not negatively impact kernel security that they will also have the stack-protector guard removed (and so it's not worth moving them to another file). Without

If you compile this with optimizations, then the 'canary()' function should be totally inlined into the 'main()' function. In that case, the cost of the stack protectors will be very small compared to the loop. -bw On Mar 9, 2012, at 2:52 AM, Job Noorman <jobnoorman at gmail.com> wrote: > I have a question about the performance of the implementation of the stack >

I have a question about the performance of the implementation of the stack protector in LLVM. Consider the following C program: ===== void canary() { char buf[20]; buf[0]++; } int main() { int i; for (i = 0; i < 1000000000; ++i) canary(); return 0; } ===== This should definately run slower when stack protection is enabled, right? I have measured the runtime of

Hello, I am having errors when I try to install RSPerl-0.92 under fedora 14. I have the following rpms installed: R-devel-2.13.0-1.fc14.x86_64 R-core-2.13.0-1.fc14.x86_64 perl-5.12.3-143.fc14.x86_64 perl-devel-5.12.3-143.fc14.x86_64 perl-ExtUtils-* (all of them from yum) Now I get the following errors: # R CMD INSTALL RSPerl_0.92-1.tar.gz * installing to library ‘/usr/lib64/R/library’ *

Hi, I am using clang++3.9 to build a simple program with both CFI and safe-stack. I am getting linker errors when combining -fsanitize=safe-stack, -fsanitize=cfi, and -fno-sanitize-trap=all. Combining safe-stack and CFI without -fno-sanitize-trap=all works as expected. It looks like clang is attempting to link in two compiler-rt libraries, one for ubsan and one for safestack, and this causes

Hi, List, In checking the page fault problem when using pv-grub to start domU in opensuse12.3[1], found that the problem is caused by ''-fstack-protector'' flag which is introduced in rpm build: export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS" export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS" export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS" with

Le 21/08/2013 12:20, maximilian attems a ?crit : > On Tue, Aug 20, 2013 at 07:44:39AM +0200, leroy christophe wrote: >> Find attached two patches I have in order to build klibc 2.0.2 >> against kernel 3.8.13 >> We had to introduce those patches when going from kernel 3.6 to kernel 3.7 >> Hope it helps. >> > those patches are wrong and again very brittle. >

M-Halo wrote: >--- "James E. LaBarre" <jamesl@bestweb.net> wrote: > > > >>>On Fri, 2004-12-03 at 08:27 -0800, Duane Clark >>> >>> >>wrote: >> >> >>>>(You need to hit "Reply-all" so that responses go >>>> >>>> >>to the list, instead >> >>

You should be able to set PKG_FCFLAGS="-fno-stack-protector" when compiling to ensure that the stack protector is not used. (Trying that out on a Windows VM, with a simple `R CMD build` + `R CMD INSTALL`, compilation of your package succeeded but linking failed saying the DLL 'Fpi' was not found; I imagine that's a separate issue.) As an aside, be sure to check out what

Did you installed openssh? Tobias Hachmer <lists at kokelnet.de>??? >Hello list, > >Although timos bugfix release this morning I can't build pigeonhole 0.3.3 for >dovecot 2.1.12 successfully. I don't know if it is a new bug or if I do >something wrong but with dovecot 2.1.10 all worked fine, with the same configure >options. > >configure options (out of

Hello list, Although timos bugfix release this morning I can't build pigeonhole 0.3.3 for dovecot 2.1.12 successfully. I don't know if it is a new bug or if I do something wrong but with dovecot 2.1.10 all worked fine, with the same configure options. configure options (out of debian/rules for building debian package): ./configure --with-dovecot=/usr/lib/dovecot \

Verifying a report I just got pinged about, building vanilla openssh 7.7p1 on linux configures ok, but fails build around 'retpoline' I've started looking through recent reports; haven't _yet_ found anything similar. While I continue, is any of the following familiar/expected? Either known bug/issue or env conflict? The current env includes supposedly retpoline-ready GCC 8.1.1,