Backporting of security patches for Intel i40e drivers required?
masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
Hi, Jan-san, All,
At the IRC meeting today, we identified the following new CVEs are not in LTS4.4 yet. - CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for mainline and 4.19+ These are for i40e driver for Intel. The kernel team would like to know whether their backporting is needed or not. For details of those CVE checking results, please see the following. https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/merge_requests/75/diffs Regarding the discussion of the IRC meeting, please see the following. https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.00.log.html Best regards, -- M. Kudo
|
|
Re: CIP IRC weekly meeting today
Chen-Yu Tsai (Moxa) <wens@...>
On Thu, Oct 8, 2020 at 8:57 AM masashi.kudo@...
<masashi.kudo@...> wrote: I might not make it. Here's this week's update: Five new CVEs: - CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 [net/i40e] - Fixed for mainline and 4.19+ - This is enabled in Siemens x86 configs for both 4.4 and 4.19 and we should probably backport them. - CVE-2020-25643 [hdlc_ppp] - Fixed in all current stable kernels - CVE-2020-26541 [UEFI secure boot] - Fix posted but hasn't landed I also reviewed some patches from Daniel for cip-kernel-sec on the mailing list. ChenYu * Kernel testing
|
|
Re: [cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs
Chen-Yu Tsai (Moxa) <wens@...>
On Fri, Sep 25, 2020 at 12:01 PM Daniel Sangorrin
<daniel.sangorrin@...> wrote: Looks like all the new descriptions were copied from MITRE. Reviewed-by: Chen-Yu Tsai (Moxa) <wens@...>
|
|
Re: [cip-kernel-sec 2/3] report_affected: Delete extra blank lines between CVEs
Chen-Yu Tsai (Moxa) <wens@...>
On Thu, Oct 8, 2020 at 3:59 PM Chen-Yu Tsai <wens@...> wrote:
Jumped the gun. This patch is no longer needed if you use join() to combine the lines.
|
|
Re: [cip-kernel-sec 2/3] report_affected: Delete extra blank lines between CVEs
Chen-Yu Tsai (Moxa) <wens@...>
On Fri, Sep 25, 2020 at 12:00 PM Daniel Sangorrin
<daniel.sangorrin@...> wrote: Reviewed-by: Chen-Yu Tsai (Moxa) <wens@...> Though these occurrences seem to be very rare. ---
|
|
Re: [cip-kernel-sec 1/3] report_affected: word-wrap for the 'description'
Chen-Yu Tsai (Moxa) <wens@...>
On Fri, Sep 25, 2020 at 12:00 PM Daniel Sangorrin
<daniel.sangorrin@...> wrote: I believe it would be better to include the "CVE => " string in the full text passed to textwrap. That would make all lines properly wrapped at the given width. Also, textwrap can handle indentation for subsequent lines, so you don't have to handle that yourself. And it might be easier to read if they matched up with the beginning of the description in the first line. Last, you could use join() to combine the lines. So I would rewrite the part as: text = cve_id + ' => ' + kernel_sec.issue.load(cve_id).get('description', 'None') print('\n'.join(textwrap.wrap(text, 80, subsequent_indent=' ' * (len(cve_id) + 4), break_long_words=False))) ChenYu Moxa + print(cve_id, '=>',wrap_description)
|
|
Re: CIP IRC weekly meeting today
Nobuhiro Iwamatsu
Hi Kudo-san,
toggle quoted messageShow quoted text
Sorry, I can not participate IRC meeting today.
-----Original Message-----No update. 2. Check whether CVE-2020-25284 needs to be backported to 4.4-rtI reviewed 4.4.y-rc. * Kernel testingBest regards, Nobuhiro
|
|
Re: [ANNOUNCE] v4.19.148-cip35-rt15
Nobuhiro Iwamatsu
Hi,
toggle quoted messageShow quoted text
-----Original Message-----Sorry, this may be wrong. If 151 isn't released this weekend, I'll cherry pick this commit, and release new CIP kernel. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-4.19.y&id=1fa5848fae409511eda2c6ee4f8ad9e42a0cb3c1 And I think we can use it to release the cip-rt tree.Best regards, Nobuhiro
|
|
Re: [ANNOUNCE] v4.19.148-cip35-rt15
Nobuhiro Iwamatsu
Hi Pavel,
toggle quoted messageShow quoted text
-----Original Message-----Yes, I think so. Perhaps 4.19.151 will be released this weekend. And this week is the release week of the CIP kernel. And I think we can use it to release the cip-rt tree. Best regards, Nobuhiro
|
|
Re: CIP IRC weekly meeting today
Kento Yoshida
Hi Kudo-san and all,
toggle quoted messageShow quoted text
I'll be absent today. And, I'll report here as an alternative to attendance. Both minor updates were once reported, but since they are protracted, I will summarize again here. Major updates: There is no major update this week. Minor updates: 1. Gap assessment for the development process (IEC 62443-4-1): The report from the certification body, whether development process for OSS meets to the IEC 62443-4-1 standard, is delayed. But, perhaps we can get it the end of this week. And then, we'll plan to share the documents on the development process that reflects the feedback from the report. 2. Gap assessment for security features of security packages we suggested (IEC 62443-4-2): We started review security features of security packages we suggested to add as CIP core packages. The completion date is scheduled by the end of December. After this, we'll continue to proceed our suggestion, now it's pended. Regards, Kent
-----Original Message-----
|
|
CIP IRC weekly meeting today
masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
Hi all,
Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today. *Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting* https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=10&day=8&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248 USWest USEast UK DE TW JP 02:00 05:00 10:00 11:00 17:00 18:00 Channel: * irc:chat.freenode.net:6667/cip Last meeting minutes: https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-01-09.00.log.html Agenda: * Action item 1. Combine root filesystem with kselftest binary - iwamatsu 2. Check whether CVE-2020-25284 needs to be backported to 4.4-rt -> Delete rbd ( Ceph block device ) from 4.4-rt x86 config - iwamatsu -> Done, so will be closed today. * Kernel maintenance updates * Kernel testing * Software update * CIP Security * 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. Best regards, -- M. Kudo Cybertrust Japan Co., Ltd.
|
|
Re: [ANNOUNCE] v4.19.148-cip35-rt15
Pavel Machek
Hi!
FYI:Yes, and the revert is now queued to 4.19-stable, too. So.. what do we want to do here? We can merge 4.19.151 to -cip when it is released, and I can then release new -cip-rt that works on renesas boards... Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
|
|
Re: [cip-kernel-sec] reports: add script to convert reports to csv format
Daniel Sangorrin <daniel.sangorrin@...>
Hello Ben,
toggle quoted messageShow quoted text
Thanks a lot for your review and sorry for taking your time. We will have an internal review and take your comments into account to prepare a new proposal. Kind regards, Daniel
-----Original Message-----
|
|
Re: [ANNOUNCE] v4.19.148-cip35-rt15
Nobuhiro Iwamatsu
Hi,
toggle quoted messageShow quoted text
FYI: https://patchwork.ozlabs.org/project/netdev/patch/20200922072931.2148-1-geert+renesas@glider.be/ Best regards, Nobuhiro
-----Original Message-----
|
|
Re: [cip-kernel-sec] reports: add script to convert reports to csv format
Ben Hutchings <ben.hutchings@...>
On Fri, 2020-09-25 at 14:07 +0900, Daniel Sangorrin wrote:
The text version is probably enough for developers but[...] I think this script is trying to do too many different things: 1. Importing data from NVD 2. Importing data from Debian security tracker 3. Parsing an existing report (!) 4. Generating a new report 1. If there's useful information from NVD that belongs in reports, and the license allows us to redistribute it, we should add an import script that adds that to the issue files (and extend the schema if necessary). We can then use that in any of the reporting scripts. 2. I'm not sure why the script is using Debian's general security tracker. Debian's kernel-sec normally has better information for kernel issues, and the import_debian.py script already imports that. 3. The output of report_affected.py is intended to be human-readable, and just happens to be relatively easy to parse. If you want to use its output as input, that should either be done by adding a structured format (e.g. JSON) for the intermediate file, or by sharing code between the two reporting scripts so there's no need to use an intermediate file. Other comments: - The new script needs to be documented in README.md. - Any files created in the process of importing data should go under the import/ subdirectory. - Error handling needs improvement, e.g.: +def download_file(src, file, bar=""):This doesn't check whether there was a network error; it retries in case of *any* error. The except block should specify which exception types we want to handle. + if not os.path.exists(file):Error messages should go to stderr. + exit(1)This should call sys.exit. Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
|
|
Re: [ANNOUNCE] v4.19.148-cip35-rt15
Nobuhiro Iwamatsu
Hi,
toggle quoted messageShow quoted text
This issue seems to occur randomly. # cip+rt kernel NG: https://lava.ciplatform.org/scheduler/job/57129 https://lava.ciplatform.org/scheduler/job/57842 OK: https://lava.ciplatform.org/scheduler/job/57851 https://lava.ciplatform.org/scheduler/job/57841 # 4.19.148+cip kernel NG: https://lava.ciplatform.org/scheduler/job/58836 OK: https://lava.ciplatform.org/scheduler/job/58837 We may need to confirm these relationships with CIP kernel patches. Best regards, Nobuhiro
-----Original Message-----
|
|
Re: [ANNOUNCE] v4.19.148-cip35-rt15
Pavel Machek
Hi!
Yes, I did that, as the changelog explains. Sorry.New realtime trees should be available at kernel.org.Thank you for the release. I had to select from few bad options: 4.19.147-rt release is not available and previous release is too old. So -cip-rt is based on 4.19.148-rt, and it brings in the bad commit. I thought about reverting it for release, but all I'd get would be rejects, as it really needs to be solved in -cip, not -cip-rt. Proper solution is likely updating 4.19-cip to 4.19.148, first. Then figuring out what is the clean way to solve the problem, and then creating new -rt release. But that will likely take more than few days, and it will end up with different release number. I can create new -cip-rt release when that is done. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
|
|
Re: [ANNOUNCE] v4.19.148-cip35-rt15
Chris Paterson
Hello Pavel,
From: Pavel Machek <pavel@...>Thank you for the release. So we're releasing a Kernel that we know doesn't boot on one of CIP's reference platforms? Or did you already revert the above patch as part of your release? Thanks, Chris
|
|
Re: [isar-cip-core] image: export dpkg status file for debsecan
Jan Kiszka <jan.kiszka@...>
On 30.09.20 04:08, Daniel Sangorrin wrote:
Although the currently exported manifest probably hasThis is just a copy-out, I don't see the chroot need here. +}Please avoid code duplication. We have means like "require some.inc" in bitbake. I'm also wondering if this should go to isar upstream directly. debsecan is a generic Debian tool, nothing CIP-specific per se. Jan
|
|
[ANNOUNCE] v4.19.148-cip35-rt15
Pavel Machek
Hi!
New realtime trees should be available at kernel.org. Trees are available at https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt-rebase And their content should be identical. This patch merges 4.19.148-stable into -cip-rt (because that's what recent -rt is based on, and older -rt tree is too old). Unfortunately, that brings regression with ethernet on Renesas Arm64 targets, which will prevent boot, and fail tests etc. Kernel that should work ok on Renesas Arm64 machines can be obtained by reverting fb3a780e7a76cf8efb055f8322ec039923cee41f "ravb: Fixed to be able to unload modules" on top of -cip-rt release. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
|
|