* cpuinfo: Fix WinChip and Cyrix/NSC CPU name and cache info
Always populate the cache info from extended CPUID, it is not used for
Intel CPUs, even though it is present, and is useful for non-Intel CPUs.
Fix the CPU name and cache sizes for Centaur and Cyrix/NSC CPUs without
brand string, which are the WinChip C6 and all Cyrix CPUs except the
Media GXm.
For the Media GXm and Geode GXm/GXLV/GX1, which are available with both
Cyrix and NSC vendor strings, hardcode the L1 cache size. The Geode GX2
uses standard cache info.
* Add 'Intel' in CPU names for older CPUs
* Add 'Transmeta' and 'IDT' in CPU names for older CPUs
-------
Co-authored-by: Sam Demeulemeester <github@x86-secret.com>
* Support cache and temperature info for VIA/Centaur/Zhaoxin CPUs
Use extended CPUID for VIA C3/C7/Nano cache information.
Use MSR reads for Nano/Zhaoxin and VIA C7 processor temperature.
Tested on VIA C7-D 1.5GHz.
* Small code conventions fixes
* Fix overallocation of cpuid_cache_info_t union (From PR #263)
---------
Co-authored-by: Sam Demeulemeester <github@x86-secret.com>
We have a .setup section in the EFI image that contains the remainder of
the Linux boot header and the real-mode setup code to support booting via
an intermediate bootloader. This sits between the PE header and the .text
section. We don't want the EFI loader to load this section, so simply
increase the SizeOfHeader field in the PE header to cover it.
The AP stacks section was being discarded by the linker because the
change in section name and attributes hadn't been propagated from
the startup64.S to startup32.S.
The alignment characteristics are only valid in COFF files. The section
alignment for image files is determined by the SectionAlignment field
in the image header.
When the reloc and sbat sections were added by PR #34, three bugs were
introduced:
1. The virtual address and size fields in the PE headers were set to the
same values as the raw address and size fields. This is incorrect, because
the sections in the image file are aligned on 512 byte boundaries, but when
loaded into memory they need to be aligned on 4096 byte boundaries.
2. The value programmed into the SizeOfImage field was too large, as it
double-counted the region before the start of the .text section.
3. The value programmed into the SizeOfImage field no longer included the bss
size. That potentially allowed the EFI loader to load the image immediately
before a reserved region of memory without leaving enough space for the bss
section.
This commit fixes those bugs by calculating both file and virtual memory
offsets & sizes in the ld script. Note that we can't add a bss section to the
EFI image because many EFI loaders fail to load images that have uninitialised
data sections. Instead the text region size in virtual memory is increased
to include the bss size.
This fixes issue #243. It also eliminates the gaps between sections
observed in issue #202.
A headless EFI system may have no GOP devices. In this case, disable
output to the physical display, but continue to write to the shadow
buffer. This allows operation via a serial console.
* For 64-bit images, use the physical address as the test pattern in test 2.
This will make it easier to diagnose faults.
* Disable test 1 by default (issue #155).
Test 2 provides the same test coverage. Test 1 may make it slightly easier
to diagnose faults with a 32-bit image, so leave it as an option.
* For 32 bit images, use the physical address to generate the offset in test 2.
Detecting a stage change and using that to reset the offset counter
could fail when the config menu was used to skip to the next test
(issue #224).
* BadRAM: Rename pattern -> patterns
* BadRAM: Refactor COMBINE_MASK and add clarifying comment
* BadRAM: Extract DEFAULT_MASK into variable
* BadRAM: Add is_covered() for checking if pattern is already covered by one of the existing patterns
* BadRAM: Initialize patterns to 0
* BadRAM: Change how addr/masks are merged to minimize number of addresses covered by badram
Prior to this patch, a list of up to MAX_PATTERNS (=10) addr/mask tuples
(aka. pattern) were maintained, adding failing addresses one by one to
the list until it was full. When full, space was created by forcing a
merge of the new address with the existing pattern that would grow the
least (with regards to number of addresses covered by the pattern) by
merging it with the new address. This can lead to a great imbalance in
the number of addresses covered by the patterns. Consider the following:
MAX_PATTERNS=4 (for illustrative purposes).
The following addresses are faulted and added to patterns:
0x00, 0x10, 0x20, 0x68, 0xa0, 0xb0, 0xc0, 0xd0
This is the end result with the implementation prior to this commit:
patterns = [
(0x00, 0xe8),
(0x00, 0x18),
(0x68, 0xf8),
(0x90, 0x98)
]
Total addresses covered: 120.
This commit changes how the merges are done, not only considering a
merge between the new address and existing patterns, but also between
existing patterns. It keeps the patterns in ascending order (by .addr)
in patterns, and a new address is always inserted into patterns (even if
num_patterns == MAX_PATTERNS, patterns is of MAX_PATTERNS+1 size). Then,
if num_patterns > MAX_PATTERNS, we find the pair of patterns (only
considering neighbours, assuming for any pattern i, i-1 or i+1 will
be the best candidate for a merge) that would be the cheapest to
merge (using the same metric as prior to this patch), and merge those.
With this commit, this is the result of the exact same sequence of
addresses as above:
[
(0x00, 0xe0),
(0x68, 0xf8),
(0xa0, 0xe8),
(0xc0, 0xe8)
]
Total addresses covered: 72.
A drawback of the current implementation (as compared to the prior)
is that it does not make any attempt at merging patterns until
num_patterns == MAX_PATTERNS, which can lead to having several patterns
that could've been merged into one at no additional cost. I.e.:
patterns = [
(0x00, 0xf8),
(0x08, 0xf8)
]
can appear, even if
patterns = [
(0x00, 0xf0)
]
represents the exact same addresses with one pattern instead of two.
* fixup! BadRAM: Change how addr/masks are merged to minimize number of addresses covered by badram
Co-authored-by: Anders Wenhaug <anders.wenhaug@solutionseeker.no>
smp_init() used to be called after the startup dialogue, so F2 only
needed to change the enable_smp flag. Now smp_init() is called earlier,
we also need to reset num_available_cpus.
This patch adds a new section, ".sbat", which allows for the revocation
of signed binaries given a numeric value representing the set of bugs
which allow for arbitrary code execution, and therefore a Secure Boot
breakout, in a given family of binaries.
In this case, the class is defined as "memtest86+", and the current set
of bugs is 1. This doesn't imply that we're aware of bugs currently,
merely that when we change it to 2, any bugs that /have/ been discovered
have been fixed.
Documentation for how SBAT works can be found at the following URLs:
https://github.com/rhboot/shim/blob/main/SBAT.mdhttps://github.com/rhboot/shim/blob/main/SBAT.example.md
Signed-off-by: Peter Jones <pjones@redhat.com>
In the past, we've seen some problems with some EFI loaders refusing to
load a binary that has both a .text section with the VMA set and no
relocations, when the VMA set to load is already allocated for some
other purpose.
This patch adds a dummy absolute relocation from 0 to 0, so the loader
can always feel like it has done something useful.
Signed-off-by: Peter Jones <pjones@redhat.com>
SizeOfImage is defined as:
The size (in bytes) of the image, including all headers, as the image
is loaded in memory. It must be a multiple of SectionAlignment.
SizeOfHeaders likewise is defined as:
The combined size of an MS-DOS stub, PE header, and section headers
rounded up to a multiple of FileAlignment.
Currently SizeOfImage represents .bss and .text, but it doesn't include
.header or .setup, nor any sections we'll add later, and there's nothing
enforcing that it matches SectionAlignment. Additionally, since .bss is
being set up in our running code and /not/ by the loader, the current
value is dangerously high, as in the event there is an error in the
section table, it could potentially lead the loader to mark memory
allocated at runtime holding user-supplied data by any EFI binary loaded
before us as executable.
This patch adds a new symbol, _img_end, which is after .text and is
rounded up to 4kB (which is also what SectionAlignment is set to). It
also adds a local label, anchored with ".org 512", and uses that to set
SizeOfHeaders - this will ensure the build fails without outputting and
invalid binary if the headers take too much space.
Signed-off-by: Peter Jones <pjones@redhat.com>
Currently, the PE headers we create in boot/header.S do not allocate
space for any Data Directory entries, as they haven't been needed.
In order to support signatures and compatibility with some loaders, we
need the Data Directory to be populated at least enough to set
DataDirectory.Certs and DataDirectory.BaseReloc.
This patch extends that space enough to include those entries.
Signed-off-by: Peter Jones <pjones@redhat.com>
This changes header.S to use the constants defined in peimage.h to for
the values in its structure, making it a lot easier to debug.
Signed-off-by: Peter Jones <pjones@redhat.com>
This adds a header file to describe the PE binary we're building. This
has constants defined for all the values we use in the PE headers, as
well as the structures for reference (guarded by #ifdef __ASSEMBLY__).
This particular peimage.h is originally from binutils-2.10.0.18, which
is GPLv2 licensed, and is copyright the Free Software Foundation. I've
added the few additional fields we need.
Signed-off-by: Peter Jones <pjones@redhat.com>
This patch makes it so we use "gcc -x assembler-with-cpp" to build our
.S files, instead of translating them to .s files and assembling
directly. This allows us to use header files and simple symbolic
arithmetic more conveniently in .S files, and at the same time reduces
the number of temporary files created when building.
Signed-off-by: Peter Jones <pjones@redhat.com>
If the memory map contains very small segments and we have many active CPUs,
the tests that split the segments into chunks distributed across the CPUs may
end up with chunks that are too small for the test algorithm. With 4K pages
and the current limit of 256 active CPUs, this is currently only a problem
for the block move and modulo-n tests, but if we ever support more than 512
active CPUs, it could affect the other tests too.
For now, just skip segments that are too small in the affected tests. As it
only affects the block move and modulo-n tests and only affects very small
regions of memory, the loss of test coverage is negligable.
This may fix issue #216.
By default, don't re-display FAIL banner after it has been discarded (#130 & #173)
Add an option to re-display FAIL banner even if previously discarded
