.
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 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
fine but that Linus hated the name securelevel more than I hate pickled
herring, so after thinking about this for a few months I've come
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
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
On Wed, Sep 4, 2013 at 4:09 PM, jerry.hoem...@hp.com wrote:
On Tue, Sep 03, 2013 at 07:50:15PM -0400, Matthew Garrett wrote:
kexec permits the loading and execution of arbitrary code in ring 0, which
is something that module signing enforcement is meant to prevent. It makes
sense to disable
On Mon, Aug 19, 2013 at 01:26:02PM -0400, Matthew Garrett wrote:
Provide a single call to allow kernel code to determine whether the system
has been configured to either disable module loading entirely or to load
only modules signed with a trusted key.
Signed-off-by: Matthew Garrett
On Thu, Aug 29, 2013 at 12:05:47PM -0700, H. Peter Anvin wrote:
On 08/29/2013 11:49 AM, Matthew Garrett wrote:
No, you mixed and matched in a single patch...
Right, but I'd fixed that in V2 (which I see I *did* send correctly, and
you're just replying to the old one :))
Well, I'm
.
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
On Thu, Apr 18, 2013 at 12:00:26PM +0100, Matt Fleming wrote:
On 17/04/13 23:00, Bryan O'Donoghue wrote:
In my mind the only memory that is relevant to efi_enter_virtual_mode is
memory that the BIOS has marked as EFI_RUNTIME_SERVICE
md-attribute 0x8000_
I couldn't quite
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
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
userspace in order to avoid it being possible for an attacker to cause
arbitrary kernel behaviour. Default to paranoid - in future we can
On Fri, Feb 8, 2013 at 4:07 PM, Matthew Garrett
matthew.garr...@nebula.com wrote:
On Fri, 2013-02-08 at 13:02 -0800, Kees Cook wrote:
I don't find it unreasonable to drop all caps and lose access to
sensitive things. :) That's sort of the point, really. I think a cap
is the best match. It
On Mon, Nov 5, 2012 at 12:18 PM, Takashi Iwai ti...@suse.de wrote:
Hi,
this is a patch series to add the support for firmware signature
check. At this time, the kernel checks extra signature file (*.sig)
for each firmware, instead of embedded signature.
It's just a quick hack using the
18 matches
Mail list logo
