of knowing whether another field added in the reserved
bits could change the interpretation of the image.
- Josh Triplett
e file. Would it be better to split out the sme_enable()
> > and other boot routines into a separate file or just apply the
> > $(nostackp) to the whole file?
>
> Josh might have a better idea here... CCed.
I'm the stack validation guy, not the stack protection guy :-)
B
ion allows mappings of arbitrary size.
>
> Reported-by: Môshe van der Sterre <m...@moshe.nl>
> Tested-by: Môshe van der Sterre <m...@moshe.nl>
> Cc: Josh Triplett <j...@joshtriplett.org>
> Cc: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com>
> Cc: Bori
ing the page table switch to efi_pgd.
The original motivation for efi_lookup_mapped_addr came from
early_ioremap printing a warning if used on an address range already
mapped as RAM. Does early_mem* handle that case correctly without a
warning? Because not all firmware places the BGRT image in boot
s
On Thu, Jul 30, 2015 at 06:33:41PM +0200, Sebastian Andrzej Siewior wrote:
On 07/29/2015 06:41 PM, Josh Triplett wrote:
This is correct. However I miss the point of saving the image in the
first place. From what I see is that I have now 272 KiB in memory which
are never used again
on kexec entry. This hint is set via setup_data / SETUP_EFI
since commit 1fec053369 (x86/efi: Pass necessary EFI data for kexec
via setup_data). So maybe we could use this to check if we run under
kexec or not.
That sounds like a sensible fix; don't try to parse the BGRT if
efi_setup.
- Josh Triplett
On Tue, Jul 28, 2015 at 09:51:57PM +0100, Matt Fleming wrote:
(Pulling in Josh)
Thanks, Matt.
On Wed, 22 Jul, at 05:32:44PM, Sebastian Andrzej Siewior wrote:
I usually see
|Ignoring BGRT: failed to allocate memory for image (wanted 264301314 bytes)
|Ignoring BGRT: failed to allocate
is actually broken and has an
invalid version number. I'd prefer at least pr_warn so that people see
it and report it, but I could live with pr_notice; that should hide it
from systems booting in quiet mode, while still having it in the log
even on non-debug kernels.
- Josh Triplett
arch/x86/platform
an error message in that case
because it's just noise for users. So swap pr_err() for pr_debug().
However, Josh points that out it still makes sense to test the validity
of the upper 7 bits of the 'status' field, since they're marked as
reserved in the spec and must be zero. If firmware violates
that the BGRT image isn't being
displayed, and we shouldn't be printing an error message in that case
because it's just noise for users. So swap pr_err() for pr_debug().
However, Josh points that out it still makes sense to test the validity
of the upper 7 bits of the 'status' field, since
firmware and aid kernel
developers in debugging.
However, it probably does make sense to drop the pr_err() for -status
being zero though, because the firmware is explicitly telling us The
BGRT image is not being displayed.
Josh, Matthew? Can you think of a reason that something like
On Mon, Jun 29, 2015 at 04:17:24PM +0200, Borislav Petkov wrote:
On Mon, Jun 29, 2015 at 07:00:22AM -0700, Josh Triplett wrote:
Definitely not FW_BUG. The field is reserved *now*; it would be
legitimate for a new version of the BGRT spec to define one of those
bits for something else
On Mon, Jun 29, 2015 at 03:49:40PM +0100, Matt Fleming wrote:
On Mon, 29 Jun, at 04:17:24PM, Borislav Petkov wrote:
On Mon, Jun 29, 2015 at 07:00:22AM -0700, Josh Triplett wrote:
Definitely not FW_BUG. The field is reserved *now*; it would be
legitimate for a new version of the BGRT spec
agree with Josh that for the specific case of reserved bits,
FW_BUG is wrong, because if in some future version of the spec those
bits get used, seeing,
[Firmware Bug]: Ignoring BGRT: reserved bits are non-zero 0x3
I still don't see what that message brings if some kernel complains
the frame
pointer with FP_SAVE/RESTORE.
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
Cc: Matt Fleming matt.flem...@intel.com
Cc: linux-efi@vger.kernel.org
---
arch/x86/platform/efi/efi_stub_64.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/platform/efi/efi_stub_64.S
b
without modifying anything in-between
succession run of sparse. I just want to know is this is the known
issue(Bug) of sparse ? If yes, can someone share here ?
Can you provide a sample of the differences?
How did you invoke Sparse? C=1 or C=2?
- Josh Triplett
--
To unsubscribe from this list: send
.
This approach results in no additional GOT entries being generated,
so there is no need for any changes in the early GOT handling.
Cc: Maarten Lankhorst maarten.lankho...@canonical.com
Cc: Josh Boyer jwbo...@fedoraproject.org
Cc: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Ard Biesheuvel
On Mon, Aug 04, 2014 at 01:19:59PM +0100, Matt Fleming wrote:
On Fri, 01 Aug, at 09:11:54AM, Josh Triplett wrote:
The original bug report was about an allocation failure for a fairly
reasonable BGRT size. We can certainly prohibit absurdly huge ones (for
instance, bigger than
On Fri, Aug 01, 2014 at 10:19:49AM +0100, Matt Fleming wrote:
(Including akpm, the __GFP_NOWARN police)
Andrew suggested __GFP_NOWARN here in the first place.
On Thu, 31 Jul, at 09:11:33AM, Josh Triplett wrote:
I started to add an explicit limit, but any reasonable limit (large
enough
On Thu, Jul 31, 2014 at 11:31:10AM +0100, Matt Fleming wrote:
On Wed, 30 Jul, at 12:23:32PM, Josh Triplett wrote:
@@ -61,14 +81,18 @@ void __init efi_bgrt_init(void)
early_iounmap(image, sizeof(bmp_header));
bgrt_image_size = bmp_header.size;
- bgrt_image = kmalloc
of the
patchset Fedora typically carries for this purpose for a bit. Things
appear to be working as expected and the protections remain the same.
It would be really nice to get this set of patches in so some of the
other patches that depend on them can start being pushed as well.
josh
--
To unsubscribe
On Thu, Feb 27, 2014 at 2:07 PM, Greg KH gre...@linuxfoundation.org wrote:
On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote:
On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett
matthew.garr...@nebula.com wrote:
The conclusion we came to at Plumbers was that this patchset was basically
On Mon, Sep 9, 2013 at 11:49 AM, Matthew Garrett
matthew.garr...@nebula.com wrote:
From: Josh Boyer jwbo...@redhat.com
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to execute arbitrary code in the kernel.
Disable this when securelevel
if the
recommendation in the spec changed, the kernel would still have to
accomodate both possibilities.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Sep 16, 2013 at 06:25:22PM +0200, Laszlo Ersek wrote:
On 09/16/13 17:57, Josh Triplett wrote:
The edk2 commit that flipped the memory type underneath the image data
from EfiReservedMemoryType to EfiBootServicesData is:
https://github.com/tianocore/edk2/commit/4c58575e
I
On Mon, Sep 9, 2013 at 4:10 PM, David Lang da...@lang.hm wrote:
On Mon, 9 Sep 2013, Josh Boyer wrote:
On Mon, Sep 9, 2013 at 3:41 PM, H. Peter Anvin h...@zytor.com wrote:
On 09/09/2013 12:01 PM, valdis.kletni...@vt.edu wrote:
On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said:
Given
On Wed, Sep 4, 2013 at 6:51 AM, joeyli j...@suse.com wrote:
於 五，2013-08-30 於 19:41 -0400，Josh Boyer 提到：
On Fri, Aug 30, 2013 at 01:46:30PM -0700, H. Peter Anvin wrote:
On 08/29/2013 11:37 AM, Josh Boyer wrote:
setup_efi_pci(boot_params);
diff --git a/arch/x86/include/uapi/asm
:
Acked-by: Kees Cook keesc...@chromium.org
I spent yesterday rebasing and testing Fedora 20 secure boot support
to this series, and things have tested out fine on both SB and non-SB
enabled machines.
For the series:
Reviewed-by: Josh Boyer jwbo...@fedoraproject.org
Tested-by: Josh Boyer jwbo
believe it should be posted somewhere relatively soon. We're also
planning on talking about it at the Secure Boot microconference at
Linux Plumbers in two weeks.
josh
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More
modules_disabled;
+#endif
+}
Needs an EXPORT_SYMBOL/EXPORT_SYMBOL_GPL here, or the patches to drivers
later in the series will fail to link.
josh
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
responding to the one that was sent 31 minutes ago.
No patches were sent 31 minutes ago. And this is definitely in the
first series thread in my inbox.
josh
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo
.
This is apparently the case with several Apple firmwares that support EFI
1.10, and the current check causes them to no longer boot. Fix based on
a suggestion from Matthew Garrett.
Signed-off-by: Josh Boyer jwbo...@redhat.com
---
arch/x86/boot/compressed/eboot.c | 4 +++-
1 file changed, 3 insertions
On Wed, Apr 24, 2013 at 03:44:30PM +0100, Matt Fleming wrote:
On 24/04/13 15:37, Josh Boyer wrote:
We need to check the runtime sys_table for the EFI version the firmware
specifies instead of just checking for a NULL QueryVariableInfo. Older
implementations of EFI don't have
dev tree. It panics with:
D'oh. OK, at this point I'm inclined to apply Josh Boyer's patch on top
of my urgent branch which will address the WARNING people are hitting on
i386. I updated the commit message a little.
Josh (Boyer), are you guys still carrying this patch and have you seen
any
out the bgrt image - it's not, see the above
commit log - and I assumed that you had an ACPI bgrt pointer in your
memory map, but you don't.
Darren, Josh, have you ever seen an i386 machine with a bgrt pointer? If
not, and given that we've never seen an i386 firmware that requires the
above
of pulling out the bgrt image - it's not, see the above
commit log - and I assumed that you had an ACPI bgrt pointer in your
memory map, but you don't.
Darren, Josh, have you ever seen an i386 machine with a bgrt pointer? If
not, and given that we've never seen an i386 firmware that requires
On Thu, Apr 18, 2013 at 09:38:04AM -0700, H. Peter Anvin wrote:
On 04/18/2013 09:33 AM, Josh Triplett wrote:
On Thu, Apr 18, 2013 at 12:00:26PM +0100, Matt Fleming wrote:
No, no - we *don't* have a BGRT object at all.
We have a completely clean memory map - but the BGRT code is causing
On Wed, Mar 27, 2013 at 11:08 AM, Kyle McMartin kmcma...@redhat.com wrote:
On Wed, Mar 27, 2013 at 11:03:26AM -0400, Josh Boyer wrote:
On Mon, Mar 18, 2013 at 5:32 PM, Matthew Garrett
matthew.garr...@nebula.com wrote:
Any hardware that can potentially generate DMA has to be locked down from
this, but we
can't just replace it with an efi_enabled(EFI_SECURE_BOOT) check because
of the sysfs open case. I'm not sure there are great answers here.
josh
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo
be.
Really though, the main issue is that you cannot introduce new caps to
enforce finer grained access without breaking something.
josh
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
necessarily need to.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
in boot services memory - one can't generally
expect the ACPI parser to become available in an OS before
setting up memory allocation. To Linux this already has turned
out to be a problem, on Xen dealing with this would turn out
even more cumbersome.
What problems has this caused?
- Josh Triplett
of
work has been done to decouple linux-firmware from the kernel tree and
if signed firmware is used it seems to couple them together one way or
another. At the moment, using generated per-build keys to come up with
the firmware signatures seems a bit suboptimal in that regard.
josh
--
To unsubscribe
43 matches
Mail list logo
