Date   

[Git][cip-project/cip-kernel/cip-kernel-sec][master] 6 commits: Add test scripts for f2fs issues with public reproducers

Agustin Benito Bethencourt
 

Ben Hutchings pushed to branch master at cip-project / cip-kernel / cip-kernel-sec

Commits:

  • 762d2184
    by Ben Hutchings at 2019-02-05T18:10:06Z
    Add test scripts for f2fs issues with public reproducers
    
  • 718ec1d6
    by Ben Hutchings at 2019-02-05T18:10:35Z
    Import more data
    
  • 78b6f478
    by Ben Hutchings at 2019-02-05T18:10:35Z
    Fill in fix commit list for SSB in 4.4
    
  • bd17a1cc
    by Ben Hutchings at 2019-02-05T18:10:35Z
    Update description for CVE-2019-3701 and mark it to be ignored
    
  • 35c41e3e
    by Ben Hutchings at 2019-02-05T18:10:35Z
    Add test script for CVE-2018-18690
    
  • f97cfc8c
    by Ben Hutchings at 2019-02-05T18:10:35Z
    Ignore some minor issues
    

30 changed files:

Changes:

  • issues/CVE-2017-18232.yml
    ... ... @@ -10,3 +10,8 @@ introduced-by:
    10 10
       mainline: [87c8331fcf72e501c3a3c0cdc5c9391ec72f7cf2]
    
    11 11
     fixed-by:
    
    12 12
       mainline: [0558f33c06bb910e2879e355192227a8e8f0219d]
    
    13
    +ignore:
    
    14
    +  all: |-
    
    15
    +    This appears to be a denial-of-service that requires physical
    
    16
    +    access or CAP_SYS_ADMIN privileges. That doesn't seem to be a
    
    17
    +    security issue at all.

  • issues/CVE-2018-13096.yml
    ... ... @@ -23,3 +23,5 @@ fixed-by:
    23 23
       linux-4.14.y: [b8321ccd045710ee04fd5322c34cadd13a5e58af]
    
    24 24
       linux-4.9.y: [1c87980591a1dc8c5eafdcc5f9953fca4e518465]
    
    25 25
       mainline: [e34438c903b653daca2b2a7de95aed46226f8ed3]
    
    26
    +tests:
    
    27
    +- CVE-2018-13096

  • issues/CVE-2018-13097.yml
    ... ... @@ -21,3 +21,5 @@ fixed-by:
    21 21
       linux-4.14.y: [f9cf5462b51d98026275cc51437fc531e808b64a]
    
    22 22
       linux-4.9.y: [06e606acedaf8bb00c83c4cee43acdd264287a92]
    
    23 23
       mainline: [9dc956b2c8523aed39d1e6508438be9fea28c8fc]
    
    24
    +tests:
    
    25
    +- CVE-2018-13097

  • issues/CVE-2018-13099.yml
    ... ... @@ -24,3 +24,5 @@ fixed-by:
    24 24
       linux-4.18.y: [235fd393825b8b79d962eb2f9a2d6aa454eb17a5]
    
    25 25
       linux-4.9.y: [7e0782ceebaaed70b0c4b775c27b81e8f8cf6ddb]
    
    26 26
       mainline: [4dbe38dc386910c668c75ae616b99b823b59f3eb]
    
    27
    +tests:
    
    28
    +- CVE-2018-13099

  • issues/CVE-2018-13100.yml
    ... ... @@ -21,3 +21,5 @@ fixed-by:
    21 21
       linux-4.18.y: [0342426f2bf7298a91efee659ddc033082f6918b]
    
    22 22
       linux-4.9.y: [a3dccfacd3a574365ab6c5118f8a944a4ba691fa]
    
    23 23
       mainline: [42bf546c1fe3f3654bdf914e977acbc2b80a5be5]
    
    24
    +tests:
    
    25
    +- CVE-2018-13100

  • issues/CVE-2018-14610.yml
    ... ... @@ -13,5 +13,6 @@ reporters:
    13 13
     - Po-Ning Tseng
    
    14 14
     fixed-by:
    
    15 15
       linux-4.14.y: [34407a175a59b668a1a2bbf0d0e495d87a7777d8]
    
    16
    +  linux-4.4.y: [ee5e37a26791f9c842b3298e594c6e3c93bb1355]
    
    16 17
       linux-4.9.y: [7a72f918825ddece7a4ed79583836f6f1e06e478]
    
    17 18
       mainline: [514c7dca85a0bf40be984dab0b477403a6db901f]

  • issues/CVE-2018-14611.yml
    ... ... @@ -13,5 +13,6 @@ reporters:
    13 13
     - Po-Ning Tseng
    
    14 14
     fixed-by:
    
    15 15
       linux-4.14.y: [f7eef132ccc95c9af50b647c5da0511d2b8492f8]
    
    16
    +  linux-4.4.y: [50962a7b4877f26d1f3f49cd77ad1814a9e81bac]
    
    16 17
       linux-4.9.y: [3c77b07dc365a7ed2644ca0dd38e6e40a9652d57]
    
    17 18
       mainline: [315409b0098fb2651d86553f0436b70502b29bb2]

  • issues/CVE-2018-14612.yml
    ... ... @@ -15,5 +15,6 @@ reporters:
    15 15
     - Po-Ning Tseng
    
    16 16
     fixed-by:
    
    17 17
       linux-4.14.y: [c0dfb99847851fb830d1e8ea7d5e0571f50c325a, 895586ecb7a4528336d41f81d0ce3985e8abbed6]
    
    18
    +  linux-4.4.y: [42d263820480ab1f7eba54590f2c7283b3428723, 98620167ed91cfef2bf24b058170d5194e0c4c45]
    
    18 19
       linux-4.9.y: [6f33d3d8dca8683a4df94e9944296a1a1a2a6f10, 23eb2f435a07e1e09d48ea10c4a22bc96e16fde6]
    
    19 20
       mainline: [ba480dd4db9f1798541eb2d1c423fc95feee8d36, 7ef49515fa6727cb4b6f2f5b0ffbc5fc20a9f8c6]

  • issues/CVE-2018-14613.yml
    ... ... @@ -9,5 +9,6 @@ reporters:
    9 9
     - Po-Ning Tseng
    
    10 10
     fixed-by:
    
    11 11
       linux-4.14.y: [9f268b5cf2d6a716779dfe11f4bc02d6461db693]
    
    12
    +  linux-4.4.y: [ae94efaf2b609e811bce6280d5c88cf557cd1238]
    
    12 13
       linux-4.9.y: [058e388e42c8dc5b6ce6248990c75a0459e20197]
    
    13 14
       mainline: [fce466eab7ac6baa9d2dcd88abcf945be3d4a089]

  • issues/CVE-2018-14614.yml
    ... ... @@ -14,3 +14,5 @@ fixed-by:
    14 14
       linux-4.14.y: [30130700acfad8a705c109325379f5bbe21b3ccc]
    
    15 15
       linux-4.9.y: [91fe514bedf4c72ae8046fe4cfa98c5e201f6b84]
    
    16 16
       mainline: [e494c2f995d6181d6e29c4927d68e0f295ecf75b]
    
    17
    +tests:
    
    18
    +- CVE-2018-14614

  • issues/CVE-2018-14616.yml
    ... ... @@ -16,3 +16,5 @@ fixed-by:
    16 16
       linux-4.14.y: [38fce19d4d7bc8acfa183ee2918758d279a69c9a]
    
    17 17
       linux-4.9.y: [b10a6ac262f8c1c0c70a90e992137a5590325f0b]
    
    18 18
       mainline: [91291e9998d208370eb8156c760691b873bd7522]
    
    19
    +tests:
    
    20
    +- CVE-2018-14616

  • issues/CVE-2018-16884.yml
    ... ... @@ -22,4 +22,9 @@ reporters:
    22 22
     introduced-by:
    
    23 23
       mainline: [23c20ecd44750dd42e5fd53285a17ca8d8a9b0a3]
    
    24 24
     fixed-by:
    
    25
    +  linux-4.14.y: [65dba32522065b79a16393efc75f8006c2c3dbb8]
    
    26
    +  linux-4.19.y: [44e7bab39f877c9c095bfaaee943b0807574a7f7]
    
    27
    +  linux-4.20.y: [696d76cca37114d6a32f7043add7ce22a734dcfa]
    
    28
    +  linux-4.4.y: [9615b6aeccbfb233fd672107aa6885bf039c3de3]
    
    29
    +  linux-4.9.y: [37c791a031ece3afeb9c8b023397473a5349f171]
    
    25 30
       mainline: [d4b09acf924b84bae77cad090a9d108e70b43643]

  • issues/CVE-2018-16885.yml
    1 1
     description: out-of-bound read in memcpy_fromiovecend()
    
    2 2
     references:
    
    3 3
     - https://bugzilla.redhat.com/show_bug.cgi?id=1661503
    
    4
    +- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16885
    
    5
    +- https://bugzilla.redhat.com/show_bug.cgi?id=1661503#c4
    
    4 6
     comments:
    
    5 7
       Debian-carnil: |-
    
    6 8
         Not much details provided in RedHat Bugzilla #1661503 but said
    
    ... ... @@ -8,5 +10,9 @@ comments:
    8 10
         the buggy memcpy_fromiovecend() (and related functions) are
    
    9 11
         fixed by upstream commit
    
    10 12
         21226abb4e9f14d88238964d89b279e461ddc30c (4.0-rc1)
    
    13
    +  Ubuntu-tyhicks: According to Red Hat, this flaw only affects Red Hat Enterprise
    
    14
    +    Linux
    
    15
    +reporters:
    
    16
    +- Paolo Abeni
    
    11 17
     fixed-by:
    
    12 18
       mainline: [21226abb4e9f14d88238964d89b279e461ddc30c]

  • issues/CVE-2018-18690.yml
    ... ... @@ -18,3 +18,5 @@ fixed-by:
    18 18
       linux-4.14.y: [cb7ccb9924bb3596f211badf0d2becf131a979cd]
    
    19 19
       linux-4.9.y: [4ec44e98ab08c704d0ff1a35a21a0682a5562a27]
    
    20 20
       mainline: [7b38460dc8e4eafba06c78f8e37099d3b34d473c]
    
    21
    +tests:
    
    22
    +- CVE-2018-18690

  • issues/CVE-2018-19985.yml
    ... ... @@ -10,5 +10,6 @@ introduced-by:
    10 10
     fixed-by:
    
    11 11
       linux-4.14.y: [49be8dc589aee04c64d61e362c5029ab20fd6fd7]
    
    12 12
       linux-4.19.y: [8f980122236c1fc8e11ffb57ec73315d01dc88e0]
    
    13
    +  linux-4.4.y: [8846b1dbfd2146b145d73ba31a4caa4a4789aefb]
    
    13 14
       linux-4.9.y: [5501175cb1975239add62a521cfbedcf76b93d8d]
    
    14 15
       mainline: [5146f95df782b0ac61abde36567e718692725c89]

  • issues/CVE-2018-3639.yml
    ... ... @@ -119,6 +119,32 @@ fixed-by:
    119 119
         bd4b410bc5ea560107126a3df18e9233baaec9f3, 95271aeb93d4681c65e2f94969b23ef6070367a6,
    
    120 120
         7445962ff2d652bb957722ca1a08a92d09f3e5d7, 677af592349708498671b0d9290912acb2f203e4,
    
    121 121
         75e3417f898fe1d2451e7ceffe93db5c66772b0a]
    
    122
    +  linux-4.4.y: [b2dab2dc776cea8e1f190523456b32b850506ce3, d77421663170a2d660fa63a50c664805d132e69d,
    
    123
    +    96df48c0c42c6816d5b2808ed9e18a428cbf9598, 51f37b2f0248911465d8f84fb6f547be5316a261,
    
    124
    +    2658e4d66deca4c1fc6eb59514bded62dd0a7812, 3e1ec1698244de1b808ae0142dd653e5aded91d7,
    
    125
    +    d8067aba239cbd2bfd64cdd548a914b20c58d189, 1cdf94bc21610ffbabedd5b6d85700ed1017037d,
    
    126
    +    46ea6e547d0595f88086bc56c2f032b0e2f3f9ac, 7dc950c1ce909c11c3985802b1aba6b655d8dc23,
    
    127
    +    d9a58c4316857347b0ef77e94bde43379c87a746, ec5bf1a308faac133951877c8b5fbbb0413529cb,
    
    128
    +    0109a1b0a5cababd514671b517722585302c0d4f, 49d8e36618f7524611409b8608dd54d399e7097f,
    
    129
    +    13fa2c65c9a8c2cd5f2a9799891582c40b6f5cfa, b04a020d0745a7ba18800e86ea678676aeb21278,
    
    130
    +    2cb00ce1273d48dafce848f4e0ea353eb5839475, b6f4a6285d7979b45d629e65c880279930b98ef1,
    
    131
    +    484964fa3e5a0d8467891aab8368dab34e8eb13c, 0b1174054e0f4afd999c56ddecbbfb18f598f099,
    
    132
    +    3f9cb20f9126db1edb1fad78a0e94ff8e9ae94e2, a08c3f484c34df1e3bec3c47818d570483bf67fa,
    
    133
    +    c463c0f037f2d83aea54415ed7c61deb0b90333b, 9237a1b0828962191107e702cf56c88db9f9d455,
    
    134
    +    afc6bf9131efc36d4ae8a003e8597119a2190661, 6e2119e4b8767a6c3a415875ad09596ada00755c,
    
    135
    +    765897c6486de605eae3f94f77f2c800c9a2a254, e5eea0486470acbe7aa20a0533543c47c942ec93,
    
    136
    +    631474e1cee0fbc0f346664aea5ee5b1c3600649, 103b28d8a271c1d650eb5b09bd7a53d8915b51d6,
    
    137
    +    95bef2217ece77c345e627eba9cd2e85ada8eeb2, 714f18858ceda6f2b8335686f1f019560fe89283,
    
    138
    +    7f77d36ab3f3d3dc09af0afbc7b58198382e9941, 3e3a1c2ee031cd3d1a8fe9a990b61c8f17a6dd83,
    
    139
    +    4f4a2c70cf2ecd17ef3899c754fee30caa343286, e4bb3382cbe9173e7f6e3a13fd1cb39c3a72671f,
    
    140
    +    11a0b92f6d57853550f927fe91190b745a5ab945, 21757fc8bafd50ce477fff2bcec6faec27c5548d,
    
    141
    +    ea8efcd4415f70766acb4bb9553fad855eea48e1, b5ec2b3f11993d843f75c2d2954ece20af96dc88,
    
    142
    +    e13a6f0955bb5ee6daca1f08027d6561d0830daf, ecfe9bf30e4b7cd13f3b28f40a587a932b5cb457,
    
    143
    +    3d60492cea89c0a0fb06c73ee49cc14c55f527dd, d5aec90670c378b6d05e5f904b1a8c8cffb17eef,
    
    144
    +    9ed7ee52e4e06364f47d6a6e898610bae5f04e93, 90cfa767bc12a9931e5e45ed275b069d5b35b52e,
    
    145
    +    80d7439fb0c446d006599b6347efd255a86a93ca, 48805280d05c968e0883e8debf5e33f40f8e56c5,
    
    146
    +    ff3c3b181c5ee5930b9cc6ca59c4c985a3d93220, cadb98135daf474648d646db5625e9c663b94a3d,
    
    147
    +    1c74bd22e846b162ea6401e8d43172e0e7256ccf]
    
    122 148
       linux-4.9.y: [741c026d1a0c594f7ad509f44488ef29582fed74, 88659d5fd9bea7f6afb227c6d404de750b368b45,
    
    123 149
         3effee64a9993dc5587fb39f0da4455769e53d26, 0f5dd651397b264903e8becc511af6cf384c273e,
    
    124 150
         cf21f58ae6f264e0a10d9736be97342627cf9837, 24e4dd97af40afa4d45e85a32d9c2cc81425a62e,
    

  • issues/CVE-2018-5995.yml
    ... ... @@ -10,3 +10,8 @@ comments:
    10 10
         be possible.
    
    11 11
     fixed-by:
    
    12 12
       mainline: [ad67b74d2469d9b82aaa572d76474c95bc484d57]
    
    13
    +ignore:
    
    14
    +  all: |-
    
    15
    +    This is an information leak that requires access to the system
    
    16
    +    log. It can therefore be mitigated with
    
    17
    +    CONFIG_SECURITY_DMESG_RESTRICT or sysctl kernel.dmesg_restrict.

  • issues/CVE-2018-7273.yml
    ... ... @@ -10,4 +10,7 @@ comments:
    10 10
     fixed-by:
    
    11 11
       mainline: [ad67b74d2469d9b82aaa572d76474c95bc484d57]
    
    12 12
     ignore:
    
    13
    -  linux-3.2.y: Minor issue
    13
    +  all: |-
    
    14
    +    This is an information leak that requires access to the system
    
    15
    +    log. It can therefore be mitigated with
    
    16
    +    CONFIG_SECURITY_DMESG_RESTRICT or sysctl kernel.dmesg_restrict.

  • issues/CVE-2019-3459.yml
    1
    +description: Heap address infoleak in use of l2cap_get_conf_opt
    
    2
    +references:
    
    3
    +- https://lore.kernel.org/linux-bluetooth/20190110062833.GA15047@.../
    
    4
    +- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3459
    
    5
    +reporters:
    
    6
    +- Shlomi Oberman
    
    7
    +- Yuli Shapiro
    
    8
    +- Ran Menscher

  • issues/CVE-2019-3460.yml
    1
    +description: Heap data infoleak in multiple locations including functionl2cap_parse_conf_rsp
    
    2
    +references:
    
    3
    +- https://lore.kernel.org/linux-bluetooth/20190110062917.GB15047@.../
    
    4
    +- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3460
    
    5
    +reporters:
    
    6
    +- Shlomi Oberman
    
    7
    +- Yuli Shapiro
    
    8
    +- Ran Menscher

  • issues/CVE-2019-3701.yml
    ... ... @@ -4,13 +4,15 @@ description: |-
    4 4
       logical operations that can be also applied to the can_dlc field. Because
    
    5 5
       of a missing check, the CAN drivers may write arbitrary content beyond the
    
    6 6
       data registers in the CAN controller's I/O memory when processing can-gw
    
    7
    -  manipulated outgoing frames. This is related to cgw_csum_xor_rel. An
    
    8
    -  unprivileged user can trigger a system crash (general protection fault).
    
    7
    +  manipulated outgoing frames. This is related to cgw_csum_xor_rel. A
    
    8
    +  privileged user can trigger a system crash (general protection fault).
    
    9 9
     references:
    
    10 10
     - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3701
    
    11 11
     - https://marc.info/?l=linux-netdev&m=154659326324991&w=2
    
    12 12
     - https://bugzilla.suse.com/show_bug.cgi?id=1120386
    
    13 13
     - https://marc.info/?l=linux-netdev&m=154651842302479&w=2
    
    14
    +- https://marc.info/?l=linux-can&m=154659326224990&w=2
    
    15
    +- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/net/can?id=0aaa81377c5a01f686bcdb8c7a6929a7bf330c68
    
    14 16
     comments:
    
    15 17
       Debian-carnil: |-
    
    16 18
         unprivileged user namespaces might be needed to exploit the bug,
    
    ... ... @@ -31,3 +33,7 @@ fixed-by:
    31 33
       linux-4.4.y: [693ae291197429f404e7d9c191e1541f61925278]
    
    32 34
       linux-4.9.y: [d379b338387e3d5a9b5ebe5ab16656a9c65c988d]
    
    33 35
       mainline: [0aaa81377c5a01f686bcdb8c7a6929a7bf330c68]
    
    36
    +ignore:
    
    37
    +  all: |-
    
    38
    +    Only the global root user can trigger this bug and the result is a
    
    39
    +    crash. This doesn't seem to have a security impact.

  • issues/CVE-2019-5489.yml
    ... ... @@ -15,12 +15,22 @@ references:
    15 15
     - https://bugzilla.suse.com/show_bug.cgi?id=1120843
    
    16 16
     - https://twitter.com/lavados/status/1081205802046607361
    
    17 17
     - https://lore.kernel.org/lkml/CAHk-=wiqbKEC5jUXr3ax+oUuiRrp=QMv_ZnUfO-SPv=UNJ-OTw@.../T/#mf09fc35229f38e5b657f299a3a3865c8ca39e7e1
    
    18
    +- https://lore.kernel.org/lkml/CAHk-=wiqbKEC5jUXr3ax+oUuiRrp=QMv_ZnUfO-SPv=UNJ-OTw@.../
    
    18 19
     comments:
    
    19 20
       Debian-carnil: |-
    
    20 21
         574823bfab82d9d8fa47f422778043fbb4b4f50e was marked explicitly
    
    21 22
         not yet for stable as it is expected to check if there are issues
    
    22 23
         with this approach. There are enough tools which depend on mincore()
    
    23 24
         to try to tell wheter a file is loaded in cache or not.
    
    25
    +  Ubuntu-tyhicks: |-
    
    26
    +    On 2018-01-06, a potential fix for this issue was committed in the
    
    27
    +     upstream kernel git tree. The potential fix changes the behavior of the
    
    28
    +     mincore(2) system call in ways that could possibly break userspace
    
    29
    +     applications. The potential fix landed during the kernel's "merge window"
    
    30
    +     which allows for the change to mature and receive additional testing.
    
    31
    +     Applying the potential fix to Ubuntu kernels, at this time, could potentially
    
    32
    +     break some existing applications. Ubuntu will continue to monitor related
    
    33
    +     changes in the upstream kernel and evaluate/test the potential fix.
    
    24 34
     reporters:
    
    25 35
     - Daniel Gruss
    
    26 36
     - Erik Kraft
    

  • tests/CVE-2018-13096
    1
    +#!/bin/sh -eu
    
    2
    +
    
    3
    +. "$(dirname "$0")/common.sh"
    
    4
    +
    
    5
    +test_cleanup() {
    
    6
    +    if mountpoint -q "$scratch_dir/mnt"; then
    
    7
    +	umount "$scratch_dir/mnt"
    
    8
    +    fi
    
    9
    +}
    
    10
    +
    
    11
    +assert_kconfig CONFIG_F2FS_FS
    
    12
    +assert_kconfig CONFIG_KASAN y
    
    13
    +
    
    14
    +curl -o "$scratch_dir/35.img.zip" \
    
    15
    +     "https://bugzilla.kernel.org/attachment.cgi?id=276727"
    
    16
    +unzip -d "$scratch_dir" "$scratch_dir/35.img.zip" 35.img
    
    17
    +
    
    18
    +mkdir "$scratch_dir/mnt"
    
    19
    +! mount -o loop -t f2fs "$scratch_dir/35.img" "$scratch_dir/mnt"
    
    20
    +
    
    21
    +assert_untainted

  • tests/CVE-2018-13097
    1
    +#!/bin/sh -eu
    
    2
    +
    
    3
    +. "$(dirname "$0")/common.sh"
    
    4
    +
    
    5
    +test_cleanup() {
    
    6
    +    if mountpoint -q "$scratch_dir/mnt"; then
    
    7
    +	umount "$scratch_dir/mnt"
    
    8
    +    fi
    
    9
    +}
    
    10
    +
    
    11
    +assert_kconfig CONFIG_F2FS_FS
    
    12
    +
    
    13
    +curl -o "$scratch_dir/final.img.zip" \
    
    14
    +     "https://bugzilla.kernel.org/attachment.cgi?id=276731"
    
    15
    +unzip -d "$scratch_dir" "$scratch_dir/final.img.zip" final.img
    
    16
    +
    
    17
    +mkdir "$scratch_dir/mnt"
    
    18
    +! mount -o loop -t f2fs "$scratch_dir/final.img" "$scratch_dir/mnt"
    
    19
    +
    
    20
    +assert_untainted

  • tests/CVE-2018-13099
    1
    +#!/bin/sh -eu
    
    2
    +
    
    3
    +. "$(dirname "$0")/common.sh"
    
    4
    +
    
    5
    +test_cleanup() {
    
    6
    +    if mountpoint -q "$scratch_dir/mnt"; then
    
    7
    +	umount "$scratch_dir/mnt"
    
    8
    +    fi
    
    9
    +}
    
    10
    +
    
    11
    +assert_kconfig CONFIG_F2FS_FS
    
    12
    +assert_kconfig CONFIG_KASAN y
    
    13
    +
    
    14
    +curl -o "$scratch_dir/final.img.zip" \
    
    15
    +     "https://bugzilla.kernel.org/attachment.cgi?id=276739"
    
    16
    +unzip -d "$scratch_dir" "$scratch_dir/final.img.zip" final.img
    
    17
    +
    
    18
    +# Proof-of-concept code is inline in a comment :-(
    
    19
    +curl -o "$scratch_dir/comments.json" \
    
    20
    +     "https://bugzilla.kernel.org/rest/bug/comment/1290421"
    
    21
    +jq --raw-output '.comments["1290421"].text' "$scratch_dir/comments.json" \
    
    22
    +    | sed -n '/^- POC/,/^- Kernel message/ { /^-/d; p }' \
    
    23
    +    > "$scratch_dir/poc.c"
    
    24
    +cc -Wall -Wextra -O2 "$scratch_dir/poc.c" -o "$scratch_dir/poc"
    
    25
    +
    
    26
    +mkdir "$scratch_dir/mnt"
    
    27
    +mount -o loop -t f2fs "$scratch_dir/final.img" "$scratch_dir/mnt"
    
    28
    +
    
    29
    +assert_untainted
    
    30
    +
    
    31
    +"$scratch_dir/poc" "$scratch_dir/mnt"
    
    32
    +
    
    33
    +assert_untainted $((0x200))  # expect and ignore TAINT_WARN

  • tests/CVE-2018-13100
    1
    +#!/bin/sh -eu
    
    2
    +
    
    3
    +. "$(dirname "$0")/common.sh"
    
    4
    +
    
    5
    +test_cleanup() {
    
    6
    +    if mountpoint -q "$scratch_dir/mnt"; then
    
    7
    +	umount "$scratch_dir/mnt"
    
    8
    +    fi
    
    9
    +}
    
    10
    +
    
    11
    +assert_kconfig CONFIG_F2FS_FS
    
    12
    +
    
    13
    +curl -o "$scratch_dir/final.img.zip" \
    
    14
    +     "https://bugzilla.kernel.org/attachment.cgi?id=276743"
    
    15
    +unzip -d "$scratch_dir" "$scratch_dir/final.img.zip" final.img
    
    16
    +
    
    17
    +mkdir "$scratch_dir/mnt"
    
    18
    +! mount -o loop -t f2fs "$scratch_dir/final.img" "$scratch_dir/mnt"
    
    19
    +
    
    20
    +assert_untainted

  • tests/CVE-2018-14614
    1
    +#!/bin/sh -eu
    
    2
    +
    
    3
    +. "$(dirname "$0")/common.sh"
    
    4
    +
    
    5
    +test_cleanup() {
    
    6
    +    if mountpoint -q "$scratch_dir/mnt"; then
    
    7
    +	umount "$scratch_dir/mnt"
    
    8
    +    fi
    
    9
    +}
    
    10
    +
    
    11
    +assert_kconfig CONFIG_F2FS_FS
    
    12
    +
    
    13
    +curl -o "$scratch_dir/74.img.zip" \
    
    14
    +     "https://bugzilla.kernel.org/attachment.cgi?id=277195"
    
    15
    +unzip -d "$scratch_dir" "$scratch_dir/74.img.zip" 74.img
    
    16
    +
    
    17
    +mkdir "$scratch_dir/mnt"
    
    18
    +! mount -o loop -t f2fs "$scratch_dir/74.img" "$scratch_dir/mnt"
    
    19
    +
    
    20
    +assert_untainted

  • tests/CVE-2018-14616
    1
    +#!/bin/sh -eu
    
    2
    +
    
    3
    +. "$(dirname "$0")/common.sh"
    
    4
    +
    
    5
    +test_cleanup() {
    
    6
    +    if mountpoint -q "$scratch_dir/mnt"; then
    
    7
    +	umount "$scratch_dir/mnt"
    
    8
    +    fi
    
    9
    +}
    
    10
    +
    
    11
    +assert_kconfig CONFIG_F2FS_FS
    
    12
    +assert_kconfig CONFIG_F2FS_FS_ENCRYPTION
    
    13
    +
    
    14
    +curl -o "$scratch_dir/final.img.zip" \
    
    15
    +     "https://bugzilla.kernel.org/attachment.cgi?id=277309"
    
    16
    +unzip -d "$scratch_dir" "$scratch_dir/final.img.zip" final.img
    
    17
    +
    
    18
    +# Proof-of-concept code is inline in a comment :-(
    
    19
    +curl -o "$scratch_dir/comments.json" \
    
    20
    +     "https://bugzilla.kernel.org/rest/bug/comment/1292063"
    
    21
    +jq --raw-output '.comments["1292063"].text' "$scratch_dir/comments.json" \
    
    22
    +    | sed -n '/^- POC/,/^- kernel message/ { /^-/d; p }' \
    
    23
    +    > "$scratch_dir/poc.c"
    
    24
    +cc -Wall -Wextra -O2 "$scratch_dir/poc.c" -o "$scratch_dir/poc"
    
    25
    +
    
    26
    +mkdir "$scratch_dir/mnt"
    
    27
    +mount -o loop -t f2fs "$scratch_dir/final.img" "$scratch_dir/mnt"
    
    28
    +
    
    29
    +assert_untainted
    
    30
    +
    
    31
    +"$scratch_dir/poc" "$scratch_dir/mnt"
    
    32
    +
    
    33
    +assert_untainted $((0x200))  # expect and ignore TAINT_WARN

  • tests/CVE-2018-18690
    1
    +#!/bin/sh -eu
    
    2
    +
    
    3
    +. "$(dirname "$0")/common.sh"
    
    4
    +
    
    5
    +test_cleanup() {
    
    6
    +    if mountpoint -q "$scratch_dir/mnt"; then
    
    7
    +	umount "$scratch_dir/mnt"
    
    8
    +    fi
    
    9
    +}
    
    10
    +
    
    11
    +assert_kconfig CONFIG_XFS_FS
    
    12
    +
    
    13
    +truncate -s 1G "$scratch_dir/xfs.img"
    
    14
    +mkfs.xfs "$scratch_dir/xfs.img"
    
    15
    +
    
    16
    +curl -o "$scratch_dir/setattr.c" \
    
    17
    +     "https://bugzilla.kernel.org/attachment.cgi?id=274733"
    
    18
    +cc -Wall -Wextra -O2 "$scratch_dir/setattr.c" -o "$scratch_dir/setattr"
    
    19
    +
    
    20
    +mkdir "$scratch_dir/mnt"
    
    21
    +mount -o loop -t xfs "$scratch_dir/xfs.img" "$scratch_dir/mnt"
    
    22
    +
    
    23
    +"$scratch_dir/setattr" "$scratch_dir/mnt/hello"
    
    24
    +value="$(getfattr -n user.world --absolute-names --only-values  "$scratch_dir/mnt/hello")"
    
    25
    +test "${#value}" -eq 2048
    
    26
    +
    
    27
    +assert_untainted

  • tests/common.sh
    1
    +# -*- shell-script -*-
    
    2
    +
    
    3
    +_cat_kconfig() {
    
    4
    +    local release
    
    5
    +
    
    6
    +    if [ -f /proc/config ]; then
    
    7
    +	cat /proc/config
    
    8
    +    elif [ -f /proc/config.gz ]; then
    
    9
    +	gzip -dc /proc/config.gz
    
    10
    +    elif [ -f /boot/config-"${release:=$(uname -r)}" ]; then
    
    11
    +	cat /boot/config-"$release"
    
    12
    +    else
    
    13
    +	return 1
    
    14
    +    fi
    
    15
    +}
    
    16
    +
    
    17
    +# Check symbol state in kernel config.
    
    18
    +# Parameters:
    
    19
    +# - symbol name (required)
    
    20
    +# - symbol state (optional), one of m n y
    
    21
    +# If symbol state is not specified then both m and y will be accepted.
    
    22
    +check_kconfig() {
    
    23
    +    local regexp
    
    24
    +
    
    25
    +    if [ $# -eq 1 ]; then
    
    26
    +	regexp="^$1="
    
    27
    +    elif [ "$2" = n ]; then
    
    28
    +	regexp="^# $1 is not"
    
    29
    +    else
    
    30
    +	regexp="^$1=$2"
    
    31
    +    fi
    
    32
    +    _cat_kconfig | grep -q "$regexp"
    
    33
    +}
    
    34
    +
    
    35
    +assert_kconfig() {
    
    36
    +    if check_kconfig "$@"; then
    
    37
    +	return
    
    38
    +    fi
    
    39
    +    if [ $# -eq 1 ]; then
    
    40
    +	echo >&2 "E: $1 must be enabled"
    
    41
    +    elif [ "$2" = n ]; then
    
    42
    +	echo >&2 "E: $1 must be disabled"
    
    43
    +    else
    
    44
    +	echo >&2 "E: $1 must be set to $2"
    
    45
    +    fi
    
    46
    +    exit 1
    
    47
    +}
    
    48
    +
    
    49
    +# Assert that no unexpected taint flags are set.  By default this ignores
    
    50
    +# TAINT_CRAP, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE,
    
    51
    +# TAINT_UNSIGNED_MODULE, TAINT_LIVEPATCH.
    
    52
    +# Parameters:
    
    53
    +# - bitmask of extra flags to ignore (optional)
    
    54
    +assert_untainted() {
    
    55
    +    local tainted
    
    56
    +
    
    57
    +    tainted="$(cat /proc/sys/kernel/tainted)"
    
    58
    +    tainted="$((tainted & ~(0xbc00 | ${1:-0})))"
    
    59
    +
    
    60
    +    if [ $tainted -eq 0 ]; then
    
    61
    +	return
    
    62
    +    fi
    
    63
    +
    
    64
    +    printf >&2 'E: Unexpected taint flags: %#x\n' $tainted
    
    65
    +    exit 1
    
    66
    +}
    
    67
    +
    
    68
    +# Temporary files should normally be created under this directory, which
    
    69
    +# is automatically cleaned up.
    
    70
    +scratch_dir="$(mktemp -d)"
    
    71
    +
    
    72
    +common_cleanup() {
    
    73
    +    rm -rf "$scratch_dir"
    
    74
    +}
    
    75
    +
    
    76
    +# The test_cleanup function should be redefined by tests that need any
    
    77
    +# special cleanup.
    
    78
    +test_cleanup() {
    
    79
    +    :
    
    80
    +}
    
    81
    +
    
    82
    +cleanup() {
    
    83
    +    test_cleanup
    
    84
    +    common_cleanup
    
    85
    +}
    
    86
    +trap cleanup EXIT


  • [Git][cip-project/cip-kernel/cip-kernel-sec][master] 2 commits: This issue has been fixed in mainline, kernel 4.4, 4.9, 4.14 and 4.19

    Agustin Benito Bethencourt
     

    Ben Hutchings pushed to branch master at cip-project / cip-kernel / cip-kernel-sec

    Commits:

    • 9da92a37
      by SZ Lin (林上智) at 2019-01-31T08:53:23Z
      This issue has been fixed in mainline, kernel 4.4, 4.9, 4.14 and 4.19
      
      
    • 41754e09
      by Ben Hutchings at 2019-02-05T14:02:11Z
      Merge branch 'master' into 'master'
      
      
      
      Update status of CVE-2019-3701.yml
      
      
      
      See merge request cip-project/cip-kernel/cip-kernel-sec!2

    1 changed file:

    Changes:

  • issues/CVE-2019-3701.yml
    ... ... @@ -25,3 +25,9 @@ reporters:
    25 25
     - Marcus Meissner
    
    
    26 26
     introduced-by:
    
    
    27 27
       mainline: [c1aabdf379bc2feeb0df7057ed5bad96f492133e]
    
    
    28
    +fixed-by:
    
    
    29
    +  linux-4.14.y: [39ff087b5c6be2ff0b08e617d334e5bf72a08b44]
    
    
    30
    +  linux-4.19.y: [8db82a6f2b76d42ec2615f8def6e797e064e7822]
    
    
    31
    +  linux-4.4.y: [693ae291197429f404e7d9c191e1541f61925278]
    
    
    32
    +  linux-4.9.y: [d379b338387e3d5a9b5ebe5ab16656a9c65c988d]
    
    
    33
    +  mainline: [0aaa81377c5a01f686bcdb8c7a6929a7bf330c68]


  • TSC Meeting note for 4th February, 2019

    Yoshitake Kobayashi
     

    Hi All,

    Here is a meeting note for today's TSC meeting.
    https://docs.google.com/document/d/13CTJnoBChfYELFd_GIpwX0NtmDvGH3eDSwqjjlfoHU0/edit?usp=sharing

    Best regards,
    Yoshi


    Re: [RFC] isar-cip-core

    daniel.sangorrin@...
     

    Thanks Iwamatsu-san.
    Jan: when you move your isar repo to cip-core please add two subgroups for tiny and generic if you want. Otherwise, we can have them on the same level and just mention on the wiki that each belongs to a different profile.

    Thanks,
    Daniel

    -----Original Message-----
    From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...>
    Sent: Monday, February 4, 2019 6:09 PM
    To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@...>
    Cc: agustin.benito@...; jan.kiszka@...; cip-dev@...
    Subject: Re: [cip-dev] [RFC] isar-cip-core

    Hi, Daniel.

    I have confirmed that the cip-core group is displayed and I can show
    to the repository without login.
    Thanks for your work.

    Best regards,
    Nobuhiro

    2019年2月4日(月) 14:37 <daniel.sangorrin@...>:

    Iwamatsu-san,

    I have fixed the permissions. Could you try again and see if it works now?

    Thanks,
    Daniel

    -----Original Message-----
    From: Agustin Benito Bethencourt <agustin.benito@...>
    Sent: Friday, February 1, 2019 5:36 PM
    To: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...>
    Cc: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@...>;
    jan.kiszka@...; cip-dev@...
    Subject: Re: [cip-dev] [RFC] isar-cip-core

    Hi,

    On 1 February 2019 02:35:51 CET, Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...> wrote:
    Hi, Agustin.

    Non-members can not access newly created subgroups.
    Previously, since cip-core was published, I think that it is a setting
    problem, but how do you do?
    the new subgroup has inherited every group member. If you cannot access the new subgroup is because
    you
    were member of a different subgroup, not the top group.

    I am traveling and will not have access the next few hours (I rather do this on a laptop).

    Yo can be added by the new owners.

    @Daniel, @Jan there is a config option in the subgroup to allow people to request access.

    Best Regards


    Best regards,
    Nobuhiro

    2019年1月31日(木) 17:03 Agustín Benito Bethencourt
    <agustin.benito@...>:

    Hi jan and Daniel,

    On Thursday, 31 January 2019 06:33:53 CET
    daniel.sangorrin@... wrote:
    Hi Agustin,

    I need to create the following hierarchy on gitlab:

    cip-core/ <-- group
    tiny/ <-- subgroup
    deby <-- git repo (current cip-core.git)
    generic/ <-- subgroup
    isar <-- git repo
    I just created the new subgroup called "cip-core". I moved the
    project cip-core from the root tree to the new subgroup. I gave both of
    you owner rights in this new subgroup so you can configure it as you
    please. Please take a few minutes to go over the configurations so you
    guys can decide merge request, merge, tickets... strategies. I will be
    traveling the coming days but feel free to ask me through mail or IRC
    if you want a second opinion on how to set up the subgroup/projects. I
    have done it several times with a variety of use cases over the years.

    We defined a policy in which each Member company has a person as
    Owner of the whole CIP Group. If you think there should be two people
    per company to make things more fluid, please propose it. I would be
    fine with it. I understand sometimes it is not ideal to depend on
    somebody else for these things.

    I think it would be useful to agree on basic topics across the
    different subgroups like some common labels, milestones. boards... so
    we start to apply some consistency across the different groups on very
    basic thinks. If you think it might be a good idea I can make a
    proposal in the coming days.

    Best Regards


    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See
    https://www.codethink.co.uk/privacy.html
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev
    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.


    Re: [RFC] isar-cip-core

    Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...>
     

    Hi, Daniel.

    I have confirmed that the cip-core group is displayed and I can show
    to the repository without login.
    Thanks for your work.

    Best regards,
    Nobuhiro

    2019年2月4日(月) 14:37 <daniel.sangorrin@...>:


    Iwamatsu-san,

    I have fixed the permissions. Could you try again and see if it works now?

    Thanks,
    Daniel

    -----Original Message-----
    From: Agustin Benito Bethencourt <agustin.benito@...>
    Sent: Friday, February 1, 2019 5:36 PM
    To: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...>
    Cc: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@...>;
    jan.kiszka@...; cip-dev@...
    Subject: Re: [cip-dev] [RFC] isar-cip-core

    Hi,

    On 1 February 2019 02:35:51 CET, Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...> wrote:
    Hi, Agustin.

    Non-members can not access newly created subgroups.
    Previously, since cip-core was published, I think that it is a setting
    problem, but how do you do?
    the new subgroup has inherited every group member. If you cannot access the new subgroup is because you
    were member of a different subgroup, not the top group.

    I am traveling and will not have access the next few hours (I rather do this on a laptop).

    Yo can be added by the new owners.

    @Daniel, @Jan there is a config option in the subgroup to allow people to request access.

    Best Regards


    Best regards,
    Nobuhiro

    2019年1月31日(木) 17:03 Agustín Benito Bethencourt
    <agustin.benito@...>:

    Hi jan and Daniel,

    On Thursday, 31 January 2019 06:33:53 CET
    daniel.sangorrin@... wrote:
    Hi Agustin,

    I need to create the following hierarchy on gitlab:

    cip-core/ <-- group
    tiny/ <-- subgroup
    deby <-- git repo (current cip-core.git)
    generic/ <-- subgroup
    isar <-- git repo
    I just created the new subgroup called "cip-core". I moved the
    project cip-core from the root tree to the new subgroup. I gave both of
    you owner rights in this new subgroup so you can configure it as you
    please. Please take a few minutes to go over the configurations so you
    guys can decide merge request, merge, tickets... strategies. I will be
    traveling the coming days but feel free to ask me through mail or IRC
    if you want a second opinion on how to set up the subgroup/projects. I
    have done it several times with a variety of use cases over the years.

    We defined a policy in which each Member company has a person as
    Owner of the whole CIP Group. If you think there should be two people
    per company to make things more fluid, please propose it. I would be
    fine with it. I understand sometimes it is not ideal to depend on
    somebody else for these things.

    I think it would be useful to agree on basic topics across the
    different subgroups like some common labels, milestones. boards... so
    we start to apply some consistency across the different groups on very
    basic thinks. If you think it might be a good idea I can make a
    proposal in the coming days.

    Best Regards


    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See
    https://www.codethink.co.uk/privacy.html
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev
    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.


    Re: [RFC] isar-cip-core

    daniel.sangorrin@...
     

    Iwamatsu-san,

    I have fixed the permissions. Could you try again and see if it works now?

    Thanks,
    Daniel

    -----Original Message-----
    From: Agustin Benito Bethencourt <agustin.benito@...>
    Sent: Friday, February 1, 2019 5:36 PM
    To: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...>
    Cc: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@...>;
    jan.kiszka@...; cip-dev@...
    Subject: Re: [cip-dev] [RFC] isar-cip-core

    Hi,

    On 1 February 2019 02:35:51 CET, Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...> wrote:
    Hi, Agustin.

    Non-members can not access newly created subgroups.
    Previously, since cip-core was published, I think that it is a setting
    problem, but how do you do?
    the new subgroup has inherited every group member. If you cannot access the new subgroup is because you
    were member of a different subgroup, not the top group.

    I am traveling and will not have access the next few hours (I rather do this on a laptop).

    Yo can be added by the new owners.

    @Daniel, @Jan there is a config option in the subgroup to allow people to request access.

    Best Regards


    Best regards,
    Nobuhiro

    2019年1月31日(木) 17:03 Agustín Benito Bethencourt
    <agustin.benito@...>:

    Hi jan and Daniel,

    On Thursday, 31 January 2019 06:33:53 CET
    daniel.sangorrin@... wrote:
    Hi Agustin,

    I need to create the following hierarchy on gitlab:

    cip-core/ <-- group
    tiny/ <-- subgroup
    deby <-- git repo (current cip-core.git)
    generic/ <-- subgroup
    isar <-- git repo
    I just created the new subgroup called "cip-core". I moved the
    project cip-core from the root tree to the new subgroup. I gave both of
    you owner rights in this new subgroup so you can configure it as you
    please. Please take a few minutes to go over the configurations so you
    guys can decide merge request, merge, tickets... strategies. I will be
    traveling the coming days but feel free to ask me through mail or IRC
    if you want a second opinion on how to set up the subgroup/projects. I
    have done it several times with a variety of use cases over the years.

    We defined a policy in which each Member company has a person as
    Owner of the whole CIP Group. If you think there should be two people
    per company to make things more fluid, please propose it. I would be
    fine with it. I understand sometimes it is not ideal to depend on
    somebody else for these things.

    I think it would be useful to agree on basic topics across the
    different subgroups like some common labels, milestones. boards... so
    we start to apply some consistency across the different groups on very
    basic thinks. If you think it might be a good idea I can make a
    proposal in the coming days.

    Best Regards


    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See
    https://www.codethink.co.uk/privacy.html
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev
    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.


    CIP-dev IRC weekly meeting log: week 5

    SZ Lin (林上智) <SZ.Lin@...>
     

    Hi,

    Please find the logs of CIP meeting last week in below link:

    https://irclogs.baserock.org/meetings/cip/2019/01/cip.2019-01-31-09.00.log.html

    #action Iwamatsu will release v4.4.172 cip kernel today
    ->Iwamatsu released v4.4.171 kernel [1]
    [1] https://lists.cip-project.org/pipermail/cip-dev/2019-January/001769.html

    #action sangorrin will list of packages for cip core v2 tiny profile

    SZ Lin, Moxa


    Re: [RFC] isar-cip-core

    Agustin Benito Bethencourt <agustin.benito@...>
     

    Hi,

    On 1 February 2019 02:35:51 CET, Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...> wrote:
    Hi, Agustin.

    Non-members can not access newly created subgroups.
    Previously, since cip-core was published, I think that it is a setting
    problem, but how do you do?
    the new subgroup has inherited every group member. If you cannot access the new subgroup is because you were member of a different subgroup, not the top group.

    I am traveling and will not have access the next few hours (I rather do this on a laptop).

    Yo can be added by the new owners.

    @Daniel, @Jan there is a config option in the subgroup to allow people to request access.

    Best Regards


    Best regards,
    Nobuhiro

    2019年1月31日(木) 17:03 Agustín Benito Bethencourt
    <agustin.benito@...>:

    Hi jan and Daniel,

    On Thursday, 31 January 2019 06:33:53 CET
    daniel.sangorrin@... wrote:
    Hi Agustin,

    I need to create the following hierarchy on gitlab:

    cip-core/ <-- group
    tiny/ <-- subgroup
    deby <-- git repo (current cip-core.git)
    generic/ <-- subgroup
    isar <-- git repo
    I just created the new subgroup called "cip-core". I moved the
    project cip-core from the root tree to the new subgroup. I gave both of
    you owner rights in this new subgroup so you can configure it as you
    please. Please take a few minutes to go over the configurations so you
    guys can decide merge request, merge, tickets... strategies. I will be
    traveling the coming days but feel free to ask me through mail or IRC
    if you want a second opinion on how to set up the subgroup/projects. I
    have done it several times with a variety of use cases over the years.

    We defined a policy in which each Member company has a person as
    Owner of the whole CIP Group. If you think there should be two people
    per company to make things more fluid, please propose it. I would be
    fine with it. I understand sometimes it is not ideal to depend on
    somebody else for these things.

    I think it would be useful to agree on basic topics across the
    different subgroups like some common labels, milestones. boards... so
    we start to apply some consistency across the different groups on very
    basic thinks. If you think it might be a good idea I can make a
    proposal in the coming days.

    Best Regards


    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See
    https://www.codethink.co.uk/privacy.html
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev
    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.


    Re: [RFC] isar-cip-core

    Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...>
     

    Hi, Agustin.

    Non-members can not access newly created subgroups.
    Previously, since cip-core was published, I think that it is a setting
    problem, but how do you do?

    Best regards,
    Nobuhiro

    2019年1月31日(木) 17:03 Agustín Benito Bethencourt <agustin.benito@...>:


    Hi jan and Daniel,

    On Thursday, 31 January 2019 06:33:53 CET daniel.sangorrin@... wrote:
    Hi Agustin,

    I need to create the following hierarchy on gitlab:

    cip-core/ <-- group
    tiny/ <-- subgroup
    deby <-- git repo (current cip-core.git)
    generic/ <-- subgroup
    isar <-- git repo
    I just created the new subgroup called "cip-core". I moved the project cip-core from the root tree to the new subgroup. I gave both of you owner rights in this new subgroup so you can configure it as you please. Please take a few minutes to go over the configurations so you guys can decide merge request, merge, tickets... strategies. I will be traveling the coming days but feel free to ask me through mail or IRC if you want a second opinion on how to set up the subgroup/projects. I have done it several times with a variety of use cases over the years.

    We defined a policy in which each Member company has a person as Owner of the whole CIP Group. If you think there should be two people per company to make things more fluid, please propose it. I would be fine with it. I understand sometimes it is not ideal to depend on somebody else for these things.

    I think it would be useful to agree on basic topics across the different subgroups like some common labels, milestones. boards... so we start to apply some consistency across the different groups on very basic thinks. If you think it might be a good idea I can make a proposal in the coming days.

    Best Regards


    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See https://www.codethink.co.uk/privacy.html
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    Linux 4.4.171-cip30

    Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...>
     

    Hi, all.

    I've released Linux version Linux 4.4.171-cip30.

    https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/tag/?h=v4.4.171-cip30
    https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/tag/?h=v4.4.171-cip30-rebase

    The fix from Linux 4.4.166-cip29 is as follows.
    - Update to 4.4.171

    Best regards,
    Nobuhiro


    Re: [RFC] isar-cip-core

    daniel.sangorrin@...
     

    Thanks Agustin!

    -----Original Message-----
    From: Agustín Benito Bethencourt <agustin.benito@...>
    Sent: Thursday, January 31, 2019 5:02 PM
    To: sangorrin daniel(サンゴリン ダニエル ○SWC□OST) <daniel.sangorrin@...>;
    jan.kiszka@...
    Cc: cip-dev@...
    Subject: Re: [cip-dev] [RFC] isar-cip-core

    Hi jan and Daniel,

    On Thursday, 31 January 2019 06:33:53 CET daniel.sangorrin@... wrote:
    Hi Agustin,

    I need to create the following hierarchy on gitlab:

    cip-core/ <-- group
    tiny/ <-- subgroup
    deby <-- git repo (current cip-core.git)
    generic/ <-- subgroup
    isar <-- git repo
    I just created the new subgroup called "cip-core". I moved the project cip-core from the root tree to the new
    subgroup. I gave both of you owner rights in this new subgroup so you can configure it as you please. Please take
    a few minutes to go over the configurations so you guys can decide merge request, merge, tickets... strategies.
    I will be traveling the coming days but feel free to ask me through mail or IRC if you want a second opinion on
    how to set up the subgroup/projects. I have done it several times with a variety of use cases over the years.

    We defined a policy in which each Member company has a person as Owner of the whole CIP Group. If you think
    there should be two people per company to make things more fluid, please propose it. I would be fine with it. I
    understand sometimes it is not ideal to depend on somebody else for these things.

    I think it would be useful to agree on basic topics across the different subgroups like some common labels,
    milestones. boards... so we start to apply some consistency across the different groups on very basic thinks. If you
    think it might be a good idea I can make a proposal in the coming days.

    Best Regards


    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See https://www.codethink.co.uk/privacy.html


    [CIP SW Updates] architecture draft

    daniel.sangorrin@...
     

    Dear CIPers,

    After completing the survey, I have been investigating and reviewing a lot of update tools. As a result, I have extracted the most important requirements and I have designed an abstract architecture of what I would like to achieve. You can find the architecture attached and an example implementation using casync and RAUC to this e-mail.

    This is still very blurry, but I hope that in the next milestone (tools comparison) I make it more clear.

    Currently, after trying some binary delta generation tools, I am geared towards using a "casync" approach. I didn't know about casync but when I found it, I thought it was very neat. The key points of using casync are:
    - operating system images can share common chunks of data: minimiza storage required on the server
    - when using file trees, it concatenates them and create chunks of sizes that are friendly to the network.
    - it is much easier to manage than using binary deltas

    So basically, the server will by casync plus sugar (https server, PKI infrastructure..).

    For the client, I have two possible ideas:
    - One is to just use RAUC, which seems to have support for casync already (although it says experimental)
    - The other one would be to have a very very simple daemon on the client, so that it is easy to add on any image generation tool. This daemon would only need to download the update metadata (casync index, an updater script), verify the signature, and execute the updater script.

    If you have any feedback, please let me know.

    Thanks,
    Daniel


    Re: [RFC] isar-cip-core

    Agustín Benito Bethencourt <agustin.benito@...>
     

    Hi jan and Daniel,

    On Thursday, 31 January 2019 06:33:53 CET daniel.sangorrin@... wrote:
    Hi Agustin,

    I need to create the following hierarchy on gitlab:

    cip-core/ <-- group
    tiny/ <-- subgroup
    deby <-- git repo (current cip-core.git)
    generic/ <-- subgroup
    isar <-- git repo
    I just created the new subgroup called "cip-core". I moved the project cip-core from the root tree to the new subgroup. I gave both of you owner rights in this new subgroup so you can configure it as you please. Please take a few minutes to go over the configurations so you guys can decide merge request, merge, tickets... strategies. I will be traveling the coming days but feel free to ask me through mail or IRC if you want a second opinion on how to set up the subgroup/projects. I have done it several times with a variety of use cases over the years.

    We defined a policy in which each Member company has a person as Owner of the whole CIP Group. If you think there should be two people per company to make things more fluid, please propose it. I would be fine with it. I understand sometimes it is not ideal to depend on somebody else for these things.

    I think it would be useful to agree on basic topics across the different subgroups like some common labels, milestones. boards... so we start to apply some consistency across the different groups on very basic thinks. If you think it might be a good idea I can make a proposal in the coming days.

    Best Regards


    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See https://www.codethink.co.uk/privacy.html


    Re: [RFC] isar-cip-core

    daniel.sangorrin@...
     

    Hi Agustin,

    I need to create the following hierarchy on gitlab:

    cip-core/ <-- group
    tiny/ <-- subgroup
    deby <-- git repo (current cip-core.git)
    generic/ <-- subgroup
    isar <-- git repo
    I don't have enough permissions, could you do that for me and possibly give me permissions for anything under cip-core?

    Thanks,
    Daniel

    -----Original Message-----
    From: cip-dev-bounces@... <cip-dev-bounces@...> On Behalf Of Daniel
    Sangorrin
    Sent: Monday, January 7, 2019 4:31 PM
    To: 'Jan Kiszka' <jan.kiszka@...>; 'cip-dev' <cip-dev@...>
    Subject: Re: [cip-dev] [RFC] isar-cip-core

    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Monday, January 7, 2019 3:59 PM
    To: Daniel Sangorrin <daniel.sangorrin@...>; 'cip-dev' <cip-dev@...>
    Subject: Re: [cip-dev] [RFC] isar-cip-core



    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Monday, January 7, 2019 3:59 PM
    To: Daniel Sangorrin <daniel.sangorrin@...>; 'cip-dev' <cip-dev@...>
    Subject: Re: [cip-dev] [RFC] isar-cip-core

    On 07.01.19 07:45, Daniel Sangorrin wrote:
    -----Original Message-----
    From: Jan Kiszka <jan.kiszka@...>
    Sent: Monday, January 7, 2019 2:41 PM
    To: Daniel Sangorrin <daniel.sangorrin@...>; 'cip-dev' <cip-dev@...>
    Subject: Re: [cip-dev] [RFC] isar-cip-core

    Hi Daniel,

    On 07.01.19 01:30, Daniel Sangorrin wrote:
    Hi Jan,

    Thanks for uploading isar-cip-core.

    As you noticed[1], https://gitlab.com/cip-project/cip-core/ contains a folder "deby". I created that
    folder
    with
    the intention of adding "isar" and other tools' metadata at the same folder level.

    cip-core/ <-- git repo
    deby/ <-- deby metadata
    isar/ <-- isar metadata
    eid/ <-- eid metadata

    [Note] Now that we have profiles (tiny and generic) we could add an extra folder for them.

    I think that having all of the metadata on the same repository can be good for communication. For
    example,
    after a git-pull I might notice that you updated certain kernel configuration values under the "isar" folder
    that
    should be applied to Deby's metadata as well.

    I agree that shared data like reference configs should ideally be stored in one
    place. That could be solved by having a single repos for all build systems or by
    sticking those artifacts into a separate repo. We already have
    https://gitlab.com/cip-project/cip-kernel/cip-kernel-config - maybe add the
    configs of the reference boards there?
    I said "communication" (like in a monorepo) rather than shared data, because each build tool has different
    methods to store that shared data. In the case of a kernel config, it will probably work fine, but there is always
    a possibility that we need to add some tuning on the recipe's metadata.

    When it comes to pure communication, the mailing list is a better place. We
    could route all cip-core patches through it (rather than splitting up the work
    in isolated MRs on gitlab).


    Another possibility is to use gitlab groups/subgroups in this way:

    cip-core/ <-- group
    tiny/ <-- subgroup
    deby <-- git repo
    generic/ <-- subgroup
    isar <-- git repo

    I don't have enough permissions to create groups and subgroups under cip-project though (that's the
    reason
    I used the folder approach).
    I do. If we agree on the group approach, we need to rename the existing cip-core
    repo first, and flatten its folder structure. Then I can create the cip-core
    group as well as the tiny/generic subgroups and move the repo.

    Later on, we can factor out the kernel configs. Do you see other shared data?
    Well, one could be the list of packages for each profile. However, as I mention above it will be hard to share
    exactly the same files.

    Yes, sharing the package list 1:1 will only work if the tiny profile follows the
    standard Debian binary packaging structure - does/will it?
    Not necessarily.
    For example, Deby follows the Open Embedded structure as far as I know.

    Thanks,
    Daniel



    Which way would you prefer?
    I'm leaning towards separate repos.
    OK, then let's analyze the pros and cons and decide today at the TSC meeting.
    Fine with me.

    Jan

    --
    Siemens AG, Corporate Technology, CT RDA IOT SES-DE
    Corporate Competence Center Embedded Linux
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    CIP IRC weekly meeting todayCIP IRC weekly meeting today

    SZ Lin (林上智) <SZ.Lin@...>
     

    Hi All,

    Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

    *Please note that  IRC meeting was rescheduled to 18:00 (JST) starting from the first week of Nov. according to F2F meeting discussion in ELCE.*

    US-West US-East  UK    DE     TW     JP
    02:00    05:00   09:00   10:00   17:00   18:00

    Channel:
    * irc:chat.freenode.net:6667/cip

    Agenda:

    * AI review
    * Kernel maintenance updates
    * Kernel testing
    * CIP Core

    * Software update 
    * AOB

    The meeting will take 30 min although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

    I won't be able to attend this meeting, Gavin will chair today's meeting.

    Best regards,

    SZ Lin, Moxa.


    Re: Next Debian kernel: when will it be announced?

    Zoran
     

    I finally got to the point that I can upgrade my custom VBox VM with
    Lava sans Vagrant from preseeded Debian 9 to Debian 10.

    Here is what I got (empirically):

    root@stretch1-hostname:~# cat /etc/os-release
    PRETTY_NAME="Debian GNU/Linux buster/sid"
    NAME="Debian GNU/Linux"
    ID=debian
    HOME_URL="https://www.debian.org/"
    SUPPORT_URL="https://www.debian.org/support"
    BUG_REPORT_URL="https://bugs.debian.org/"
    root@stretch1-hostname:~# uname -a
    Linux stretch1-hostname 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1
    (2018-12-22) x86_64 GNU/Linux
    root@stretch1-hostname:~#

    Cheers,
    Zoran
    _______


    On Thu, Sep 13, 2018 at 6:21 PM Agustín Benito Bethencourt
    <agustin.benito@...> wrote:

    Hi Ben,

    do you know when approximately will the Debian project announce the version of the new kernel?

    Best Regards

    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See https://www.codethink.co.uk/privacy.html
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    CIP-dev IRC weekly meeting log: week 4

    SZ Lin (林上智) <SZ.Lin@...>
     

    Hi,

    Please find the logs of CIP meeting last week in below link:

    https://irclogs.baserock.org/cip/%23cip.2019-01-24.log.html#t2019-01-24T09:00:08

    #action make patersonc admin of cip-testing mailing list

    -> Done

    SZ Lin, Moxa


    Re: Meet Bot in #cip

    SZ Lin (林上智) <szlin@...>
     

    Hi,

    Agustín Benito Bethencourt <agustin.benito@...> 於
    2019年1月25日 週五 下午5:57寫道:

    Hi,

    as you probably know, the Baserock project has been providing us the logs service for the #cip IRC channel in freenode. When the weekly dev meeting started, we all agree it would be good to add Meet Bot to those services, so keeping logs become easier as well as keeping track of the actions from previous meetings, among other improvements.

    The Meet Bot was implemented yesterday. Thanks Pedro for adding this service.

    For those of you unfamiliar with Meet Bot please read: https://wiki.debian.org/MeetBot
    Thanks to Pedro and thanks to Agustin for the notification.

    It's pity that my laptop is broken so that I may meet the bot later.

    SZ


    Best Regards

    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See https://www.codethink.co.uk/privacy.html
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    Re: Meet Bot in #cip

    Chris Paterson
     

    Thank you Pedro!

    Chris

    From: cip-dev-bounces@... <cip-dev-bounces@...
    project.org> On Behalf Of Agustín Benito Bethencourt
    Sent: 25 January 2019 09:56

    Hi,

    as you probably know, the Baserock project has been providing us the logs
    service for the #cip IRC channel in freenode. When the weekly dev meeting
    started, we all agree it would be good to add Meet Bot to those services, so
    keeping logs become easier as well as keeping track of the actions from
    previous meetings, among other improvements.

    The Meet Bot was implemented yesterday. Thanks Pedro for adding this
    service.

    For those of you unfamiliar with Meet Bot please read:
    https://wiki.debian.org/MeetBot

    Best Regards

    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See https://www.codethink.co.uk/privacy.html
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    Meet Bot in #cip

    Agustín Benito Bethencourt <agustin.benito@...>
     

    Hi,

    as you probably know, the Baserock project has been providing us the logs service for the #cip IRC channel in freenode. When the weekly dev meeting started, we all agree it would be good to add Meet Bot to those services, so keeping logs become easier as well as keeping track of the actions from previous meetings, among other improvements.

    The Meet Bot was implemented yesterday. Thanks Pedro for adding this service.

    For those of you unfamiliar with Meet Bot please read: https://wiki.debian.org/MeetBot

    Best Regards

    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See https://www.codethink.co.uk/privacy.html

    8381 - 8400 of 10158