[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <557ABFF8.5040304@redhat.com>
Date: Fri, 12 Jun 2015 12:18:16 +0100
From: Pedro Alves <palves@...hat.com>
To: Josh Poimboeuf <jpoimboe@...hat.com>,
Ingo Molnar <mingo@...nel.org>
CC: Andy Lutomirski <luto@...capital.net>,
Michal Marek <mmarek@...e.cz>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andi Kleen <andi@...stfloor.org>,
live-patching@...r.kernel.org, X86 ML <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v5 02/10] x86: Compile-time asm code validation
On 06/11/2015 03:10 PM, Josh Poimboeuf wrote:
> C would definitely make more sense when analyzing object code. In fact,
> asmvalidate is written in C. But then I guess we'd have to re-implement
> the .cfi stuff and populate the DWARF sections manually instead of
> letting the assembler do it.
Was doing all this directly in the assembler considered? That is,
e.g., add some knob that makes it error/warn in the same conditions
you're making the validator catch. For tail calls, you'd e.g., add
some new ".nonlocal" directive that you'd use to whitelist the
following jump. And then if it's possible run a CFI generator
as a separate step over the source, it sounds like it should also
be possible to have the assembler do it instead too (again with
some new high level directive to trigger/help it).
Thanks,
Pedro Alves
--
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