Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Honor compilation flags passed from the environment #1

Open
wants to merge 3 commits into
base: ubuntu/utopic
Choose a base branch
from

Conversation

frediz
Copy link

@frediz frediz commented Jun 19, 2015

Adding the environment variables CFLAGS, CPPFLAGS and LDFLAGS to the one in the
Makefiles. Debian/Ubuntu use this mechanism to do hardened builds.

jk-ozlabs and others added 3 commits June 18, 2015 15:29
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Will make an opal-gard package .deb file which just contains the gard
utility.

Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Adding the environment variables CFLAGS, CPPFLAGS and LDFLAGS to the one in the
Makefiles. Debian/Ubuntu use this mechanism to do hardened builds.
frediz pushed a commit to frediz/skiboot that referenced this pull request Jun 10, 2016
CID 97867 (jk-ozlabs#1 of 1): Uninitialized scalar variable (UNINIT)
5. uninit_use: Using uninitialized value rc.

Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs pushed a commit that referenced this pull request May 15, 2017
This ends up being harmless bug due to memory layout.

$ ./pflash -F ~/op-build/output/images/firestone.pnor -i
==31829==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000062f0
80 at pc 0x410226 bp 0x7ffedba9c950 sp 0x7ffedba9c948
WRITE of size 8 at 0x00000062f080 thread T0
    #0 0x410225 in file_get_info (/home/stewart/skiboot/external/pflash/pflash+0
x410225)
    #1 0x40d832 in blocklevel_get_info (/home/stewart/skiboot/external/pflash/pf
lash+0x40d832)
    #2 0x401f0c in main (/home/stewart/skiboot/external/pflash/pflash+0x401f0c)
    open-power#3 0x7fc77439ab44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21
b44)
    open-power#4 0x403884 (/home/stewart/skiboot/external/pflash/pflash+0x403884)

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs pushed a commit that referenced this pull request Oct 3, 2017
Fixes: CID 142226 (#1 of 1):
overflow_before_widen: Potentially overflowing expression
`1 << mbox_flash->shift` with type int (32 bits, signed) is evaluated using
32-bit arithmetic, and then used in a context that expects an expression
of type uint64_t (64 bits, unsigned).

Fixes: CID 142226
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs pushed a commit that referenced this pull request Oct 3, 2017
Fixes the following LeakSanitizer errors:

=================================================================
==32426==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 1 object(s) allocated from:
    #0 0x7fd94a1fa850 in malloc (/lib64/libasan.so.4+0xde850)
    #1 0x4014d4 in main core/test/run-time-utils.c:30
    #2 0x7fd94904c509 in __libc_start_main (/lib64/libc.so.6+0x20509)

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x7fd94a1fa850 in malloc (/lib64/libasan.so.4+0xde850)
    #1 0x4014f0 in main core/test/run-time-utils.c:32
    #2 0x7fd94904c509 in __libc_start_main (/lib64/libc.so.6+0x20509)

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7fd94a1fa850 in malloc (/lib64/libasan.so.4+0xde850)
    #1 0x4014e2 in main core/test/run-time-utils.c:31
    #2 0x7fd94904c509 in __libc_start_main (/lib64/libc.so.6+0x20509)

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs pushed a commit that referenced this pull request Oct 3, 2017
…nt', which requires 8 byte alignment

UBSan caught this:

hdata/test/../iohub.c:83:2: runtime error: load of misaligned address 0x7f1dc7b0210a for type 'long unsigned int', which requires 8 byte alignment
0x7f1dc7b0210a: note: pointer points here
 31 4c  58 08 31 00 04 01 00 30  00 42 50 46 02 00 00 78  00 00 00 00 00 00 00 00  00 00 00 00 00 00
              ^
    #0 0x41470a in io_get_lx_info hdata/test/../iohub.c:83
    #1 0x41759f in io_add_p8_cec_vpd hdata/test/../iohub.c:450
    #2 0x417d35 in io_parse_fru hdata/test/../iohub.c:538
    open-power#3 0x41812a in io_parse hdata/test/../iohub.c:600
    open-power#4 0x425aa2 in parse_hdat hdata/test/../spira.c:1337
    open-power#5 0x43d9f8 in main hdata/test/hdata_to_dt.c:358
    open-power#6 0x7f1dcb868509 in __libc_start_main (/lib64/libc.so.6+0x20509)
    open-power#7 0x4019e9 in _start (/home/stewart/skiboot/hdata/test/hdata_to_dt+0x4019e9)

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs pushed a commit that referenced this pull request Oct 3, 2017
LeakSanitizer spotted this:

Direct leak of 131072 byte(s) in 1 object(s) allocated from:
    #0 0x7fb99e42b850 in malloc (/lib64/libasan.so.4+0xde850)
    #1 0x408612 in main libflash/test/test-flash.c:380
    #2 0x7fb99d27d509 in __libc_start_main (/lib64/libc.so.6+0x20509)

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs pushed a commit that referenced this pull request Oct 3, 2017
LeakSanitizer caught this with libflash/test/test-flash.c:

Direct leak of 4096 byte(s) in 1 object(s) allocated from:
    #0 0x7f72546ee850 in malloc (/lib64/libasan.so.4+0xde850)
    #1 0x405ff0 in flash_init libflash/test/../libflash.c:830
    #2 0x408632 in main libflash/test/test-flash.c:382
    open-power#3 0x7f7253540509 in __libc_start_main (/lib64/libc.so.6+0x20509)

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs pushed a commit that referenced this pull request Oct 3, 2017
==8304==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4096 byte(s) in 1 object(s) allocated from:
    #0 0x7f70eda8f850 in malloc (/lib64/libasan.so.4+0xde850)
    #1 0x408ba0 in main libflash/test/test-blocklevel.c:298
    #2 0x7f70ec8e1509 in __libc_start_main (/lib64/libc.so.6+0x20509)

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs pushed a commit that referenced this pull request Mar 1, 2019
If any of the core fails to sync its TB during chipTOD initialization,
all the threads of that core are disabled. But this does not make
linux kernel to ignore the core/cpus. It crashes while bringing them up
with below backtrace:

[   38.883898] kexec_core: Starting new kernel
cpu 0x0: Vector: 300 (Data Access) at [c0000003f277b730]
    pc: c0000000001b9890: internal_create_group+0x30/0x304
    lr: c0000000001b9880: internal_create_group+0x20/0x304
    sp: c0000003f277b9b0
   msr: 900000000280b033
   dar: 40
 dsisr: 40000000
  current = 0xc0000003f9f41000
  paca    = 0xc00000000fe00000	 softe: 0	 irq_happened: 0x01
    pid   = 2572, comm = kexec
Linux version 4.13.2-openpower1 (jenkins@p89) (gcc version 6.4.0 (Buildroot 2017.08-00006-g319c6e1)) #1 SMP Wed Sep 20 05:42:11 UTC 2017
enter ? for help
[c0000003f277b9b0] c0000000008a8780 (unreliable)
[c0000003f277ba50] c00000000041c3ac topology_add_dev+0x2c/0x40
[c0000003f277ba70] c00000000006b078 cpuhp_invoke_callback+0x88/0x170
[c0000003f277bac0] c00000000006b22c cpuhp_up_callbacks+0x54/0xb8
[c0000003f277bb10] c00000000006bc68 cpu_up+0x11c/0x168
[c0000003f277bbc0] c00000000002f0e0 default_machine_kexec+0x1fc/0x274
[c0000003f277bc50] c00000000002e2d8 machine_kexec+0x50/0x58
[c0000003f277bc70] c0000000000de4e8 kernel_kexec+0x98/0xb4
[c0000003f277bce0] c00000000008b0f0 SyS_reboot+0x1c8/0x1f4
[c0000003f277be30] c00000000000b118 system_call+0x58/0x6c

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
jk-ozlabs pushed a commit that referenced this pull request Mar 1, 2019
>From coverity defect 173758:
CID 173758 (#1 of 1): Unused value (UNUSED_VALUE)
assigned_value: Assigning value from (uint8_t)i_Rs << 21 to
mtsprInstOpcode here, but that stored value is overwritten before it can
be used.

This causes the generated mtspr to always move from register r0 as
opposed to the function parameter i_Rs.

Luckily the only call to getMtsprInstruction is:
getMtsprInstruction( 0, (uint16_t)i_regId );
the first parameter is the register so in an incredible stroke of luck,
the requirement is to generate a mtspr from r0.

Therefore no bug exists today, this is still a fairly important fix
because if anyone uses getMtsprInstruction() with a non zero first
parameter, it will cause them endless headache.

Fixes: CID 173758

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants