linux-kernel - Re: Unifying x86_64 / Xen init paths and reading hardware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrXX0R-H0pTrc4eMPFb2U+N9QhEmJUmQH9-wv0k2HSStXA@mail.gmail.com>
Date:	Fri, 15 Jan 2016 15:47:25 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Juergen Gross <jgross@...e.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	Borislav Petkov <bp@...e.de>
Subject: Re: Unifying x86_64 / Xen init paths and reading hardware_subarch early

On Fri, Jan 15, 2016 at 2:08 PM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
> I will be respinning the generic Linux linker table solution [0] soon
> based on hpa's feedback again now that I'm back from vacation. As I do
> that though I wanted to highlight a feature I'm throwing into the
> linker table solution which I am not sure many have paid close
> attention to but I think is important to Xen. I'm making use of the
> zero page hardware_subarch to enable us to detect if we're a specific
> hypervisor solution *as early as is possible*. This has a few
> implications, short term it is designed to provides a proactive
> technical solution to bugs such as the cr4 shadow crash (see
> 5054daa285beaf706f051fbd395dc36c9f0f907f) and ensure that *new* x86
> features get a proper Xen implementation proactively *or* at the very
> least get annotated as unsupported properly, instead of having them
> crash and later finding out. A valid example here is Kasan, which to
> this day lacks proper Xen support. In the future, if the generic
> linker table solution gets merged, it would mean developers would have
> to *think* about if they support Xen or not at development time. It
> does this in a not-disruptive way to Xen / x86_64 but most
> *importantly* it does not extend pvops! This should avoid issues in
> cases of developer / maintainer bandwidth, should some new features be
> pushed onto Linux for x86_64 but a respective Xen solution is not
> addressed, and that was not caught early in patch review, such as with
> Kasan.
>
> [0] https://lkml.kernel.org/r/1450217797-19295-1-git-send-email-mcgrof@do-not-panic.com
>
> Two things I'd like to request a bit of help with and review / consideration:
>
> 1) I'd like some advice on a curious problem I've stumbled on. I'd
> like to access hardware_subarch super early, and in my review with at
> least two x86 folks this *should* work:
>
> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> index c913b7eb5056..9168842821c8 100644
> --- a/arch/x86/kernel/head64.c
> +++ b/arch/x86/kernel/head64.c
> @@ -141,6 +141,7 @@ static void __init copy_bootdata(char *real_mode_data)
>
>  asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
>  {
> + struct boot_params *params = (struct boot_params *)__va(real_mode_data);
>   int i;

This is a mess :-p

If you want to access real_mode_data before load_idt, you'll need to do:

    for (i = 0; i < sizeof(boot_params); i += 4096)
        early_make_pgtable((unsigned long)params + i);

Of course, it's entirely possible that that will blow up if you try to
do it on Xen.

I think this would all be easier to understand if you try to separate
out the ideas of linker tables from the idea of rearranging early
init.  AFAICT the linker table thing is just an implementation detail.

If I understand right, you're trying to unify the Xen and native
startup as much as possible.  Why not add little shims, though?
Create a new start_kernel_common(int subarch, ...) where subarch
indicates native vs Xen and have its callers tell it which mode it's
in?

--Andy