Multi-byte NOP support on older CPUs
by Florian Weimer
We are currently emitting additional multi-byte NOPs in Fedora 28, to
support the Intel CET feature in future processors. There are some
concerns that older CPUs treat these as UD. Pentium Pro and later
(i696) are supposed to be fine, but it would be better to double-check.
Would those who care about old CPUs please run this test?
int
main (void)
{
/* endbr32 */
asm volatile (".byte 0xf3, 0x0f, 0x1e, 0xfb");
/* rdsspd %eax */
asm volatile (".byte 0xf3, 0x0f, 0x1e, 0xc8" ::: "eax");
return 0;
}
The test passes if running the program does not segfault.
You can report he results here or on the redhat-rpm-config bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1540591
Thanks,
Florian
6 years, 2 months
Lines of communication: releng, automated testing
by Adam Williamson
Hi folks!
So, the topic of x86 came up in the Fedora panel discussion session at
Devconf this week, and one of the aspects we discussed is that there's
kind of a lack of lines of communication in a few areas. One especially
that I'm interested in is compose quality.
It's not unusual for the status of nightly composes (for Branched and
Rawhide) to be different on i686 and x86_64. There can be actual arch
bugs, or just things like comps differences or lorax behaviour
differences or package dependency problems that result in i686 images
not building, or failing to work in ways that are arch-specific
somehow. When this happens, sometimes myself or Mohan Boddu (mboddu) or
Kevin Fenzi (nirik) will notice this, but we don't always have the
time/cycles to address it.
We have automated testing for nightly composes (and for updates, but at
present I'm not running the automated tests on updates) in openQA:
https://openqa.fedoraproject.org/
Ideally it'd be great if someone from this group is aware and engaged
and involved when some important x86 images are not composing, or x86
tests are failing where x86_64 tests do not. So I wanted to try and
open some lines of communication there.
Right now, there's a report-y thing run after each compose:
https://pagure.io/fedora-qa/check-compose
It generates the "compose check report" mails that are sent to devel@.
These cover the entire compose, though - so they include x86
information, but it's alongside the x86_64 info and isn't really
tailored. It would be possible to tweak check-compose (and the code
that runs it) to send an x86-focused report of some kind to this list
(or, really, anywhere else), if that would be something people would
want. That list could note when important x86 images were missing from
the compose, and when there are failed tests which did *not* fail on
x86_64, for instance. It doesn't currently have those features, but I'm
pretty sure I can add them. So, let me know if that's something folks
are interested in, and I can look at doing it.
It would also be great on an informal level to just have a known person
to poke when x86-specific issues arrive; if there's someone who's
usually hanging around in #fedora-releng (most importantly, possibly
also #fedora-qa) who we know will care about this sort of thing when
poked, that'd go quite a long way to helping, I think.
Aside from all the above, I've subscribed to this list and joined
#fedora-x86 on Freenode and will do my best to send out feelers when
there's a known x86-specific issue.
Thanks, folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6 years, 2 months
Using generic tuning for Fedora i686
by Florian Weimer
We currently build with -march=i686, which also enables tuning for the
original Pentium Pro. This seems to entirely appropriate because even
for pure i686 use, most people probably use a Pentium II or a Pentium
III or a 32-bit Atom, which have different characters. And of course,
most 32-bit users come through x86_64, which are unlikely to benefit
from Pentium Pro tuning, either.
Should we switch to -march=i686 -mtune=generic instead?
Thanks,
Florian
6 years, 2 months
KAISER needs to be enabled immediately!
by Subsentient
Hi, I'm surprised you haven't done so already, but you need to enable kernel/page table isolation
in the i686 kernel immediately!
i686 is also vulnerable to the Meltdown and Spectre
flaws in Intel CPUs, all Intel CPUs past 1995 are!
Thanks.
6 years, 3 months
