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] [day] [month] [year] [list]
Message-ID: <62e6dfc9-8d8d-d1df-1847-d6b8ad681eab@ghiti.fr>
Date:   Thu, 1 Jul 2021 21:31:13 +0200
From:   Alex Ghiti <alex@...ti.fr>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     Paul Walmsley <paul.walmsley@...ive.com>, aou@...s.berkeley.edu,
        jszhang@...nel.org, Christoph Hellwig <hch@...radead.org>,
        zong.li@...ive.com, anup@...infault.org,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 0/2] Map the kernel with correct permissions the first
 time

Le 1/07/2021 à 07:37, Palmer Dabbelt a écrit :
> On Thu, 24 Jun 2021 05:00:39 PDT (-0700), alex@...ti.fr wrote:
>> The kernel permissions are fixed after the kernel page table is created:
>> avoid that by mapping the kernel 'correctly' the first time.
>>
>> Patch 1 introduces a new helper to set kernel mapping permissions while
>> avoiding all the casts when using set_memory_* API.
>>
>> Patch 2  is the bulk of this work and deals with mapping the kernel with
>> the right permissions.
>>
>> Changes in v8:
>> * Move set_kernel_memory inline function into set_memory.h header as 
>> suggested
>>   by Jisheng
>> * Make set_kernel_memory arguments name consistent
>>
>> Changes in v7:
>> * Split long lines and reintroduce parameters names of set_kernel_memory
>>   callback, as suggested by Christoph
>> * Make set_kernel_memory __always_inline as suggested by Christoph
>> * Change 64b spelling into 64-bit, as suggested by Christoph
>>
>> Changes in v6:
>> * load_sz was placed in init section but is now used in kernel address
>>   conversions macros, so remove this attribute.
>>
>> Changes in v5:
>> * Remove non-relevant commits to this patchset that raised issues
>> * Make load_sz non-static as it is used in kernel address conversions
>>   macros
>> * Rebased on top for-next
>>
>> Changes in v4:
>> * Add patch 1 as noted by Jisheng
>> * Changes patch 2 title as suggested by Anup
>> * Add Reviewed-by from Anup
>>
>> Changes in v3:
>> * Add a patch that factorizes kernel address conversions
>> * Add a helper called set_kernel_memory in its own patch, as suggested by
>>   Christoph
>> * Prefer IS_ENABLED over #ifdef, as suggested by Christoph
>> * Split overly long lines, as suggested by Christoph
>> * Simplify kernel mapping by mapping ALL text as readonly and taking 
>> advantage
>>   of already present code that enables write for init text before
>>   free_initmem_default.
>>
>> Changes in v2:
>> * Rebased on top of for-next (and "riscv: mm: fix build errors caused by
>>   mk_pmd()")
>> * Get rid of protect_kernel_linear_mapping_text_rodata as suggested by
>>   Jisheng
>> * Improve code in general compared to previous RFC
>>
>> Alexandre Ghiti (2):
>>   riscv: Introduce set_kernel_memory helper
>>   riscv: Map the kernel with correct permissions the first time
>>
>>  arch/riscv/include/asm/page.h       |  13 +++-
>>  arch/riscv/include/asm/sections.h   |  17 +++++
>>  arch/riscv/include/asm/set_memory.h |  24 ++++--
>>  arch/riscv/kernel/setup.c           |  12 +--
>>  arch/riscv/mm/init.c                | 112 ++++++++++++----------------
>>  5 files changed, 97 insertions(+), 81 deletions(-)
> 
> I had what looks to be two earlier versions of these patches on 
> for-next.  I've fixed that up, but there were some merge conflicts. Let 
> me know if there were any issues, but it's really getting too late in 
> the cycle to be rebasing so I'd prefer just a fixup.
> 

The first 2 patches:

riscv: Remove CONFIG_PHYS_RAM_BASE_FIXED
riscv: Simplify xip and !xip kernel address conversion macros

should *not* be merged as they assume the DRAM physical base address is 
0x8000_0000 for *all* rv64 chips. I have another patchset coming to 
replace those 2 patches.

Alex

> Thanks!
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ