ag or something like that which means
"block/return EAGAIN until the kernel pool is initialized"? Thanks.
(See the previous discussion about pool initialization.)
--
Florian Weimer / Red Hat Product Security
--
To unsubscribe from this list: send the line "unsubscribe linux-cryp
* James Yonan:
> noinline unsigned long __crypto_mem_not_equal(const void *a, const
> void *b, size_t size);
>
> static inline int crypto_mem_not_equal(const void *a, const void *b,
> size_t size) {
> return __crypto_mem_not_equal(a, b, size) != 0UL ? 1 : 0;
> }
>
> This hides the fact that
* James Yonan:
> + * Constant-time equality testing of memory regions.
> + * Returns 0 when data is equal, non-zero otherwise.
> + * Fast path if size == 16.
> + */
> +noinline unsigned long crypto_mem_not_equal(const void *a, const void *b,
> size_t size)
I think this should really return unsig
* Matthew Garrett:
> On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
>
>> But if you don't generate fresh keys on every boot, the persistent
>> keys are mor exposed to other UEFI applications. Correct me if I'm
>> wrong, but I don't thin
* joeyli:
> Yes, Matthew raised this concern at before. I modified patch to load
> private key in efi stub kernel, before ExitBootServices(), that means we
> don't need generate key-pair at every system boot. So, the above
> procedure of efi bootloader will only run one time.
But if you don't ge
* Chun-Yi Lee:
> + EFI bootloader must generate RSA key-pair when system boot:
>- Bootloader store the public key to EFI boottime variable by itself
>- Bootloader put The private key to S4SignKey EFI variable for forward to
> kernel.
Is the UEFI NVRAM really suited for such regular
