http://bugzilla.opensuse.org/show_bug.cgi?id=1158673http://bugzilla.opensuse.org/show_bug.cgi?id=1158673#c7
Dominique Leuenberger <dimstar(a)opensuse.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |f4tmike(a)web.de
--- Comment #7 from Dominique Leuenberger <dimstar(a)opensuse.org> ---
*** Bug 1173553 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173567
Bug ID: 1173567
Summary: [ARM] lockdown bypass for loading unsigned modules
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.2
Hardware: aarch64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: guillaume.gardet(a)arm.com
QA Contact: qa-bugs(a)suse.de
CC: afaerber(a)suse.com, dmueller(a)suse.com
Found By: ---
Blocker: ---
There is an exploit on ARM SecureBoot. The lockdown can be bypassed for loading
unsigned modules.
See: https://www.openwall.com/lists/oss-security/2020/06/14/1
There is a WIP patch to harden the AML/memory interaction, preventing AML code
to poke around in memory:
http://lists.infradead.org/pipermail/linux-arm-kernel/2020-June/580418
This final patch will need to go to supported SLE/Leap.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1100695
Matthias Brugger <mbrugger(a)suse.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mbrugger(a)suse.com,
| |nsaenzjulienne(a)suse.com
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1173483https://bugzilla.suse.com/show_bug.cgi?id=1173483#c3
Thorsten Kukuk <kukuk(a)suse.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(rbrown(a)suse.com) |
--- Comment #3 from Thorsten Kukuk <kukuk(a)suse.com> ---
If we change the KillMode to something else than "none", the systemctl reboot
command will be killed during reboot with rebootmgrd, so the reboot will never
happen.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165922
Bug ID: 1165922
Summary: s390x control.xml has wrong repos
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: S/390-64
OS: Other
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Basesystem
Assignee: slindomansilla(a)suse.com
Reporter: fvogt(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
/etc/YaST2/control.xml (part of skelcd-control-openSUSE) contains the wrong
repo URLs for s390x, e.g. http://download.opensuse.org/tumbleweed/repo/oss/.
This means that the wrong repos are used in the network installation,
containers and other images.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1084631https://bugzilla.suse.com/show_bug.cgi?id=1084631#c6
--- Comment #6 from jun wang <junguo.wang(a)suse.com> ---
(In reply to Adam Majer from comment #5)
> (In reply to jun wang from comment #4)
> > I am testing nasm update, and when checking the url
> > https://build.suse.de/build/SUSE:Maintenance:15602/SUSE_SLE-15_Update/x86_6…
> > nasm.SUSE_SLE-15_Update/_log, I get many these output:
> >
> > [ 95s] cd test && perl -I./perllib -I. performtest.pl --nasm=../nasm *.asm
> > [ 95s] Can't compare at _file_/bin file stdout
> > [ 95s] Can't compare at _version/version file stdout
> > [ 95s] Can't compare at a32offs/unoptimized file a32offs.bin
> > [ 95s] Can't compare at a32offs/optimized file a32offs.bin
> >
> > is this OK?
>
> Short answer: Yes.
>
> Long answer: NASM unit tests are mostly focused on regression detection.
> What they are suppose to be used for,
>
> 1. make
> 2. make golden
> 3. <do changes here>
> 4. make
> 5. make test
>
> The `make test` then compares output of the "golden" output with the test
> run. If there are any changes, it *could* indicate a regression that need to
> be investigated.
>
> The "golden" directory of binaries is not shipped by upstream that's why
> it's complaining. But nasm is called before the attempted comparison so if
> there is some major nasm failure on execution, like segfault, I think we
> would see it in the log.
wonderful answer. Thank you.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1084631https://bugzilla.suse.com/show_bug.cgi?id=1084631#c5
--- Comment #5 from Adam Majer <amajer(a)suse.com> ---
(In reply to jun wang from comment #4)
> I am testing nasm update, and when checking the url
> https://build.suse.de/build/SUSE:Maintenance:15602/SUSE_SLE-15_Update/x86_6…
> nasm.SUSE_SLE-15_Update/_log, I get many these output:
>
> [ 95s] cd test && perl -I./perllib -I. performtest.pl --nasm=../nasm *.asm
> [ 95s] Can't compare at _file_/bin file stdout
> [ 95s] Can't compare at _version/version file stdout
> [ 95s] Can't compare at a32offs/unoptimized file a32offs.bin
> [ 95s] Can't compare at a32offs/optimized file a32offs.bin
>
> is this OK?
Short answer: Yes.
Long answer: NASM unit tests are mostly focused on regression detection. What
they are suppose to be used for,
1. make
2. make golden
3. <do changes here>
4. make
5. make test
The `make test` then compares output of the "golden" output with the test run.
If there are any changes, it *could* indicate a regression that need to be
investigated.
The "golden" directory of binaries is not shipped by upstream that's why it's
complaining. But nasm is called before the attempted comparison so if there is
some major nasm failure on execution, like segfault, I think we would see it in
the log.
--
You are receiving this mail because:
You are on the CC list for the bug.