Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

grateful for suggestions here. > > Could there be a bug in gcc 8 that made it forget to actually output the > file? I don't think that gcc is to blame. Did you look at the final messages make-kpkg printed? If run successfully it should say something like "building

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

ar.xz > drwxr-xr-x 8 root root 4096 Nov 18 09:15 open-vm-tools-10.1.5 > root@mikef-PC:/usr/src# > > > ​Should the filename be something like linux-image-4.14.14.deb etc? > > Maybe Greg could think some find command that would search everywhere in > the install I

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

me funny directory (even /tmp?) no one has ever heard of. I would be grateful for suggestions here. Could there be a bug in gcc 8 that made it forget to actually output the file? Thanks MF​ > > Regards > > Michael > > > .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On 27 January 2018 at 11:26, Michael Fothergill < michael.fotherg...@gmail.com> wrote: > When you install the kernel, the following page ( > https://www.debian.org/releases/jessie/i386/ch08s06.html.en) says you > must run the following command: > > *​dpkg -i

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

Hi, On Sat, 27 Jan 2018 11:26:25 + Michael Fothergill wrote: > > Where would the default location of such a file be if were created using > the make-kpkg command? the package should be in the source's parent directory, in your case I guess in /usr/src .

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

When you install the kernel, the following page ( https://www.debian.org/releases/jessie/i386/ch08s06.html.en) says you must run the following command: *​dpkg -i ../linux-image-3.16-subarchitecture_1.0.custom_i386.deb*. ​Do I need to run mrproper beforehand? I can't see any linux-image file in

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

.14.15' make[1]: Leaving directory '/usr/src/linux-4.14.15' echo done > debian/stamp/conf/minimal_debian exec debian/rules nothing to be done. ​I think it's worked. I am going to back to the list of tasks I made on this figure out what to do next to install it so grub can see it etc and I can

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

gt; Update: > just checked with my laptop (Intel/Baytrail); it is the same with msr, > module not loaded automatically, when loaded manually the contents > of /dev/cpu/0 look just as on my AMD desktop machine. The output of the > checker script still says "No" in the lines referring

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On Fri, 26 Jan 2018 23:49:46 +0100 Sven Hartge wrote: > Michael Lange wrote: > > > When I check /proc/cpuinfo I see that "msr" is listed in the "flags" > > section. So why doesn't the driver load automagically? > > It is not programmed to load

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

he contents of /dev/cpu/0 look just as on my AMD desktop machine. The output of the checker script still says "No" in the lines referring to msr. *BUT*, since I finally managed to compile 4.15.rc9 with gcc-7.3, the script claims the laptop is no longer vulnerable to "Spectre2&q

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

Michael Lange wrote: > When I check /proc/cpuinfo I see that "msr" is listed in the "flags" > section. So why doesn't the driver load automagically? It is not programmed to load automatically, because writing to MSRs is dangerous and can even damage your computer or CPU.

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On Fri, 26 Jan 2018 12:45:13 -0500 Greg Wooledge <wool...@eeg.ccf.org> wrote: > On Fri, Jan 26, 2018 at 06:07:13PM +0100, Michael Lange wrote: > > I am definitely anything but an expert on this; but with sid's 4.14.15 > > (which I assumed was compiled with said gcc-7.2)

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On Fri, 26 Jan 2018 23:25:55 +0100 Sven Hartge wrote: > Do the contents of the /dev/cpu directory change between loaded and > unloaded msr.ko? > > When msr.ko is loaded, there should be directory for each CPU in the > system: > > # ls -ld /dev/cpu/* > drwxr-xr-x 2 root root

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

Michael Lange wrote: > Yes, it is the sid kernel, and the module exists. When running the > script as root it is the same. lsmod shows that the msr module is not > loaded. If I load it manually with modprobe it appears to load without > errors, but the output of the

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On Fri, 26 Jan 2018 21:28:19 +0100 Sven Hartge wrote: > > Not me, that's the sid kernel :) > > No. The kernel from Sid has support for MSR as module: > > root@host:~# modinfo msr > filename: /lib/modules/4.14.0-3-amd64/kernel/arch/x86/kernel/msr.ko > license:GPL >

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

Michael Lange wrote: > On Fri, 26 Jan 2018 18:38:23 +0100 Sven Hartge wrote: >> Michael Lange wrote: >>> Hardware check >>> * Hardware support (CPU microcode) for mitigation techniques >>> * Indirect Branch Restricted

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On Fri, 26 Jan 2018 18:38:23 +0100 Sven Hartge wrote: > Michael Lange wrote: > > > Hardware check > > * Hardware support (CPU microcode) for mitigation techniques > > * Indirect Branch Restricted Speculation (IBRS) > > * SPEC_CTRL MSR is

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

​Dear All, I have decided to get rid of GCC8 using ML's helpful command suggestion. I will install gcc 7 again as sid and try again with kernel 4.14.15. ​Cheers MF >

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On Fri, Jan 26, 2018 at 06:07:13PM +0100, Michael Lange wrote: > I am definitely anything but an expert on this; but with sid's 4.14.15 > (which I assumed was compiled with said gcc-7.2) the script here says: You shouldn't have to assume. /proc/version tells you which compiler was used. w

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

Hi, On Fri, 26 Jan 2018 22:48:51 +0530 "tv.deb...@googlemail.com" <tv.deb...@googlemail.com> wrote: > > Tested with upstream vanilla 4.14.15 compiled with current Sid gcc-7.3, > i get a pass for Spectre v2 (full generic retpoline) and Meltdown > (a.k.a. &qu

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

Michael Lange wrote: > Hardware check > * Hardware support (CPU microcode) for mitigation techniques > * Indirect Branch Restricted Speculation (IBRS) > * SPEC_CTRL MSR is available: UNKNOWN (couldn't > read /dev/cpu/0/msr, is msr support enabled in your kernel?)

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On 26 January 2018 at 17:18, tv.deb...@googlemail.com < tv.deb...@googlemail.com> wrote: > On 26/01/2018 22:37, Michael Lange wrote: > >> On Fri, 26 Jan 2018 22:19:27 +0530 >> "tv.deb...@googlemail.com" <tv.deb...@googlemail.com> wrote: >> >

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

e: >> >> Hi, sorry to jump into the thread this late, I didn't follow the >>> beginning. You can save yourself quite a bit of hassle by downloading >>> the upstream up-to-date vanilla kernel 4.15-rc9 and compile that with >>> Unstable gcc-7. All you need is t

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On 26/01/2018 22:37, Michael Lange wrote: On Fri, 26 Jan 2018 22:19:27 +0530 "tv.deb...@googlemail.com" <tv.deb...@googlemail.com> wrote: gcc-7[.2] was really gcc-7.3-rc for a while, and was doing a good job at enabling Spectre mitigation (as tested by the spectre-meltdown-

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On 26 January 2018 at 16:37, Greg Wooledge <wool...@eeg.ccf.org> wrote: > On Fri, Jan 26, 2018 at 04:17:27PM +, Michael Fothergill wrote: > > ​Is the sid gcc now 7.3 as someone said earlier even though it says it is > > 7.2? > > Sid apparently has both "gcc&

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On Fri, 26 Jan 2018 22:19:27 +0530 "tv.deb...@googlemail.com" <tv.deb...@googlemail.com> wrote: > > gcc-7[.2] was really gcc-7.3-rc for a while, and was doing a good job > at enabling Spectre mitigation (as tested by the > spectre-meltdown-checker and /sys/device

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

nto the thread this late, I didn't follow the >>> beginning. >>> You can save yourself quite a bit of hassle by downloading the upstream >>> up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7. >>> All you need is there already and you will

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

the upstream up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7. All you need is there already and you will get as good a mitigation for Spectre as one can get right now. well, I just saw that gcc-7.3 arrived in sid today, so at least the issues with gcc-8 from experimental se

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

p-to-date vanilla kernel 4.15-rc9 and compile that with > > Unstable gcc-7. All you need is there already and you will get as > > good a mitigation for Spectre as one can get right now. > > > ​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compile the > spectr

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

pstream >> up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7. >> All you need is there already and you will get as good a mitigation for >> Spectre as one can get right now. > > > ​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compi

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

e vanilla kernel 4.15-rc9 and compile that with > Unstable gcc-7. All you need is there already and you will get as good > a mitigation for Spectre as one can get right now. well, I just saw that gcc-7.3 arrived in sid today, so at least the issues with gcc-8 from experimental seem to be history

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

On Fri, Jan 26, 2018 at 04:17:27PM +, Michael Fothergill wrote: > ​Is the sid gcc now 7.3 as someone said earlier even though it says it is > 7.2? Sid apparently has both "gcc" and "gcc-7" packages. https://packages.debian.org/sid/gcc shows version 7.2.0-1d1. https

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

>> > Hi, sorry to jump into the thread this late, I didn't follow the beginning. > You can save yourself quite a bit of hassle by downloading the upstream > up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7. > All you need is there already and yo

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

if you don't want to give up yet :-) Don't try to force the use of gcc-8 until you know that everything runs properly with the default compiler. Maybe you should follow the advice from the previously posted error message: "make[2]: Entering directory '/usr/src/linux-4.14.15' Makefile:942: ***

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

libelf-dev, libelf-devel or > > elfutils-libelf-devel". Stop." > > ^ > > > > ​Many thanks. I can think of some things that might help a bit here. > > 1. I could try out the ​ > gcc-h...@gcc.gnu.o

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

t; > the patch checker could confirm has these meltdown and spectre fixes > > are properly set up and active. > > Ok, my advice if you don't want to give up yet :-) > > Don't try to force the use of gcc-8 until you know that everything runs > properly with the default compi

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......

4.14.15 does have the KPTI and retpoline patches in it, so > it is a fair candidate for the GCC8 compiler to produce a kernel that > the patch checker could confirm has these meltdown and spectre fixes > are properly set up and active. Ok, my advice if you don't want to give up yet :-) Don't try

kernel 4.14.15 compilation using GCC 8 in unstable.......

Dear All, I am continuing the discussion of the kernel 4.14.15 compilation in the Question on CVE-2017-5754 on Debian 8.9 post in a new post. The reason I am running with this kernel and not the 4.15.0 rc9 kernel that is now available on kernel.org is that: 1. It is stable 2. I have never

Re: how to check GCC default C standard

On 09/26/2017 06:22 PM, Michael Stone wrote: > On Mon, Sep 25, 2017 at 05:10:32PM +, 慕 冬亮 wrote: >> how do I check the default C standard GCC uses? I check "gcc -v"(list >> below), but nothing is found. > > the default is to not be standards compliant. if you

Re: how to check GCC default C standard

On Mon, Sep 25, 2017 at 05:10:32PM +, 慕 冬亮 wrote: how do I check the default C standard GCC uses? I check "gcc -v"(list below), but nothing is found. the default is to not be standards compliant. if you need a specific standard you should specify it (e.g., -std=c11) gcc ver

how to check GCC default C standard

Hi all, how do I check the default C standard GCC uses? I check "gcc -v"(list below), but nothing is found. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Targ

extracted-rpm bin files and gcc executables on GNUroot debian on Android phone/device

Hi, I'm using GNUroot Debian bash on my Anroid phone. While I have been to install many packages like java, python, ruby, node.js, scala, groovy via apt-get install and use them to write and run programs, I'm finding difficulty with extracted rpm files and gcc executables. That is, they come

Re: In Stretch, gcc producing position independent binaries by default?

Hi. On Sat, 15 Apr 2017 14:39:49 + (UTC) Neoklis Kyriazis <nkcy...@yahoo.com> wrote: > > >They patched gcc to produce PIE by default - and that's one of Debian > >stretch release goals. See: > > > >https://wiki.debian.org/Hardening/PIEByDefault

Re: In Stretch, gcc producing position independent binaries by default?

Hi. On Sat, 15 Apr 2017 13:50:59 + (UTC) Neoklis Kyriazis <nkcy...@yahoo.com> wrote: > Hi, > > I have recently completed my first installation of Debian (stretch) > and I am compiling some apps from source. I have noticed that filers > show binaries produce b

Re: gcc-doc in stretch

Thanks for clarifying. On Sat, Aug 6, 2016 at 7:32 AM, Christian Seiler <christ...@iwakd.de> wrote: > On 08/06/2016 04:08 PM, Steven Tan wrote: > > https://packages.debian.org/search?keywords=gcc-doc; > searchon=names=all=all > > It looks like the package gcc-doc is

Re: gcc-doc in stretch

On 08/06/2016 04:08 PM, Steven Tan wrote: > https://packages.debian.org/search?keywords=gcc-doc=names=all=all > It looks like the package gcc-doc is not provided in stretch, not even in > contrib or non-free, but the package is provided in jessie and sid. > > Is this a bug or

gcc-doc in stretch

Hi, https://packages.debian.org/search?keywords=gcc-doc=names=all=all It looks like the package gcc-doc is not provided in stretch, not even in contrib or non-free, but the package is provided in jessie and sid. Is this a bug or intended? Thank you.

Re: make oldconfig bzImage with GCC 4.9.2 on debian 8

Dhiraj Bhor wrote: Is there any clue to proceed with this query? I compiled many kernels from the 2.6.26 - 2.6.37 in chrooted i386 environment with gcc-4.7 it works pretty well for me. To me it looks like the patches you apply mess up something. regards -- To UNSUBSCRIBE, email to debian

Re: make oldconfig bzImage with GCC 4.9.2 on debian 8

On Wed, 2015-06-03 at 10:05 +0530, Dhiraj Bhor wrote: Is there any clue to proceed with this query? No idea. My suggestion was made after googling your problem for a couple of minutes. If this is for a school or uni project, you should really talk to the people in charge and ask them to use a

Re: make oldconfig bzImage with GCC 4.9.2 on debian 8

Is there any clue to proceed with this query? On Fri, May 29, 2015 at 9:54 AM, Dhiraj Bhor dhirajbho...@gmail.com wrote: Can anyone help me out. On Thu, May 28, 2015 at 12:47 PM, Dhiraj Bhor dhirajbho...@gmail.com wrote: Hi Sven, I applied the patch suggested but it did not worked for

Re: make oldconfig bzImage with GCC 4.9.2 on debian 8

Can anyone help me out. On Thu, May 28, 2015 at 12:47 PM, Dhiraj Bhor dhirajbho...@gmail.com wrote: Hi Sven, I applied the patch suggested but it did not worked for me. I wanted to let you know that i am compiling kernel version 2.6.20 and given link has patch applicable for 2.6.27 which

make oldconfig bzImage with GCC 4.9.2 on debian 8

Hi all, I am compiling https://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.tar.bz2 I have gcc 4.9.2 installed on my Debbian 8.0. I have compiled linux-kernel-2.6.32 on this box. Somebody may point out that this is old version and i do not waste time in compile but this is requirement and i

Re: make oldconfig bzImage with GCC 4.9.2 on debian 8

On Tue, 2015-05-26 at 16:37 +0530, Dhiraj Bhor wrote: After this i got some error while make bzImage as follows: [...] *kernel/built-in.o: In function `mutex_lock':* *(.sched.text+0xea5): undefined reference to `__mutex_lock_slowpath'* *kernel/built-in.o: In function `mutex_unlock':*

make oldconfig bzImage fails under GCC-4.9.2 on debian-8.0

Hi, I am compiling the linux kernel 2.6.32 with my custom config file as input. I am using gcc-4.9.2 on Debian-8.0. I am getting following error. build@bd:~/2.6.32/linux-2.6.32-358.el6$ make oldconfig bzImage scripts/kconfig/conf -o arch/x86/Kconfig # # configuration written to .config # scripts

gcc and associated pkgs

What versions of gcc is it safe to remove? I have gcc 4.{1..8} installed on a box, and I'm fairly sure I can get rid of at least 4.1 - 4.6. Also, what associated packages should be removed with it? Should I get rid of equivalent versions of gcc, gcc-base, cpp? Anything else? Thanks, --b

Re: gcc and associated pkgs

On Sun, Feb 09, 2014 at 06:29:27PM -0500, Brad Alexander wrote: What versions of gcc is it safe to remove? I have gcc 4.{1..8} installed on a box, and I'm fairly sure I can get rid of at least 4.1 - 4.6. Also, what associated packages should be removed with it? Should I get rid of equivalent

Package gcc-msp430 not available in testing ...

Hello, I've just installed Debian testing / jessie with the intention to do some development with the msp430 mcu. Unfortunatly the needed package gcc-msp430 is unavailable in testing. Some information about the why can be found here: http://packages.qa.debian.org/g/gcc-msp430.html It looks

Re: MIT discovered issue with gcc

... And, according to the article that started this thread, isn't going to do the job, either, since many of our primary compilers now optimize more than they are able to warn about even at the lowest level of optimization. What about adding cppcheck warnings and gcc -Wall -pedantic be added to Lintian

Re: MIT discovered issue with gcc

Ick. On Thu, Nov 28, 2013 at 8:28 PM, Joel Rees joel.r...@gmail.com wrote: On Thu, Nov 28, 2013 at 6:10 AM, Wade Richards w...@wabyn.net wrote: [...] I'm taking a course in embedded programming at the local employment training center to brush up on skills I never lost, for reasons that I

Re: MIT discovered issue with gcc [OT]

On 28/11/13 22:33, Joel Rees wrote: snipped [...] Uninitialized pointers in my thought processes. Made perfect sense to me. I use ld.so.preload for everything. It's great. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe.

Re: MIT discovered issue with gcc

On 11/28/2013 03:28 AM, Joel Rees wrote: And, according to the article that started this thread, isn't going to do the job, either, since many of our primary compilers now optimize more than they are able to warn about even at the lowest level of optimization. This should be enough to throw

Re: MIT discovered issue with gcc

as they are found, or (2) recompile all packages with optimizations disabled. I don't think proposal #2 would get very far... Well, there's always -O1 as opposed to no optimization. BTW, -O1 is the minimum permitted for making gcc or glibc, I forget which. I'm rebuilding glibc 2.18 now

Re: MIT discovered issue with gcc

for bugs/vulnerabilities as they are found, or (2) recompile all packages with optimizations disabled. I don't think proposal #2 would get very far... Well, there's always -O1 as opposed to no optimization. BTW, -O1 is the minimum permitted for making gcc or glibc, I forget which. I'm

Re: MIT discovered issue with gcc

permitted for making gcc or glibc, I forget which. I'm rebuilding glibc 2.18 now with -O1 after it refused -O0, but binutils 2.23.2, gcc 4.8.1, and g++ 4.8.1 are fine with -O0. And what was the result of poptck (STACK) when you tested them? I haven't gotten that far yet

Re: MIT discovered issue with gcc

disabled. I don't think proposal #2 would get very far... What about adding cppcheck warnings and gcc -Wall -pedantic be added to Lintian? Or what about changing debhelper to pass some -f flags by default? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject

Re: MIT discovered issue with gcc

: (1) wait for upstream patches for bugs/vulnerabilities as they are found, or (2) recompile all packages with optimizations disabled. I don't think proposal #2 would get very far... What about adding cppcheck warnings and gcc -Wall -pedantic be added to Lintian? Or what about changing

Re: MIT discovered issue with gcc

On 27/11/13 13:10, Wade Richards wrote: Also, the deeper you get into the optimized code, the harder it is to issue meaningful source-level warnings. E.g. when the compiler optimizes: static int decimate(x) { return x/10; } int foo() { int a=INT_MAX; int b; for(i=0; i100; ++i) {

Re: MIT discovered issue with gcc

On Mon, Nov 25, 2013 at 03:10:07PM -0700, Bob Proulx wrote: In those systems the zero page is initially bit-zero and reading from the zero point will return zero values from the contents there. If the program writes to the zero page then subsequent reads will return whatever was written there.

Re: MIT discovered issue with gcc

for WAY upstream - i.e., if gcc's optimizer is opening a class of security holes - then it's gcc that has to be fixed, after which that class of holes would go away after the next build of any impacted package. Miles Fidelman -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org

Re: MIT discovered issue with gcc

Miles, the GCC developers don't consider this to be a bug, and so I doubt that any of it will be fixed. For example, here is a bug cited in the paper: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 If you have a moment, read through that thread. It gets pretty testy as the developers argue

Re: MIT discovered issue with gcc

Wow... that really is kind of testy. And... point taken. Mark Haase wrote: Miles, the GCC developers don't consider this to be a bug, and so I doubt that any of it will be fixed. For example, here is a bug cited in the paper: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 If you have

Re: MIT discovered issue with gcc

as opposed to no optimization. BTW, -O1 is the minimum permitted for making gcc or glibc, I forget which. -- not cent from sell May the LORD God bless you exceedingly abundantly! Dave_Craig__ So the universe is not quite as you thought it was. You'd

Re: MIT discovered issue with gcc

* Bob Proulx: In those systems the zero page is initially bit-zero and reading from the zero point will return zero values from the contents there. If the program writes to the zero page then subsequent reads will return whatever was written there. This is bad behavior that was the default

Re: MIT discovered issue with gcc

#2 would get very far... Well, there's always -O1 as opposed to no optimization. BTW, -O1 is the minimum permitted for making gcc or glibc, I forget which. I'm rebuilding glibc 2.18 now with -O1 after it refused -O0, but binutils 2.23.2, gcc 4.8.1, and g++ 4.8.1 are fine with -O0

Re: MIT discovered issue with gcc

with optimizations disabled. I don't think proposal #2 would get very far... Well, there's always -O1 as opposed to no optimization. BTW, -O1 is the minimum permitted for making gcc or glibc, I forget which. I'm rebuilding glibc 2.18 now with -O1 after it refused -O0, but binutils 2.23.2, gcc 4.8.1

Re: MIT discovered issue with gcc

On 25/11/2013 12:15 AM, Henrique de Moraes Holschuh wrote: Well, my best guess is that this is going to be considered upstream issues by the majority of the package maintainers, and thus they won't get much attention downstream (in Debian) until they start causing large headaches. That's my

Re: MIT discovered issue with gcc

Robert Baron robertbartlettba...@gmail.com writes: Aren't many of the  constructs used as examples in the paper are commonly used in c programming.  For example it is very common to see a function that has a pointer as a parameter defined as: int func(void *ptr)     {     if(!ptr) return

Re: MIT discovered issue with gcc

Robert Baron robertbartlettba...@gmail.com writes: Second question: Doesn't memcpy allow for overlapping memory, but strcpy does not?  Isn't this why memcpy is preferred over strcpy? According to the man page for memcpy, The memory areas must not overlap. Use memmove(3) if the memory

Re: MIT discovered issue with gcc

Robert Baron wrote: struct tun_struct *tun=; struct sock *sk = tun-sk; if(*tun) return POLLERR; The check to see that tun is non-null should occur before use, as in - quite frankly it is useless to check after as tun cannot be the null pointer (the program hasn't crashed): In Debian

Re: MIT discovered issue with gcc

show up at -O0 and not at -O2, for example). Obviously these are an issue for Debian. Not only we'd like to be able to use c-lang/llvm as a real alternative in the not-too-distant future (say, 3 years from now), and that would likely awaken many of these latent bugs, but also any major gcc upgrade

Re: MIT discovered issue with gcc

Hi Andrew, hi all, I understand that Debian has a bunch of vulnerabilities as described in the following PDF. http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf Just a small quote: This paper presents the first systematic approach for reasoning about and detecting unstable code. We

Re: MIT discovered issue with gcc

On Sat, Nov 23, 2013 at 6:18 AM, Michael Tautschnig m...@debian.org wrote: This looks very serious indeed, but a quick search of Debian mailing lists didn't show anything being acknowledged for this issue should Debian users be concerned? Probably not more than before, but as

Re: MIT discovered issue with gcc

Deja gnu? On Sat, Nov 23, 2013 at 10:34 AM, Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote: Hi, The following link shows the issue in a nutshell: http://www.securitycurrent.com/en/research/ac_research/mot-researchers-uncover-security-flaws-in-c [it refers to the PDF that I

Re: MIT discovered issue with gcc

Aren't many of the constructs used as examples in the paper are commonly used in c programming. For example it is very common to see a function that has a pointer as a parameter defined as: int func(void *ptr) { if(!ptr) return SOME_ERROR; /* rest of function*/ return 1; }

Re: MIT discovered issue with gcc

Second question: Doesn't memcpy allow for overlapping memory, but strcpy does not? Isn't this why memcpy is preferred over strcpy? On Sat, Nov 23, 2013 at 10:09 AM, Robert Baron robertbartlettba...@gmail.com wrote: Aren't many of the constructs used as examples in the paper are commonly

Re: MIT discovered issue with gcc

On 2013-11-23 15:18, Robert Baron wrote: Second question: Doesn't memcpy allow for overlapping memory, but strcpy does not? Isn't this why memcpy is preferred over strcpy? IIRC memcpy does not, but memmove does. See: http://linux.die.net/man/3/memcpy -- To UNSUBSCRIBE, email to

Re: MIT discovered issue with gcc

[...] Isn't it interesting that their one example will potentially dereference the null pointer even before compiler optimizations (from the paper): struct tun_struct *tun=; struct sock *sk = tun-sk; if(*tun) return POLLERR; The check to see that tun is non-null should occur before

Re: MIT discovered issue with gcc

The researchers' point was that an attacker might be able to remap that memory page so that dereferencing a null pointer would NOT segfault. (I don't actually know how feasible this is; I'm just paraphrasing their argument. They footnote this claim but I didn't bother to read the cited

Re: MIT discovered issue with gcc

On Sat, Nov 23, 2013 at 1:16 PM, Mark Haase mark.ha...@lunarline.com wrote: Anyway, I don't see what this has to do with Debian. It's an interesting paper, but Debian can't find and fix all upstream bugs, nor do I think most users would be happy if suddenly everything was compiled without any

Re: MIT discovered issue with gcc

detected at least one instance of unstable code. So 3471 Wheezy packages had one ore more instances of gcc introduced anomalies. And the kernel binary they tested had 32. As an end user I'm not worried about this at all. But I'd think developers may want to start taking a closer look at how gcc

Re: MIT discovered issue with gcc

On Saturday, November 23, 2013 04:23:05 PM Stan Hoeppner wrote: I didn't read the full paper yet, but I'm wondering how/if the optimization flag plays a part in this. I.e. does O2 produce these bugs but OO (default) or Og (debugging) does not? Or -O3... -- To UNSUBSCRIBE, email to

Re: MIT discovered issue with gcc

[Not sure this really needs to be cc-ed to security@] On Sun, Nov 24, 2013 at 12:09 AM, Robert Baron robertbartlettba...@gmail.com wrote: Aren't many of the constructs used as examples in the paper are commonly used in c programming. For example it is very common to see a function that has a

Re: MIT discovered issue with gcc

On Sun, Nov 24, 2013 at 12:18 AM, Robert Baron robertbartlettba...@gmail.com wrote: Second question: Doesn't memcpy allow for overlapping memory, but strcpy does not? Isn't this why memcpy is preferred over strcpy? [...] The reason memcpy() is preferred over strcpy() is the same as the

Re: MIT discovered issue with gcc

of 17432 packages contained C/C++ code. For a whopping 3471 packages, STACK detected at least one instance of unstable code. So 3471 Wheezy packages had one ore more instances of gcc introduced anomalies. And the kernel binary they tested had 32. As an end user I'm not worried about

Re: MIT discovered issue with gcc

On Sun, Nov 24, 2013 at 3:53 AM, Darius Jahandarie wrote: Although Debian *developers* can't find and fix all upstream bugs, the Debian project, as the funnel between code and users, provides an interesting location to perform this sort of automated static analysis on all source code flowing

MIT discovered issue with gcc

Hi, I understand that Debian has a bunch of vulnerabilities as described in the following PDF. http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf Just a small quote: This paper presents the first systematic approach for reasoning about and detecting unstable code. We implement this approach

Re: MIT discovered issue with gcc

Hi, The following link shows the issue in a nutshell: http://www.securitycurrent.com/en/research/ac_research/mot-researchers-uncover-security-flaws-in-c [it refers to the PDF that I mentioned] -- Kind Regards AndrewM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a

Re: Reg: gcc option for printing large number (large double)

\n, temp); return 0; } I compiled and ran as below: [balamurugan@balamurugan C_Programs]$ gcc test.c -o test [balamurugan@balamurugan C_Programs]$ ./test The value of temp is _inf_ But for the same expression, I am able to get the value from python, [balamurugan@balamurugan

Re: Reg: gcc option for printing large number (large double)

: 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00 2^2000 as double: inf 2^2000 as long double: inf - I compiled and ran as below: [balamurugan@balamurugan C_Programs]$ gcc test.c -o test [balamurugan@balamurugan C_Programs]$ ./test The value

Re: Reg: gcc option for printing large number (large double)

On 09/09/13 07:21, Joel Rees wrote: snip code and stuff Not sure why neither man -k nor whereis can find float.h, but it compiles okay. dom@oz:~$ locate float.h /usr/lib/gcc/i486-linux-gnu/4.6/include/float.h /usr/lib/gcc/i486-linux-gnu/4.7/include/float.h /usr/lib/pymodules/python2.6/numpy

<    1   2   3   4   5   6   7   8   9   10   >