From: Jiri Kosina
old_memmap's efi_call_phys_prolog() calls set_pgd() with swapper PGD that
has PAGE_USER set, which makes PTI set NX on it, and therefore EFI can't
execute it's code.
Fix that by forcefully clearing _PAGE_NX from the PGD (this can't be done
by the pgprot
... and even if that happens, locking down only that particular feature of
ftrace would be needed.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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
27;t seem to fit at all.
>
> I'll defer this question to Alexei since he suggested I needed to deal
> with this too.
Thanks.
--
Jiri Kosina
SUSE Labs
--
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
verification that the code
you're running in ring0 can be trusted (IOW is the one that has been
signed and verified by the whole boot chain).
Checking execution patterns doesn't seem to fit at all.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line &q
ght.
> >
> > Swap encryption is not mandatory and I'm not sure how the hibernate
> > code can verify whether or not it is in use.
>
> BTW, SUSE has patches adding secure boot support to the hibernate code
> and Jiri promised me to post them last year even. :-)
Oh, thanks fo
On Sat, 15 Aug 2015, Pavel Machek wrote:
> > For forwarding hibernation key from EFI stub to boot kernel, this patch
> > allocates setup data for carrying hibernation key, size and the status
> > of efi operating.
> >
> > Reviewed-by: Jiri Kosina
>
> Jiri, a
On Thu, 16 Jul 2015, Lee, Chun-Yi wrote:
> This patchset is the implementation of signature verification of hibernate
> snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader
> generate key-pair in UEFI secure boot environment, then forward it to kernel
> for
anage to
> get done in time for merging.
>
> And even if we did, they would've been too risky so instead of rushing
> things and break booting 4.1 on boxes left and right, we will be very
> strict and conservative and will take our time with this to fix and test
> it proper
t;
> Cc: Matt Fleming
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: Jiri Kosina
> Cc: linux-efi@vger.kernel.org
> Cc: Ingo Molnar
> Cc: Baoquan He
> Fixes: f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
Thanks a lot for fixing my ove
-rc3, but this particular one at least
is a regression fix that has to go in.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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 Sat, 28 Feb 2015, Yinghai Lu wrote:
> We should access variable with referrence instead of using physical
> address as value.
>
> Cc: Matt Fleming
> Cc: Borislav Petkov
> Signed-off-by: Yinghai Lu
Acked-by: Jiri Kosina
Thanks for fixing my brainfart. This
n do the
> validation since the validating key has to be secret
This is true, but as you said, the relevance of this seems to be rather
questionable.
--
Jiri Kosina
SUSE Labs
--
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
eating fake hibernation image and issuing reboot)
doesn't have access to the symmetric key
--
Jiri Kosina
SUSE Labs
--
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
> because it's not for generate 0x00 0x01 leading string when used in
> > > > signature
> > > > generation.
> > > >
> > > > Reviewed-by: Jiri Kosina
> > > > Signed-off-by: Lee, Chun-Yi
> > >
> > > > +st
our differs from Windows
How so? Windows don't work on those older Macs as well, do they?
So if we properly detect those (and only those), we mimic Windows
completely, right?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-
d Linux
> kernels on Macs than there are people using kexec,
I'd be careful in order not to underestimate how much kexec is being used.
[At least some] distros are using it during installation process.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "uns
the problem you were trying to avoid.
The problem that needs to be avoided is machines turning into bricks if
EFI storage nvram is getting full.
--
Jiri Kosina
SUSE Labs
--
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 the process of testing this. But the
patches are not ready for mainline yet.
(*) If one would be naive enough, he'd believe that the pressure should be
put on the BIOS writers instead of OS to fix the bug :)
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line &qu
t; > No, that defeats the entire point of the original patch.
>
> How so? It is still calling QueryVariableInfo()
> before the data is used.
You lose information provided by QueryVariableInfo() about boot-only
variables once the transition boot -> runtime has happened.
--
Jiri Kos
runtime:
> >
> > UEFI spec 2.3.1 P.109:
> > Runtime Services
> > Functions that are available before and after any call to
> > ExitBootServices(). These functions are described in Section 7.
>
> That's a great idea. This patch moves the QueryVariabl
).
But it's being called later on coming back to efi_main(). That was just a
poor man's demonstration attempt why this code is running before
ExitBootServices() has been called.
--
Jiri Kosina
SUSE Labs
--
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
(void **)&gdt);
if (status != EFI_SUCCESS) {
efi_printk("Failed to alloc mem for gdt structure\n");
goto fail;
}
[ ... snip ... ]
We are calling QueryVariableInfo() in setup_efi_vars(), and later on
All
mmap(char *arg)
> }
> early_param("add_efi_memmap", setup_add_efi_memmap);
>
> +static bool efi_no_storage_paranoia;
> +EXPORT_SYMBOL_GPL(efi_no_storage_paranoia);
Is there any particular reason to export this symbol?
--
Jiri Kosina
SUSE Labs
--
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
.e.
exploiting the bug in the kernel ... and that's independent of the OS we
are talking about).
Just because it contains "secure" in its name, doesn't really make it a
proper security solution. It should rather be called "vendor lock-in
boot", or something like that.
-
stand) set the
variable for storing the public key in a way that it can't be accessed
from runtime environment. But how can we prevent it being *created* before
the machine is ever touched by Linux?
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "u
On Mon, 5 Nov 2012, Jiri Kosina wrote:
> Do I understand you correctly that by the 'glue' stuff you actually mean
> the division of the kexec image into segments?
>
> Of course, when we are dividing the image into segments and then passing
> those individua
x27;d mean sys_kexec_raw_load(), or whatever ... but I fail to see why that
would be problem in principle.
If you can point me to the code where all the magic that prevents this
easy handling is happening, I'd appreciate it.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this
kexec-tools
> in kernel.
Why is "when kernel has been securely booted, the in-kernel kexec
mechanism has to verify the signature of the supplied image before
kexecing it" not enough? (basically the same thing we are doing for signed
modules already).
--
Jiri Kosina
SUSE Labs
--
To
with Dave, it is not upstream. Well, still it is a concern
> for distro kernel.
Well, that's about /dev/crash, right?
How about /proc/kcore?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vge
don't believe in the secure boot
stuff at all.
But if you take the secure/trusted boot as a basic paradigma, then you
really need the separation.
In such model, the root is untrusted, exactly because the code running
under those privileges hasn't been signed, period. If you allow suc
disallowing "legitimate crossing" of this line.
--
Jiri Kosina
SUSE Labs
--
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
as been tampered
with, etc).
Or perhaps I just misunderstood the point you were trying to make?
Thanks,
--
Jiri Kosina
SUSE Labs
--
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
m shim to
kernel (and kernel discarding the private keys at right moments). It just
needs to be implemented.
--
Jiri Kosina
SUSE Labs
--
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
kernel is signed. The kernel doesn't check the signature on the
> > suspend image.
>
> Which doesn't matter. How are you going to create the tampered image in
> the first place ?
Editing the suspend partition/file directly when trusted kernel is booted.
--
Jiri Kosina
SUSE
vironment.patch
I don't see that patch touching kernel/power/user.c, so using 's2disk' to
suspend machine seems to be still possible even with this patch applied,
right?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-e
ter.
Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
from that artificial image.
It can be viewed as a very obscure way of rewriting the kernel through
/dev/mem (which is obviously not possible when in 'secure boot'
environment).
--
Jiri Kosina
SUSE Labs
--
To
ng arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this could be made "secure" (without
storing private keys to sign the hibernation image on the machine itself
which, well, doesn't sound secure either).
--
Jiri Kosina
SUSE Labs
--
To unsubscr
payloads has been merged.
Apparently your patchset currently doesn't handle device firmware loading,
nor do you seem to mention in in the comments.
I believe signed firmware loading should be put on plate as well, right?
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this li
38 matches
Mail list logo
