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:	Wed, 2 Sep 2015 11:48:41 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	"Suzuki K. Poulose" <Suzuki.Poulose@....com>,
	Steve Capper <steve.capper@...aro.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 12/14] arm64: Check for selected granule support

On 13 August 2015 at 19:29, Catalin Marinas <catalin.marinas@....com> wrote:
> On Thu, Aug 13, 2015 at 03:45:07PM +0100, Suzuki K. Poulose wrote:
>> On 13/08/15 13:28, Steve Capper wrote:
>> >On 13 August 2015 at 12:34, Suzuki K. Poulose <suzuki.poulose@....com> wrote:
>> >>  __enable_mmu:
>> >>+       mrs     x1, ID_AA64MMFR0_EL1
>> >>+       ubfx    x2, x1, #ID_AA64MMFR0_TGran_SHIFT, 4
>> >>+       cmp     x2, #ID_AA64MMFR0_TGran_ENABLED
>> >>+       b.ne    __no_granule_support
>> >>         ldr     x5, =vectors
>> >>         msr     vbar_el1, x5
>> >>         msr     ttbr0_el1, x25                  // load TTBR0
>> >>@@ -626,3 +643,8 @@ __enable_mmu:
>> >>         isb
>> >>         br      x27
>> >>  ENDPROC(__enable_mmu)
>> >>+
>> >>+__no_granule_support:
>> >>+       wfe
>> >>+       b __no_granule_support
>> >>+ENDPROC(__no_granule_support)
>> >>--
>> >>1.7.9.5
>> >>
>> >
>> >Is is possible to tell the user that the kernel has failed to boot due
>> >to the kernel granule being unsupported?
>>
>> We don't have anything up at this time. The "looping address" is actually a clue
>> to the (expert) user. Not sure we can do something, until we get something like DEBUG_LL(?)
>
> No.
>
>> Or we should let it continue and end in a panic(?). The current situation can boot a
>> multi-cluster system with boot cluster having the Tgran support(which doesn't make a
>> strong use case though). I will try out some options and get back to you.
>
> If the boot CPU does not support 16KB pages, in general there isn't much
> we can do since the console printing is done after we enabled the MMU.
> Even mapping the UART address requires fixmap support and the PAGE_SIZE
> is hard-coded in the kernel image. The DT is also mapped at run-time.
>
> While in theory it's possible to fall back to a 4KB page size just
> enough to load the DT and figure out the early console, I suggest we
> just live with the "looping address" clue.
>

Couldn't we allocate some flag bits in the Image header to communicate
the page size to the bootloader?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ