linux-kernel - Re: [PATCH v1 4/6] x86/boot: Assume MMIO if serial base address supplied via earlyprintk

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]

Date:   Thu, 03 May 2018 13:45:58 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 4/6] x86/boot: Assume MMIO if serial base address
 supplied via earlyprintk

On Tue, 2018-01-16 at 16:55 +0100, Ingo Molnar wrote:
> * Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
> 
> > On Tue, 2018-01-16 at 04:13 +0100, Ingo Molnar wrote:
> > > * Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
> > > 
> > > > If user supplied serial base address via kernel command line and
> > > > value
> > > > is higher than IO space limit (64k boundary), assume for now
> > > > that
> > > > MMIO
> > > > byte access is required.
> > > > 
> > > > Later we might expand or modify this if needed.
> > > 
> > > Is this a standard pattern for serial code configuration values?
> > 
> > I didn't get what you meant under "standard" here.
> > 
> > IO space limit comes from generic io.h header and AFAIU is a
> > hardware
> > limitation (outN (%dx), ...; inX (%dx); dx is 16 bit register).
> > 
> > Using mmio8 out of the IO space is dictated by the (modern) x86
> > platforms with non-standard (okay, high speed) UART location in
> > address
> > space.
> 
> So I was wondering whether we should just make mmio configuration an
> explicit 
> parameter instead of a 'range hack'.

I _think_ it can be done later without breaking any existed
configurations.

> Since we are introducing something entirely new the choice is ours.
> 
> Doing it that way would technically be cleaner, as, at least
> theoretically,
> there could be platforms with mmio addresses below 64k physical,
> right?

Correct, though we are talking about x86 world where I have no example
like this. Either we have LPC ports (I/O 0x3f8 and alike) or HS UARTS on
higher MMIO addresses. Note, that PCI code guarantees that range bump as
well when resources would be allocated for unassigned, by firmware, PCI
UART controllers.

> It's also more self-documenting if the new configuration/parameter
> says 'mmio' 
> explicitly.

I would look at it, though it might make things much more complicated to
implement. And yes, it wouldn't reduce fragility of the parser anyway.

Perhaps we can unify earlycon parser with earlyprintk one (not sure if
it's possible since this nice trick with sharing same code between
compressed and boot code).

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy