[cip-dev] Testing CIP kernel with Debian gcc

[cip-dev] Testing CIP kernel with Debian gcc

[kazuhiro3.hayashi at toshiba.co.jp]

Hello Chris,

I would like to put this topic from IRC in cip-dev as well :-)

My current opinion is:
> at least, CIP will support the following version combinations:
> 4.4 + stretch, 4.19 + stretch, 4.19 + buster
> So, the above kernel versions should be tested with gcc of each Debian version

> Will this testing happen as part of cip-core testing?
> Or do I need to build each Kernel config with multiple GCC versions?
I think that it takes much time to test all combinations
of kernel(2) x configs(30?) x gcc(2) in the current kernel testing.

GCC versions in Debian 9/10
stretch: https://packages.debian.org/stretch/gcc (6.3.0-*)
buster: https://packages.debian.org/buster/gcc (8.3.0-*)

Here is my idea about how to test them:

* In the kernel testing,
  use gcc 6.3(Debian 9) for kernel 4.4, and
  use gcc 8.3(Debian 10) for kernel 4.19

* In CIP core testing,
  do test the three combinations above for
  at least one CIP reference hardware [*]

[*] Regarding CIP core testing, we need to create test matrix
    (kernel x Debian version x Reference hardware)
    then decide which conditions should be tested considering the overwraps.
    How many devices are actually tested depends on this matrix.

What do you think?

Best regards,
Kazu

[cip-dev] Testing CIP kernel with Debian gcc

[Chris Paterson]

Hello Kazu-san,

> From: kazuhiro3.hayashi at toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
> Sent: 08 August 2019 11:48
> 
> Hello Chris,
> 
> I would like to put this topic from IRC in cip-dev as well :-)
> 
> My current opinion is:
> > at least, CIP will support the following version combinations:
> > 4.4 + stretch, 4.19 + stretch, 4.19 + buster
> > So, the above kernel versions should be tested with gcc of each Debian
> version
> 
> > Will this testing happen as part of cip-core testing?
> > Or do I need to build each Kernel config with multiple GCC versions?
> I think that it takes much time to test all combinations
> of kernel(2) x configs(30?) x gcc(2) in the current kernel testing.

Indeed it would.
Although we could of course throw money at the problem to make it quicker if there was really a need.

> 
> GCC versions in Debian 9/10
> stretch: https://packages.debian.org/stretch/gcc (6.3.0-*)
> buster: https://packages.debian.org/buster/gcc (8.3.0-*)

And jessie: https://packages.debian.org/jessie/gcc (4.9.2-*) ?

> 
> Here is my idea about how to test them:
> 
> * In the kernel testing,
>   use gcc 6.3(Debian 9) for kernel 4.4, and
>   use gcc 8.3(Debian 10) for kernel 4.19

I see no problem with this, although it would be good to get input from the Kernel maintainers.

Do Debian make any changes/fixes in their gcc package?

The packages provided in the links above are presumably for compiling in the native system.
Does Debian provide suitable packages for cross-compiling?

For example I'm currently using the packages provided on kernel.org [0] which cover pretty much every build/target combination.
But there is nothing for v6.3 or v8.3

[0] https://cdn.kernel.org/pub/tools/crosstool/files/bin

Of course I could just build all the cross-compilers from source when I create the build container...

> 
> * In CIP core testing,
>   do test the three combinations above for
>   at least one CIP reference hardware [*]
> 
> [*] Regarding CIP core testing, we need to create test matrix
>     (kernel x Debian version x Reference hardware)
>     then decide which conditions should be tested considering the overwraps.
>     How many devices are actually tested depends on this matrix.

This would be useful.

Kind regards, Chris

> 
> What do you think?
> 
> Best regards,
> Kazu

[cip-dev] Testing CIP kernel with Debian gcc

[Nobuhiro Iwamatsu]

Hi,

2019?8?8?(?) 21:05 Chris Paterson <Chris.Paterson2@renesas.com>:
>
> Hello Kazu-san,
>
> > From: kazuhiro3.hayashi at toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
> > Sent: 08 August 2019 11:48
> >
> > Hello Chris,
> >
> > I would like to put this topic from IRC in cip-dev as well :-)
> >
> > My current opinion is:
> > > at least, CIP will support the following version combinations:
> > > 4.4 + stretch, 4.19 + stretch, 4.19 + buster
> > > So, the above kernel versions should be tested with gcc of each Debian
> > version
> >
> > > Will this testing happen as part of cip-core testing?
> > > Or do I need to build each Kernel config with multiple GCC versions?
> > I think that it takes much time to test all combinations
> > of kernel(2) x configs(30?) x gcc(2) in the current kernel testing.
>
> Indeed it would.
> Although we could of course throw money at the problem to make it quicker if there was really a need.
>
> >
> > GCC versions in Debian 9/10
> > stretch: https://packages.debian.org/stretch/gcc (6.3.0-*)
> > buster: https://packages.debian.org/buster/gcc (8.3.0-*)
>
> And jessie: https://packages.debian.org/jessie/gcc (4.9.2-*) ?
>
> >
> > Here is my idea about how to test them:
> >
> > * In the kernel testing,
> >   use gcc 6.3(Debian 9) for kernel 4.4, and
> >   use gcc 8.3(Debian 10) for kernel 4.19
>
> I see no problem with this, although it would be good to get input from the Kernel maintainers.
>
> Do Debian make any changes/fixes in their gcc package?
>
> The packages provided in the links above are presumably for compiling in the native system.
> Does Debian provide suitable packages for cross-compiling?
>
> For example I'm currently using the packages provided on kernel.org [0] which cover pretty much every build/target combination.
> But there is nothing for v6.3 or v8.3
>
> [0] https://cdn.kernel.org/pub/tools/crosstool/files/bin
>
> Of course I could just build all the cross-compilers from source when I create the build container...

If we use Debian, we can use cross toolchain packages.
But this depends on the distribution. buster provides a cross-tool
chain for gcc-8 but not gcc-6.
  - https://tracker.debian.org/pkg/gcc-8-cross
  - https://tracker.debian.org/pkg/gcc-6-cross

Best regards,
  Nobuhiro

--
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

[cip-dev] Testing CIP kernel with Debian gcc

[Ben Hutchings]

On Thu, 2019-08-08 at 12:05 +0000, Chris Paterson wrote:
[...]
> Do Debian make any changes/fixes in their gcc package?

Yes, they are usually snapshots of a release branch, with some cherry-
picked fixes e.g. for gcc-8 in buster the latest changelog entry is:

gcc-8 (8.3.0-6) unstable; urgency=medium

  * Update to SVN 20190406 (r270182) from the gcc-8-branch.
    - Fix PR middle-end/89934, PR lto/89896.
  * Fix PR fortran/89981, taken from the trunk.

 -- Matthias Klose <doko@debian.org>  Sat, 06 Apr 2019 16:44:55 +0200

Older gcc packages also have backports of retpoline support.

> The packages provided in the links above are presumably for compiling in the native system.
> Does Debian provide suitable packages for cross-compiling?
[...]

Yes, starting with stretch there are cross-compilers for x86 and arm64
targetting most release architectures.  They are named gcc-<major>-
<triplet>, e.g. gcc-8-arm-linux-gnueabihf (except that x86_64 is
changed to x86-64 since underscores aren't allowed in package names).

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

[cip-dev] Testing CIP kernel with Debian gcc

[Chris Paterson]

> From: Ben Hutchings <ben.hutchings@codethink.co.uk>
> Sent: 09 August 2019 14:03
> 
> On Thu, 2019-08-08 at 12:05 +0000, Chris Paterson wrote:
> [...]
> > Do Debian make any changes/fixes in their gcc package?
> 
> Yes, they are usually snapshots of a release branch, with some cherry-
> picked fixes e.g. for gcc-8 in buster the latest changelog entry is:
> 
> gcc-8 (8.3.0-6) unstable; urgency=medium
> 
>   * Update to SVN 20190406 (r270182) from the gcc-8-branch.
>     - Fix PR middle-end/89934, PR lto/89896.
>   * Fix PR fortran/89981, taken from the trunk.
> 
>  -- Matthias Klose <doko@debian.org>  Sat, 06 Apr 2019 16:44:55 +0200
> 
> Older gcc packages also have backports of retpoline support.
> 
> > The packages provided in the links above are presumably for compiling in
> the native system.
> > Does Debian provide suitable packages for cross-compiling?
> [...]
> 
> Yes, starting with stretch there are cross-compilers for x86 and arm64
> targetting most release architectures.  They are named gcc-<major>-
> <triplet>, e.g. gcc-8-arm-linux-gnueabihf (except that x86_64 is
> changed to x86-64 since underscores aren't allowed in package names).

Thank you Ben and Iwamatsu-san.

I'll take do some experiments.

Chris


> 
> Ben.
> 
> --
> Ben Hutchings, Software Developer                         Codethink Ltd
> https://www.codethink.co.uk/                 Dale House, 35 Dale Street
>                                      Manchester, M1 2HF, United Kingdom

[cip-dev] Testing CIP kernel with Debian gcc

[SZ Lin (林上智)]

Hi all,

According to the discussion in IRC weekly meeting last week, do we
want to add extra compiler options (e.g., security hardening) in CIP
development? Or use origin setting from Debian package.

I also attached Debian gcc 6.3 and 8.3 options below

Any feedback is appreciated.

SZ

== Debian 9 gcc 6.3 options ==
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
==

== Debian 10 gcc 8.3 options ==
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
8.3.0-19' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto --enable-link-mutex
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-19)
==

Ben Hutchings <ben.hutchings@codethink.co.uk> ? 2019?8?9? ?? ??9:05???
>
> On Thu, 2019-08-08 at 12:05 +0000, Chris Paterson wrote:
> [...]
> > Do Debian make any changes/fixes in their gcc package?
>
> Yes, they are usually snapshots of a release branch, with some cherry-
> picked fixes e.g. for gcc-8 in buster the latest changelog entry is:
>
> gcc-8 (8.3.0-6) unstable; urgency=medium
>
>   * Update to SVN 20190406 (r270182) from the gcc-8-branch.
>     - Fix PR middle-end/89934, PR lto/89896.
>   * Fix PR fortran/89981, taken from the trunk.
>
>  -- Matthias Klose <doko@debian.org>  Sat, 06 Apr 2019 16:44:55 +0200
>
> Older gcc packages also have backports of retpoline support.
>
> > The packages provided in the links above are presumably for compiling in the native system.
> > Does Debian provide suitable packages for cross-compiling?
> [...]
>
> Yes, starting with stretch there are cross-compilers for x86 and arm64
> targetting most release architectures.  They are named gcc-<major>-
> <triplet>, e.g. gcc-8-arm-linux-gnueabihf (except that x86_64 is
> changed to x86-64 since underscores aren't allowed in package names).
>
> Ben.
>
> --
> Ben Hutchings, Software Developer                         Codethink Ltd
> https://www.codethink.co.uk/                 Dale House, 35 Dale Street
>                                      Manchester, M1 2HF, United Kingdom
>
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

[cip-dev] [Cip-security] Testing CIP kernel with Debian gcc

[Demirci, Yasin]

Hello Lin-san,

I'm not sure about the consequences of the two different approaches.
However I thought we want to make security a mandatory feature in CIP so an optional removal would not be planned?

Best Regards
Yasin

-----Urspr?ngliche Nachricht-----
Von: cip-security-bounces at lists.cip-project.org <cip-security-bounces@lists.cip-project.org> Im Auftrag von SZ Lin (???)
Gesendet: Donnerstag, 15. August 2019 04:51
An: cip-dev at lists.cip-project.org; cip-security at lists.cip-project.org
Cc: pavel at denx.de; Ben Hutchings <ben.hutchings@codethink.co.uk>; Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Betreff: Re: [Cip-security] [cip-dev] Testing CIP kernel with Debian gcc

Hi all,

According to the discussion in IRC weekly meeting last week, do we want to add extra compiler options (e.g., security hardening) in CIP development? Or use origin setting from Debian package.

I also attached Debian gcc 6.3 and 8.3 options below

Any feedback is appreciated.

SZ

== Debian 9 gcc 6.3 options ==
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ==

== Debian 10 gcc 8.3 options ==
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-19' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto --enable-link-mutex Thread model: posix gcc version 8.3.0 (Debian 8.3.0-19) ==

Ben Hutchings <ben.hutchings@codethink.co.uk> ? 2019?8?9? ?? ??9:05???
>
> On Thu, 2019-08-08 at 12:05 +0000, Chris Paterson wrote:
> [...]
> > Do Debian make any changes/fixes in their gcc package?
>
> Yes, they are usually snapshots of a release branch, with some cherry- 
> picked fixes e.g. for gcc-8 in buster the latest changelog entry is:
>
> gcc-8 (8.3.0-6) unstable; urgency=medium
>
>   * Update to SVN 20190406 (r270182) from the gcc-8-branch.
>     - Fix PR middle-end/89934, PR lto/89896.
>   * Fix PR fortran/89981, taken from the trunk.
>
>  -- Matthias Klose <doko@debian.org>  Sat, 06 Apr 2019 16:44:55 +0200
>
> Older gcc packages also have backports of retpoline support.
>
> > The packages provided in the links above are presumably for compiling in the native system.
> > Does Debian provide suitable packages for cross-compiling?
> [...]
>
> Yes, starting with stretch there are cross-compilers for x86 and arm64 
> targetting most release architectures.  They are named gcc-<major>- 
> <triplet>, e.g. gcc-8-arm-linux-gnueabihf (except that x86_64 is 
> changed to x86-64 since underscores aren't allowed in package names).
>
> Ben.
>
> --
> Ben Hutchings, Software Developer                         Codethink Ltd
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.codethink.co.uk%2F&amp;data=02%7C01%7Cyasin.demirci%40siemens.com%7Cce7f021bcba74953d9a908d7212b6575%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637014342590931622&amp;sdata=EWVK36tc%2FQ3F5czxC%2Fbt8uC28Ej0zptuBBLDcjOIe8g%3D&amp;reserved=0                 Dale House, 35 Dale Street
>                                      Manchester, M1 2HF, United 
> Kingdom
>
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.cip-project.org%2Fmailman%2Flistinfo%2Fcip-dev&amp;data=02%7C01%7Cya
> sin.demirci%40siemens.com%7Cce7f021bcba74953d9a908d7212b6575%7C38ae3bc
> d95794fd4addab42e1495d55a%7C1%7C0%7C637014342590931622&amp;sdata=RKknv
> i5KP616jx33TDg4NpK3RhHSOr4k1wJeFR%2FTZKM%3D&amp;reserved=0
_______________________________________________
Cip-security mailing list
Cip-security at lists.cip-project.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cip-project.org%2Fmailman%2Flistinfo%2Fcip-security&amp;data=02%7C01%7Cyasin.demirci%40siemens.com%7Cce7f021bcba74953d9a908d7212b6575%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637014342590931622&amp;sdata=MqI70UA3fjV33uZIU7cZZKzCby0r5I6HUZZqmd%2FvfDc%3D&amp;reserved=0

[cip-dev] Testing CIP kernel with Debian gcc

[Ben Hutchings]

On Thu, 2019-08-15 at 10:50 +0800, SZ Lin (???) wrote:
> Hi all,
> 
> According to the discussion in IRC weekly meeting last week, do we
> want to add extra compiler options (e.g., security hardening) in CIP
> development? Or use origin setting from Debian package.
> 
> I also attached Debian gcc 6.3 and 8.3 options below

So far as I could see, the only hardening option enabled there is PIE.
That's good for user-space but can't be used in the kernel (currently).

> Any feedback is appreciated.

There is another source of default tool-chain options for *packages*,
which is dpkg-buildflags.  In buster that enables most hardening
options by default.  Most packages will set the tool-chain options
using dpkg-buildflags (dh does so automatically), but this would need
to be checked for each package.  And this doesn't help to harden
unpackaged software that members include in their systems.

For the kernel, hardening options can require (arch-dependent) code to
support them because the kernel does not use the C library or even the
gcc runtime library.  So the kernel build system generally requires
them to be explicitly enabled in Kconfig, and will override them if
they're enabled in default compiler options but not Kconfig.

So I think that changing the default tool-chain options may be worth
doing for user-space software, but the kernel will still need to be
handled separately.

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

[cip-dev] [Cip-security] Testing CIP kernel with Debian gcc

[SZ Lin (林上智)]

Hi Yasin,

> From: Demirci, Yasin <yasin.demirci@siemens.com>
> 
> Hello Lin-san,
> 
> I'm not sure about the consequences of the two different approaches.

It mainly depends on your Debian version, gcc 6.3 is for Debian 9 and gcc 8.3 is for Debian 10.

> However I thought we want to make security a mandatory feature in CIP so an
> optional removal would not be planned?

Yes, but there're many security options in gcc (e.g., -fstack-protector), and thus we've to
decide which kind of hardening options do we (cip-security) need.

SZ
> 
> Best Regards
> Yasin
> 
> -----Urspr?ngliche Nachricht-----
> Von: cip-security-bounces at lists.cip-project.org
> <cip-security-bounces@lists.cip-project.org> Im Auftrag von SZ Lin (???)
> Gesendet: Donnerstag, 15. August 2019 04:51
> An: cip-dev at lists.cip-project.org; cip-security at lists.cip-project.org
> Cc: pavel at denx.de; Ben Hutchings <ben.hutchings@codethink.co.uk>;
> Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> Betreff: Re: [Cip-security] [cip-dev] Testing CIP kernel with Debian gcc
> 
> Hi all,
> 
> According to the discussion in IRC weekly meeting last week, do we want to
> add extra compiler options (e.g., security hardening) in CIP development? Or
> use origin setting from Debian package.
> 
> I also attached Debian gcc 6.3 and 8.3 options below
> 
> Any feedback is appreciated.
> 
> SZ
> 
> == Debian 9 gcc 6.3 options ==
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian
> 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
> --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu-
> --enable-shared --enable-linker-build-id --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
> --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
> --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
> --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
> --enable-plugin --enable-default-pie --with-system-zlib
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
> --enable-java-home
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
> --with-arch-directory=amd64
> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
> --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic --enable-checking=release
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ==
> 
> == Debian 10 gcc 8.3 options ==
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-19'
> --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
> --prefix=/usr --with-gcc-major-version-only --program-suffix=-8
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
> --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
> --enable-multiarch --disable-werror
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
> --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> --with-build-config=bootstrap-lto --enable-link-mutex Thread model: posix gcc
> version 8.3.0 (Debian 8.3.0-19) ==
> 
> Ben Hutchings <ben.hutchings@codethink.co.uk> ? 2019?8?9? ??
> ??9:05???
> >
> > On Thu, 2019-08-08 at 12:05 +0000, Chris Paterson wrote:
> > [...]
> > > Do Debian make any changes/fixes in their gcc package?
> >
> > Yes, they are usually snapshots of a release branch, with some cherry-
> > picked fixes e.g. for gcc-8 in buster the latest changelog entry is:
> >
> > gcc-8 (8.3.0-6) unstable; urgency=medium
> >
> >   * Update to SVN 20190406 (r270182) from the gcc-8-branch.
> >     - Fix PR middle-end/89934, PR lto/89896.
> >   * Fix PR fortran/89981, taken from the trunk.
> >
> >  -- Matthias Klose <doko@debian.org>  Sat, 06 Apr 2019 16:44:55 +0200
> >
> > Older gcc packages also have backports of retpoline support.
> >
> > > The packages provided in the links above are presumably for compiling in
> the native system.
> > > Does Debian provide suitable packages for cross-compiling?
> > [...]
> >
> > Yes, starting with stretch there are cross-compilers for x86 and arm64
> > targetting most release architectures.  They are named gcc-<major>-
> > <triplet>, e.g. gcc-8-arm-linux-gnueabihf (except that x86_64 is
> > changed to x86-64 since underscores aren't allowed in package names).
> >
> > Ben.
> >
> > --
> > Ben Hutchings, Software Developer                         Codethink
> Ltd
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cod
> ethink.co.uk%2F&amp;data=02%7C01%7Cyasin.demirci%40siemens.com%7Cc
> e7f021bcba74953d9a908d7212b6575%7C38ae3bcd95794fd4addab42e1495d5
> 5a%7C1%7C0%7C637014342590931622&amp;sdata=EWVK36tc%2FQ3F5czxC
> %2Fbt8uC28Ej0zptuBBLDcjOIe8g%3D&amp;reserved=0
> Dale House, 35 Dale Street
> >                                      Manchester, M1 2HF, United
> > Kingdom
> >
> > _______________________________________________
> > cip-dev mailing list
> > cip-dev at lists.cip-project.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> >
> s.cip-project.org%2Fmailman%2Flistinfo%2Fcip-dev&amp;data=02%7C01%7Cy
> a
> >
> sin.demirci%40siemens.com%7Cce7f021bcba74953d9a908d7212b6575%7C38
> ae3bc
> >
> d95794fd4addab42e1495d55a%7C1%7C0%7C637014342590931622&amp;sdat
> a=RKknv
> > i5KP616jx33TDg4NpK3RhHSOr4k1wJeFR%2FTZKM%3D&amp;reserved=0
> _______________________________________________
> Cip-security mailing list
> Cip-security at lists.cip-project.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cip-p
> roject.org%2Fmailman%2Flistinfo%2Fcip-security&amp;data=02%7C01%7Cyasi
> n.demirci%40siemens.com%7Cce7f021bcba74953d9a908d7212b6575%7C38ae
> 3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637014342590931622&amp;s
> data=MqI70UA3fjV33uZIU7cZZKzCby0r5I6HUZZqmd%2FvfDc%3D&amp;reserve
> d=0

[cip-dev] Testing CIP kernel with Debian gcc

[SZ Lin (林上智)]

Hi Ben,

> From: Ben Hutchings <ben.hutchings@codethink.co.uk> 
> On Thu, 2019-08-15 at 10:50 +0800, SZ Lin (???) wrote:
> > Hi all,
> >
> > According to the discussion in IRC weekly meeting last week, do we
> > want to add extra compiler options (e.g., security hardening) in CIP
> > development? Or use origin setting from Debian package.
> >
> > I also attached Debian gcc 6.3 and 8.3 options below
> 
> So far as I could see, the only hardening option enabled there is PIE.
> That's good for user-space but can't be used in the kernel (currently).
> 
> > Any feedback is appreciated.
> 
> There is another source of default tool-chain options for *packages*, which is
> dpkg-buildflags.  In buster that enables most hardening options by default.
> Most packages will set the tool-chain options using dpkg-buildflags (dh does so
> automatically), but this would need to be checked for each package.  And this
> doesn't help to harden unpackaged software that members include in their
> systems.

AFAIK, the hardening options are not mandatory to packages [1][2]. That means we've to
check each packages one by one...

[1] https://lintian.debian.org/tags/hardening-no-bindnow.html
[2] https://lintian.debian.org/reports/tags/hardening-no-relro.html

> 
> For the kernel, hardening options can require (arch-dependent) code to support
> them because the kernel does not use the C library or even the gcc runtime
> library.  So the kernel build system generally requires them to be explicitly
> enabled in Kconfig, and will override them if they're enabled in default
> compiler options but not Kconfig.

And the security options might make the impact to the scope of kernel maintenance.

> 
> So I think that changing the default tool-chain options may be worth doing for
> user-space software, but the kernel will still need to be handled separately.

Thanks for your feedback.

We need some feedback from cip-security workgroup as well.

SZ

> 
> Ben.
> 
> --
> Ben Hutchings, Software Developer                         Codethink
> Ltd
> https://www.codethink.co.uk/                 Dale House, 35 Dale Street
>                                      Manchester, M1 2HF, United
> Kingdom

[cip-dev] Testing CIP kernel with Debian gcc

[Dinesh Kumar]

Hi SZ,

>> We need some feedback from cip-security workgroup as well.

We will discuss this point in next security WG meeting (21/Aug) and will update here.

Thanks & Regards,
Dinesh Kumar

-----Original Message-----
From: cip-security-bounces@lists.cip-project.org [mailto:cip-security-bounces at lists.cip-project.org] On Behalf Of SZ Lin (???)
Sent: 20 August 2019 14:24
To: Ben Hutchings <ben.hutchings@codethink.co.uk>; cip-dev at lists.cip-project.org; cip-security at lists.cip-project.org
Cc: pavel at denx.de; Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Subject: Re: [Cip-security] [cip-dev] Testing CIP kernel with Debian gcc

Hi Ben,

> From: Ben Hutchings <ben.hutchings@codethink.co.uk> On Thu, 2019-08-15 
> at 10:50 +0800, SZ Lin (???) wrote:
> > Hi all,
> >
> > According to the discussion in IRC weekly meeting last week, do we 
> > want to add extra compiler options (e.g., security hardening) in CIP 
> > development? Or use origin setting from Debian package.
> >
> > I also attached Debian gcc 6.3 and 8.3 options below
> 
> So far as I could see, the only hardening option enabled there is PIE.
> That's good for user-space but can't be used in the kernel (currently).
> 
> > Any feedback is appreciated.
> 
> There is another source of default tool-chain options for *packages*, 
> which is dpkg-buildflags.  In buster that enables most hardening options by default.
> Most packages will set the tool-chain options using dpkg-buildflags 
> (dh does so automatically), but this would need to be checked for each 
> package.  And this doesn't help to harden unpackaged software that 
> members include in their systems.

AFAIK, the hardening options are not mandatory to packages [1][2]. That means we've to check each packages one by one...

[1] https://lintian.debian.org/tags/hardening-no-bindnow.html
[2] https://lintian.debian.org/reports/tags/hardening-no-relro.html

> 
> For the kernel, hardening options can require (arch-dependent) code to 
> support them because the kernel does not use the C library or even the 
> gcc runtime library.  So the kernel build system generally requires 
> them to be explicitly enabled in Kconfig, and will override them if 
> they're enabled in default compiler options but not Kconfig.

And the security options might make the impact to the scope of kernel maintenance.

> 
> So I think that changing the default tool-chain options may be worth 
> doing for user-space software, but the kernel will still need to be handled separately.

Thanks for your feedback.

We need some feedback from cip-security workgroup as well.

SZ

> 
> Ben.
> 
> --
> Ben Hutchings, Software Developer                         Codethink
> Ltd
> https://www.codethink.co.uk/                 Dale House, 35 Dale Street
>                                      Manchester, M1 2HF, United 
> Kingdom

_______________________________________________
Cip-security mailing list
Cip-security at lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-security
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

[cip-dev] Testing CIP kernel with Debian gcc

[Jan Kiszka]

On 20.08.19 10:53, SZ Lin (???) wrote:
> Hi Ben,
> 
>> From: Ben Hutchings <ben.hutchings@codethink.co.uk>
>> On Thu, 2019-08-15 at 10:50 +0800, SZ Lin (???) wrote:
>>> Hi all,
>>>
>>> According to the discussion in IRC weekly meeting last week, do we
>>> want to add extra compiler options (e.g., security hardening) in CIP
>>> development? Or use origin setting from Debian package.
>>>
>>> I also attached Debian gcc 6.3 and 8.3 options below
>>
>> So far as I could see, the only hardening option enabled there is PIE.
>> That's good for user-space but can't be used in the kernel (currently).
>>
>>> Any feedback is appreciated.
>>
>> There is another source of default tool-chain options for *packages*, which is
>> dpkg-buildflags.  In buster that enables most hardening options by default.
>> Most packages will set the tool-chain options using dpkg-buildflags (dh does so
>> automatically), but this would need to be checked for each package.  And this
>> doesn't help to harden unpackaged software that members include in their
>> systems.
> 
> AFAIK, the hardening options are not mandatory to packages [1][2]. That means we've to
> check each packages one by one...
> 
> [1] https://lintian.debian.org/tags/hardening-no-bindnow.html
> [2] https://lintian.debian.org/reports/tags/hardening-no-relro.html
> 
>>
>> For the kernel, hardening options can require (arch-dependent) code to support
>> them because the kernel does not use the C library or even the gcc runtime
>> library.  So the kernel build system generally requires them to be explicitly
>> enabled in Kconfig, and will override them if they're enabled in default
>> compiler options but not Kconfig.
> 
> And the security options might make the impact to the scope of kernel maintenance.
> 
>>
>> So I think that changing the default tool-chain options may be worth doing for
>> user-space software, but the kernel will still need to be handled separately.
> 
> Thanks for your feedback.
> 
> We need some feedback from cip-security workgroup as well.
> 

I would not deviate from upstream Debian packages unless there are good security 
reasons AND no interest by the package maintainers to follow them. Upstream 
first. That activity, though, can be a perfect CIP task.

For the kernel, we should, of course, enable additional options that make sense 
to test them (or reveal issues by having runtime checks armed). User may then 
pick them up - or turn them off again if some product has different priorities.

And I would not recommend to fiddle with the compiler package on our own. My 
impression is that's too central.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux