Andy Shevchenko writes:
> +
> +#define INTEL_CPU_FAM_ANY_NODATA(_family, _model)\
> + INTEL_CPU_FAM_ANY(_family, _model, NULL)
> +
> +#define INTEL_CPU_FAM6_NODATA(_model)\
> + INTEL_CPU_FAM_ANY_NODATA(6, INTEL_FAM6_##_model)
_NODATA is actually
On Mon, Aug 20, 2018 at 02:57:39PM -0700, Linus Torvalds wrote:
> On Mon, Aug 20, 2018 at 1:37 PM Andi Kleen wrote:
> >
> > From: Andi Kleen
> >
> > Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then
> > use the p[g4um]d_pfn() macros in the
From: Andi Kleen
Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then
use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of
duplicating the code.
Signed-off-by: Tom Lendacky
Reviewed-by: Thomas Gleixner
Reviewed-by: Borislav Petkov
Cc: Alexander Potapenko
> But it should be fairly easy to just add a 'struct ratelimit_state' to
> 'struct user_struct', and then you can easily just use
>
>'&file->f_cred->user->ratelimit'
>
> and you're done. Make sure the initial root user has it unlimited, and
> limit it to something reasonable for all other use
> Would rate limiting (but not only for non-root) help mitigate Spectre
> v1 issues in UEFI runtime services code as well? I have been looking
> into unmapping the entire kernel while such calls are in progress,
> because firmware is likely to remain vulnerable long after the OSes
> have been fixed
> > I'm a little uneasy having this run by default if enabled, even if it's
> > disabled by default in the config.
>
> What would be the canonical way to enable this feature then? Have a file
White list systems and a option to force enable.
-Andi
--
To unsubscribe from this list: send the line
> But, as Eric said, it should be OK if it is implemented in the kdump kenel.
kdump doesn't work for a lot of use cases (too much memory consumption)
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo
> + It should be noted that enabling this opton will pass a capsule
> + to the firmware on every boot. Some firmware will not allow a
> + user to enter the BIOS setup when a capsule has been registered
> + on the previous boot.
That sounds like a problem. Can this be fixed
