On 04/04/2017 12:09 PM, Ard Biesheuvel wrote:
> The EFI stub currently prints a number of diagnostic messages that do
> not carry a lot of information. Since these prints are not controlled
> by 'loglevel' or other command line parameters, and since they appear on
> the EFI framebuffer as well (if
Alexei Starovoitov wrote:
> Also is there a description of what this lockdown trying to accomplish?
Austin S. Hemmelgarn wrote:
> ... but for any kind of proper security analysis, you need to better clarify
> your threat model. 'Prevent modification to the running kernel image' is a
> decent
On 10 April 2017 at 18:13, Ard Biesheuvel wrote:
> On 10 April 2017 at 17:53, Lorenzo Pieralisi
> wrote:
>> On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
>>> On 2 April 2017 at 16:16, Ard Biesheuvel wrote:
>>> > On 30 March 2017 at 14:50, Sinan Kaya wrote:
>>> >> On 3/30/2017
On 10 April 2017 at 17:53, Lorenzo Pieralisi wrote:
> On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
>> On 2 April 2017 at 16:16, Ard Biesheuvel wrote:
>> > On 30 March 2017 at 14:50, Sinan Kaya wrote:
>> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>> >>> On 30 March 2017 at
On 4/10/2017 12:53 PM, Lorenzo Pieralisi wrote:
> Do we want to enforce it on ARM ? I do not know to be honest (and it
> still would not solve the DT firmware case).
>
Yes for ACPI on ARM. Probably no for DT.
> Whatever we do, it is not going to be clean cut IMO. I think that
> what x86 does is
On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
> On 2 April 2017 at 16:16, Ard Biesheuvel wrote:
> > On 30 March 2017 at 14:50, Sinan Kaya wrote:
> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
> >>> On 30 March 2017 at 11:09, Ard Biesheuvel
> >>> wrote:
> On 30 March 201
On 2017-04-05 11:23, Ard Biesheuvel wrote:
> This is a followup to Jan's series [0] to add support for the non-standard
> and awkward capsule header layout that is used by the Quark platform.
>
> While we would prefer to adhere to the standard rigorously, the reality
> (and common practice) in Lin
On 2 April 2017 at 16:16, Ard Biesheuvel wrote:
> On 30 March 2017 at 14:50, Sinan Kaya wrote:
>> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>>> On 30 March 2017 at 11:09, Ard Biesheuvel wrote:
On 30 March 2017 at 11:05, Lorenzo Pieralisi
wrote:
> On Thu, Mar 30, 2017 at 09:46:3
On Mon, Apr 10, 2017 at 11:30:38AM +0100, Ard Biesheuvel wrote:
> As reported by James, Catalin and Mark, commit e69176d68d26
> ("ef/libstub/arm/arm64: Randomize the base of the UEFI rt services
> region") results in a crash in the firmware regardless of whether KASLR
> is in effect or not, and whe
Mimi Zohar wrote:
> From an IMA perspective, either a file hash or signature are valid,
> but for this usage it must be a signature.
Not necessarily. If IMA can guarantee that a module is the same based on its
hash rather than on a key, I would've thought that should be fine.
David
--
To unsub
Andy Shevchenko wrote:
> >> It looks a bit fragile when responsility of whatever reasons kernel
> >> can't serve become a driver burden.
> >> Can we fix this in debugfs framework instead?
> >
> > Fix it with debugfs how? We can't offload the decision to userspace.
>
> I mean to do at least simi
the future.
>>
>> Cc: James Morse
>> Cc: Mark Rutland
>> Cc: Catalin Marinas
>> Cc: Matt Fleming
>> Cc: Ingo Molnar
>> Signed-off-by: Ard Biesheuvel
>
> With this patch applied atop of next-20170410, a defconfig arm64 kernel
> built with
TASK_SIZE on ARM, both of which
> are compile time constants. Also, change the 'headroom' variable to
> static const to force an error if this changes in the future.
>
> Cc: James Morse
> Cc: Mark Rutland
> Cc: Catalin Marinas
> Cc: Matt Fleming
> Cc: Ingo Molna
As reported by James, Catalin and Mark, commit e69176d68d26
("ef/libstub/arm/arm64: Randomize the base of the UEFI rt services
region") results in a crash in the firmware regardless of whether KASLR
is in effect or not, and whether the firmware implements EFI_RNG_PROTOCOL
or not.
Mark has identifi
t;
>> > At which point the machine start booting to a prompt again, (its noisier
>> > than
>> > usual but looks like double-printing).
>
>> That is quite interesting, to be honest, because that patch should
>> effectively be a NOP on systems that do not i
ooks like double-printing).
> That is quite interesting, to be honest, because that patch should
> effectively be a NOP on systems that do not implement
> EFI_RNG_PROTOCOL.
FWIW, I'm also seeing a crash as a result of this patch, on a Juno R1
with an EFI_RNG_PROTOCOL implementat
16 matches
Mail list logo
