Uninitialized variables and F37
by Steve Grubb
Hello,
This is a continuation of the discussion from F36 Change: GNU Toolchain
Update.
Uninitialized variables are a big problem. They can be sources of information
exposure if parts of a buffer are not initialized. They can also cause
unexpected execution paths if the attacker can groom the memory to a value of
their choosing. If the variable is a pointer to heap, this can cause free to
corrupt memory under certain circumstances. If the uninitialized memory is
part of user input, this can lead to improper input validation. This is not
hypothetical. All of these come from a paper doing an emprical study of
android flaws. [1] The data used in the paper is here. [2]
Part of the problem is that compilers and static analysis tools can't always
find them. I created a test program that has 8 uses of unintialized variables.
Gcc 11 misses all of them. Gcc 12 finds 2. Clang 13 finds 1. cppcheck finds 2 or
3 - but does so much complaining you'd think it found all. Valgrind finds 2.
Flexelint, a commercial linter, finds 1.
Since tools can't always find them, the only option we have right now is force
initialization to something the attacker cannot control. Kees Cook started a
discussion on the llvm developers mail list a while back. He makes a very
clear argument. I would be repeating his points, so please read the original
discussion here (also read the replies):
https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html
He talks about -ftrivial-auto-var-init=zero being used for production builds
and -ftrivial-auto-var-init=<pattern> being used for debug builds. The use
is not just the kernel. Consider a server that returns data across the
network to a client. It could possibly leak crypto keys or passwords if the
returned data structure has uninitialized memory.
For more background, the creator of this technology for LLVM presented a talk
about this feature at a past LLVM developer conference:
https://www.youtube.com/watch?v=I-XUHPimq3o
He said this would have prevented over 900 fixed CVE's in Chrome and 12% of
all Android CVE's.
From deep inside the LLVM thread above, comes this nugget:
---
To add in, we (Microsoft) currently use zero initialization technology in
Visual Studio in a large amount of production code we ship to customers (all
kernel components, a number of user-mode components). This code is both C and
C++.
We already have had multiple vulnerabilities killed because we shipped this
technology in production. We received bug reports with repros that worked on
older versions of Windows without the mitigation and new versions of Windows
that do have it. The new versions don't repro, the old ones do.
---
Microsoft is also digging in to uninitialized variables. They have a lengthy
blog post that talks about extending this to heap memory. [3]
I think this would be an important step forward to turn this on across all
compilations. We could wipe out an entire class of bugs in one fell swoop.
But then, what about heap allocations? Calloc has existed for a long time. It
might be worthwhile to have a CFLAG that can tell glibc (or other allocators)
to substitute something like calloc for malloc.
Cheers,
-Steve
[1] - https://picture.iczhiku.com/resource/paper/shkeTWJEaFUuWCMc.pdf
[2] - http://ml-papers.gitlab.io/android.vulnerabilities-2017/appendix/
MSR2017/vulnerabilitiesList.html
[3] - https://msrc-blog.microsoft.com/2020/07/02/solving-uninitialized-kernel-p...
2 years
The future of FMN (Fedora Messaging Notifications)
by Aurelien Bompard
Hey folks!
We're having a look at FMN these days, and we're trying to design its replacement in our Fedora Messaging enabled world.
The current FMN has the following shortcomings:
- too slow at runtime
- slow at startup time (a couple of hours to startup…)
- complex UI
We think that this all comes from the same root cause: FMN is too flexible. It's trying to be everyone's procmail, and as a result the UI is complex and performance is hindered.
Also, in the past years we've adopted quite a few external services (Discourse, Gitlab, etc) which come with their own notification systems, so the needs of FMN users may have changed, and FMN can no longer be the one-stop-shop of notifications it aimed to be.
So we're planning to rewrite it as a much more simple notification system, with a few pre-defined things you could subscribe to, clearly presented in the UI but with less bells and whistles, and for that we're gathering your requirements.
What do you want from Fedora's notifications? We have identified the following use cases:
- I want to be notified of what happens on my artifacts (packages, containers, modules, flatpaks)
- I want to be notified of what happens on any artifact by entering its type and its name
- I want to be notified of events referring to my username
- I want to be able to follow someone (for example, my mentee)
- I want to be able to block or allow notifications from a particular application (koji, bodhi, dist-git, etc)
- I want to my notifications to be sent via email and/or IRC
Are there other use cases that would make your contributor's life easier? We're not committing to implementing everything that will be suggested here, since we want to keep the app as simple as we can, but we're very interested in your use cases.
And if you want to do something very complex with notifications, we can also help you write a Fedora Messaging callback that will give you the full power of the message bus :-)
Thanks for your help!
Aurélien
2 years
F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
== Summary ==
Make UEFI a hardware requirement for new Fedora installations on
platforms that support it (x86_64). Legacy BIOS support is not
removed, but new non-UEFI installation is not supported on those
platforms. This is a first step toward eventually removing legacy
BIOS support entirely.
== Owner ==
* Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
Konečný]], [[User:bcl| Brian C. Lane]]
* Email: rharwood(a)redhat.com
== Detailed Description ==
UEFI is defined by a versioned standard that can be tested and
certified against. By contrast, every legacy BIOS is unique. Legacy
BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
and on its way out. As it ages, maintainability has decreased, and
the status quo of maintaining both stacks in perpetuity is not viable
for those currently doing that work.
It is inevitable that legacy BIOS will be removed in a future release.
To ease this transition as best we can, there will be a period (of at
least one Fedora release) where it will be possible to boot using the
legacy BIOS codepaths, but new installations will not be possible.
While it would be easier for us to cut support off today, our hope is
that this compromise position will make for a smoother transition.
Additional support with issues during the transition would be
appreciated.
While this will eventually reduce workload for boot/installation
components (grub2 reduces surface area, syslinux goes away entirely,
anaconda reduces surface area), the reduction in support burden
extends much further into the stack - for instance, VESA support can
be removed from the distro.
Fedora already requires a 2GHz dual core CPU at minimum (and therefore
mandates that machines must have been made after 2006). Like the
already accepted Fedora 37 change to retire ARMv7 support, the
hardware targeted tends to be rather underpowered by today’s
standards, and the world has moved on from it. Intel stopped shipping
the last vestiges of BIOS support in 2020 (as have other vendors, and
Apple and Microsoft), so this is clearly the way things are heading -
and therefore aligns with Fedora’s “First” objective.
== Feedback ==
Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
Important, relevant points from that thread (yes, I reread the entire
thread) that have informed this change:
* Some machines are BIOS-only. This change does not prevent their use
yet, but they are effectively deprecated. grub2 (our default
bootloader) is already capable of both BIOS and UEFI booting.
* Drawing a clear year cutoff, let alone a detailed list of hardware
this change affects, is basically impossible. This is unfortunate but
unlikely to ever change.
* There is no migration story from Legacy BIOS to UEFI -
repartitioning effectively mandates a reinstall. As a result, we
don’t drop support for existing Legacy BIOS systems yet, just new
installations.
* There is no way to deprecate hardware without causing some amount of friction.
* While at the time AWS did not support UEFI booting, that is no
longer the case and they support UEFI today.
== Benefit to Fedora ==
UEFI is required for many desirable features, including applying
firmware updates (fwupd) and supporting SecureBoot. As a standalone
change, it reduces support burden on everything involved in installing
Fedora, since there becomes only one way to do it per platform.
Finally, it simplifies our install/live media, since it too only has
to boot one way per arch. Freedom Friends Features First - this is
that last one.
== Scope ==
* Proposal owners:
** bootloaders: No change (existing Legacy BIOS installations still supported).
** anaconda: No change (there could be only optional cleanups in the
code). However, it needs to be verified.
** Lorax: Code has already been written:
https://github.com/weldr/lorax/pull/1205
* Other developers:
** libvirt: UEFI works today, but is not the default. UEFI-only
installation is needed for Windows 11, and per conversations, libvirt
is prepared for this change.
** Virtualbox: UEFI Fedora installs are working and per virtualbox
team, UEFI will be/is the default in 7.0+.
** The Hardware Overview page should be updated to mention the UEFI
requirement: https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
* Release engineering: [https://pagure.io/releng/issue/10738 #Releng
issue 10738]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Systems currently using Legacy BIOS for booting on x86_64 will
continue to do so.
However, this modifies the baseline Fedora requirements and some
hardware will no longer be supported for new installations.
== How To Test ==
UEFI installation has been supported for quite a while already, so
additional testing there should not be required.
== User Experience ==
Installs will continue to work on UEFI, and will not work on Legacy
BIOS. Our install media is already UEFI-capable.
== Dependencies ==
None
== Contingency Plan ==
Leave things as they are. Code continues to rot. Community
assistance is required to continue the status quo. Current owners
plan to orphan some packages regardless of whether the proposal is
accepted.
Another fallback option could be, if a Legacy BIOS SIG organizes, to
donate the relevant packages there and provide some initial mentoring.
Longer term, packages that cannot be wholly donated could be split,
though it is unclear whether the synchronization thereby required
would reduce the work for anyone.
* Contingency mechanism: Delay until next release.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
See release notes.
== Release Notes ==
Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
favor of UEFI. While systems already using Legacy BIOS to boot are
still supported, new legacy BIOS installations on these architectures
are no longer possible. Legacy BIOS support will be removed entirely
in a future Fedora.
(Additionally, the Hardware Overview page should be updated to mention
the UEFI requirement.)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years
Heads-up: grpc 1.41.0 coming to Rawhide with C (core) and C++ soname
bumps
by Ben Beasley
In one week (October 6), or slightly later, I will build grpc 1.41.0 for
Rawhide (F36). Fedora 35 will remain on 1.39.1.
As is traditional for minor releases of grpc, the C++ ABI was broken
(soversion bumped from 1.40 to 1.41). This time, the C (core) ABI was
also broken (soversion bumped from 18 to 19).
I will coordinate builds in a side tag of packages that use the C (core)
and/or C++ libraries. Maintainers of the following packages should have
received this email directly:
• bear
• frr
• perl-grpc-xs
Packages that use the Python bindings should be unaffected, as there
should be no incompatible API changes:
• buildstream
• python-chirpstack-api
• python-etcd3
• python-google-api-core
• python-google-cloud-core
• python-grpc-google-iam
• python-opencensus (orphaned)
• python-opencensus-proto
• python-opentelemetry
• python-pytest-grpc
• python-xds-protos
2 years
F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Silverblue_Kinoite_readonly_sysroot
== Summary ==
This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.
Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.
== Owner ==
* Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš
Popela]], [[User:jkonecny| Jiří Konečný]]
* Email: siosm(a)fedoraproject.org, tpopela(a)fedoraproject.org, jkonecny(a)redhat.com
* FESCo shepherd: [[User:Ngompa| Neal Gompa]] ngompa(a)fedoraproject.org
== Detailed Description ==
On rpm-ostree based systems, the real root (the root directory of the
root partition on the disk) is mounted under the `/sysroot` path. By
default it contains the state of the system (the content of `var` and
`etc`) as well as the system versions themselves (each versioned copy
of `/usr`) in the ostree repository (`/ostree/repo`).
This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.
Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.
Example of issue: https://github.com/fedora-silverblue/issue-tracker/issues/232
This change replicates for Fedora Silverblue/Kinoite what has been
done in Fedora CoreOS in a previous release.
== Feedback ==
None so far.
== Benefit to Fedora ==
This will make Fedora Silverblue/Kinoite more robust to accidental
damage from users.
== Scope ==
* Proposal owners:
** Work on the changes requires for new installations (potentially
Anaconda configuration changes) and support for in place updates for
existing installations (requires a two step process).
* Other developers:
** Potential Anaconda changes required.
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
We will create a systemd unit that perform the updates in place for
existing systems. This will require a two step process (changing the
existing kernel arguments, and then enabling the ostree feature). Once
the feature is enabled, user won't be able to rollback to previous
deployments where the kernel argument is not set. We will have to
clearly document that in the documentation for easier troubleshooting.
== How To Test ==
Only try the following if you are confortable debugging an un-bootable
system and have made backups!
`$ sudo rpm-ostree kargs --append-if-missing=rw`
`$ sudo ostree config --repo=/sysroot/ostree/repo set "sysroot.readonly" "true"`
`$ sudo systemctl reboot`
Note that you can not "rollback" to the previous deployment to undo
this change. You will have to boot into a Live ISO and edit the config
file in the ostree repo to remove this config option.
== User Experience ==
There should be no visible change in user experience.
== Dependencies ==
Requires changes in Anaconda (maybe just config?) to set default kargs
and property on ostree repo for new installations.
== Contingency Plan ==
Revert the change before the release.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
TODO
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years
A way to prepare custom source tarballs from .spec file to improve CI
experience
by Vít Ondruch
Hi,
It is quite common, to have some sources, which are not available as a
tarball from upstream. In case of rubygem- packages, they quite often do
not ship their test suites. In this case, our .spec file contains
something like [1]:
~~~
# Tests are not packaged with the gem. You may get them like so:
# git clone --no-checkout https://github.com/discourse/mini_mime
# git -C mini_mime archive -v -o mini_mime-1.1.0-test.txz v1.1.0 test
Source1: %{gem_name}-%{version}-test.txz
~~~
This is quite fine. However, if there is opened PR [2], the CI would
work only as long sources are in the look a side cache, which is not
always desirable, because this might be just some WIP.
I while ago, I proposed [3] this "executable" comments instead:
~~~
Source1: %{gem_name}-%{version}-test.txz
%{echo:%(
[ ! -e %{S:1} ] &&
rm -rf %{name} &&
git clone https://github.com/discourse/mini_mime %{name} &&
git -C %{name} archive -v -o %{S:1} v%{version} test/
)}
~~~
I know, that some may say "it won't work in Koji", that is true, but
won't necessarily be issue for CI. The other argument might be "it is
creating some random tarball from random source", but if the accompanied
`sources` file contains the right checksums, `fedpkg srpm` ensures that
only the tarballs with the right content is used.
While others might just handwavy upload the random sources into look a
side cache, I think this is way better approach.
Now I am looking for feedback about general approach. Of course it could
be somehow polished and improved to hide some boiler plate.
Vít
[1]:
https://src.fedoraproject.org/rpms/rubygem-mini_mime/blob/c25611d64d17c37...
[2]: https://src.fedoraproject.org/rpms/rubygem-mini_mime/pull-request/2
[3]: https://pagure.io/packaging-committee/issue/1132#comment-769233
2 years
License change: python-starlette is now “BSD and MIT”
by Ben Beasley
In release 0.19.1, python-starlette adds one Python module under the MIT
license (bundling a subset of python-pep562, which I have handled
according to the relevant guidelines).
The License field therefore changes from “BSD” to “BSD and MIT”.
2 years
