Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 28 Aug 2019 15:33:46 -0700 (PDT)
From:   Paul Walmsley <paul.walmsley@sifive.com>
To:     Anup Patel <anup@brainfault.org>
cc:     Anup Patel <Anup.Patel@wdc.com>,
        Palmer Dabbelt <palmer@sifive.com>,
        Atish Patra <Atish.Patra@wdc.com>,
        Alistair Francis <Alistair.Francis@wdc.com>,
        Christoph Hellwig <hch@infradead.org>,
        "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] RISC-V: Fix FIXMAP area corruption on RV32 systems
In-Reply-To: <CAAhSdy0XALGpc-bCuO7njiBT3p-YvLqhMnRTRu4Hd4gMKeQMTw@mail.gmail.com>
Message-ID: <alpine.DEB.2.21.9999.1908281526410.13811@viisi.sifive.com>
References: <20190819051345.81097-1-anup.patel@wdc.com> <alpine.DEB.2.21.9999.1908261704500.10109@viisi.sifive.com> <CAAhSdy0XALGpc-bCuO7njiBT3p-YvLqhMnRTRu4Hd4gMKeQMTw@mail.gmail.com>
User-Agent: Alpine 2.21.9999 (DEB 301 2018-08-15)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 27 Aug 2019, Anup Patel wrote:

> On Tue, Aug 27, 2019 at 5:43 AM Paul Walmsley <paul.walmsley@sifive.com> wrote:
> >
> > On Mon, 19 Aug 2019, Anup Patel wrote:
> >
> > > Currently, various virtual memory areas of Linux RISC-V are organized
> > > in increasing order of their virtual addresses is as follows:
> > > 1. User space area (This is lowest area and starts at 0x0)
> > > 2. FIXMAP area
> > > 3. VMALLOC area
> > > 4. Kernel area (This is highest area and starts at PAGE_OFFSET)
> > >
> > > The maximum size of user space aread is represented by TASK_SIZE.
> > >
> > > On RV32 systems, TASK_SIZE is defined as VMALLOC_START which causes the
> > > user space area to overlap the FIXMAP area. This allows user space apps
> > > to potentially corrupt the FIXMAP area and kernel OF APIs will crash
> > > whenever they access corrupted FDT in the FIXMAP area.
> > >
> > > On RV64 systems, TASK_SIZE is set to fixed 256GB and no other areas
> > > happen to overlap so we don't see any FIXMAP area corruptions.
> > >
> > > This patch fixes FIXMAP area corruption on RV32 systems by setting
> > > TASK_SIZE to FIXADDR_START.
> >
> > This part -- the TASK_SIZE change -- makes sense to me.
> >
> > However, the patch also changes FIXADDR_SIZE to be defined in terms of
> > page table-related constants.  Previously, FIXADDR_SIZE was based on
> > __end_of_fixed_addresses, as it is for most other architectures. The part
> > of the patch that changes FIXADDR_SIZE seems unrelated to the actual fix.
> >
> > If that's indeed the case -- that the change to FIXADDR_SIZE is unrelated
> > from the fix -- could you please split that into a separate patch, with a
> > description of the rationale?  I think I understand why you're proposing
> > it, but it seems odd to explicitly connect it to page table-related
> > constants, rather than the contents of "enum fixed_addresses", and I'm
> > reluctant to merge that part of this patch without a bit more discussion.
> 
> The FIXADDR_SIZE change is related to the TASK_SIZE requirement and
> it is not a separate change because:
> 
> 1. TASK_SIZE must be evenly divisible by PGDIR_SIZE. The FIXADDR_START
> is defined as (FIXADDR_TOP - FIXADDR_SIZE). The original FIXADDR_SIZE
> defined in-terms of __end_of_fixed_addresses is not a multiple of PGDIR_SIZE
> hence it makes sense to make FIXADDR_SIZE as PGDIR_SIZE.
> 
> 2. Let say we ignore point1 above then still we cannot continue to express
> FIXADDR_SIZE in-terms of __end_of_fixed_addresses because of cyclic
> header dependency where asm/fixmap.h includes asm/pgtable.h and
> __end_of_fixed_addresses is defined in asm/fixmap.h. We certainly need
> to move FIXADDR_TOP, FIXADDR_START, and FIXADDR_SIZE to
> asm/pgtable.h so that we can express TASK_SIZE as FIXADDR_START
> for RV32. If we don't simplify FIXADDR_SIZE then it will result in compile
> errors.


It would be better if we could stick to the same approach used by other 
Linux architectures.  That keeps things consistent across architectures.  
However, in the short term, as you note, the header file changes to get to 
that point are likely to be too intense for the late -rc series that we're 
in.

So, queued for v5.3-rc7.  Thanks very much for the speedy fix,


- Paul