On 12/15/23 07:04, Mark Rutland wrote:
> On Thu, Dec 14, 2023 at 02:49:29PM -0600, Madhavan T. Venkataraman wrote:
>> Hi Mark,
>
> Hi Madhavan,
>
>> I attended your presentation in the LPC. You mentioned that you could use
>> some help with some pre-requisites f
Hi Mark,
I attended your presentation in the LPC. You mentioned that you could use some
help with some pre-requisites for the Livepatch feature.
I would like to lend a hand.
What would you like me to implement?
I would also like to implement Unwind Hints for the feature. If you want a
Sorry. Forgot to include link to v2. Here it is:
https://lore.kernel.org/linux-arm-kernel/20210402032404.47239-1-madve...@linux.microsoft.com/
Thanks!
Madhavan
On 4/19/21 1:16 PM, Madhavan T. Venkataraman wrote:
> CCing Pavel Tatashin on request.
>
> Pasha,
>
> This is
CCing Pavel Tatashin on request.
Pasha,
This is v2. v1 is here:
https://lore.kernel.org/linux-arm-kernel/20210324184607.120948-1-madve...@linux.microsoft.com/
Thanks!
Madhavan
On 4/1/21 10:24 PM, madve...@linux.microsoft.com wrote:
> From: "Madhavan T. Venk
Thanks!
Madhavan
On 4/16/21 11:17 AM, Mark Brown wrote:
> On Thu, Apr 01, 2021 at 10:24:04PM -0500, madve...@linux.microsoft.com wrote:
>
>> Reliable stacktracing requires that we identify when a stacktrace is
>> terminated early. We can do this by ensuring all tasks have a final
>> frame
On 4/14/21 5:23 AM, Madhavan T. Venkataraman wrote:
> In any case, I have absolutely no problems in implementing your section idea.
> I will
> make an attempt to do that in version 3 of my patch series.
So, I attempted a patch with just declaring all .entry.text functions as
u
Hi Mark Rutland, Mark Brown,
Could you take a look at this version for proper stack termination and let me
know
what you think?
Thanks!
Madhavan
On 4/1/21 10:24 PM, madve...@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman"
>
> Reliable stacktracing requir
On 4/13/21 6:02 AM, Mark Brown wrote:
> On Mon, Apr 12, 2021 at 02:55:35PM -0500, Madhavan T. Venkataraman wrote:
>
>>
>> OK. Just so I am clear on the whole picture, let me state my understanding
>> so far.
>> Correct me if I am wrong.
>
>> 1. We are h
On 4/12/21 12:36 PM, Mark Brown wrote:
> On Fri, Apr 09, 2021 at 04:37:41PM -0500, Josh Poimboeuf wrote:
>> On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote:
>
>>> Further, I believe all the special cases are assembly functions, and
>>> most of those are already in special sections
On 4/9/21 5:53 PM, Josh Poimboeuf wrote:
> On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote:
>> On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote:
>>>> FWIW, over the years we've had zero issues with encoding the frame
>>>>
On 4/9/21 4:37 PM, Josh Poimboeuf wrote:
> On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote:
>> On Mon, Apr 05, 2021 at 03:43:09PM -0500, madve...@linux.microsoft.com wrote:
>>> From: "Madhavan T. Venkataraman"
>>>
>>> There are a n
ess may not be available in
>> that context. Mark the stack trace unreliable accordingly.
>>
>> Signed-off-by: Madhavan T. Venkataraman
>> ---
>> arch/arm64/kernel/entry-ftrace.S | 12 +++
>> arch/arm64/kernel/stacktrace.c | 61
&
ing has to be done whichever way you do it.
> On Mon, Apr 05, 2021 at 03:43:09PM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>>
>> There are a number of places in kernel code where the stack trace is not
>> reliable.
On 4/9/21 6:31 AM, Mark Brown wrote:
> On Thu, Apr 08, 2021 at 02:23:39PM -0500, Madhavan T. Venkataraman wrote:
>> On 4/8/21 11:58 AM, Mark Brown wrote:
>
>>> This looks good to me however I'd really like someone who has a firmer
>>> understanding of what f
On 4/8/21 2:30 PM, Madhavan T. Venkataraman wrote:
>
>
> On 4/8/21 12:17 PM, Mark Brown wrote:
>> On Mon, Apr 05, 2021 at 03:43:10PM -0500, madve...@linux.microsoft.com wrote:
>>
>>> These checks will involve checking the return PC to see if it falls inside
&
On 4/8/21 12:17 PM, Mark Brown wrote:
> On Mon, Apr 05, 2021 at 03:43:10PM -0500, madve...@linux.microsoft.com wrote:
>
>> These checks will involve checking the return PC to see if it falls inside
>> any special functions where the stack trace is considered unreliable.
>> Implement the
On 4/8/21 11:58 AM, Mark Brown wrote:
> On Mon, Apr 05, 2021 at 03:43:12PM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>>
>> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated
>> for a function
On 4/5/21 9:56 AM, Madhavan T. Venkataraman wrote:
>
>
> On 4/5/21 8:24 AM, Masami Hiramatsu wrote:
>> Hi Madhaven,
>>
>> On Sat, 3 Apr 2021 22:29:12 -0500
>> "Madhavan T. Venkataraman" wrote:
>>
>>
>>>>> C
On 4/5/21 8:24 AM, Masami Hiramatsu wrote:
> Hi Madhaven,
>
> On Sat, 3 Apr 2021 22:29:12 -0500
> "Madhavan T. Venkataraman" wrote:
>
>
>>>> Check for kretprobe
>>>> ===
>>>>
>>>> For function
On 4/5/21 8:24 AM, Masami Hiramatsu wrote:
> Hi Madhaven,
>
> On Sat, 3 Apr 2021 22:29:12 -0500
> "Madhavan T. Venkataraman" wrote:
>
>
>>>> Check for kretprobe
>>>> ===
>>>>
>>>> For function
On 4/3/21 11:40 PM, Madhavan T. Venkataraman wrote:
>
>
> On 4/3/21 10:46 PM, Madhavan T. Venkataraman wrote:
>>> I'm somewhat arm-ignorant, so take the following comments with a grain
>>> of salt.
>>>
>>>
>>> I don't think
On 4/3/21 10:46 PM, Madhavan T. Venkataraman wrote:
>> I'm somewhat arm-ignorant, so take the following comments with a grain
>> of salt.
>>
>>
>> I don't think changing these to 'bl' is necessary, unless you wanted
>> __primary_switched() a
On 4/3/21 10:59 AM, Josh Poimboeuf wrote:
> On Thu, Apr 01, 2021 at 10:24:04PM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>> @@ -447,9 +464,9 @@ SYM_FUNC_START_LOCAL(__primary_switched)
>> #endif
>> bl switch_t
On 4/3/21 12:01 PM, Josh Poimboeuf wrote:
> On Tue, Mar 30, 2021 at 02:09:51PM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>>
>> There are a number of places in kernel code where the stack trace is not
>> reliable. En
On 4/1/21 1:53 PM, Madhavan T. Venkataraman wrote:
>
>
> On 4/1/21 1:40 PM, Madhavan T. Venkataraman wrote:
>>>> So, it is only defined if CONFIG_FUNCTION_GRAPH_TRACER is defined. I can
>>>> address
>>>> this as well as your comment
On 4/1/21 1:40 PM, Madhavan T. Venkataraman wrote:
>>> So, it is only defined if CONFIG_FUNCTION_GRAPH_TRACER is defined. I can
>>> address
>>> this as well as your comment by defining another label whose name is more
>>> meaningful
>>> to ou
On 4/1/21 1:28 PM, Mark Brown wrote:
> On Thu, Apr 01, 2021 at 12:43:25PM -0500, Madhavan T. Venkataraman wrote:
>
>>>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
>>>> + { (unsigned long) _graph_call, 0 },
>>>> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>&g
On 4/1/21 9:27 AM, Mark Brown wrote:
> On Tue, Mar 30, 2021 at 02:09:54PM -0500, madve...@linux.microsoft.com wrote:
>
>> + * FTRACE trampolines.
>> + */
>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
>> +{ (unsigned long) _graph_call, 0 },
>> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>> +
On 4/1/21 10:27 AM, Mark Brown wrote:
> On Tue, Mar 30, 2021 at 02:09:52PM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>>
>> Implement a check_reliability() function that will contain checks for the
>> presence of var
On 4/1/21 9:27 AM, Mark Brown wrote:
> On Tue, Mar 30, 2021 at 02:09:54PM -0500, madve...@linux.microsoft.com wrote:
>
>> + * FTRACE trampolines.
>> + */
>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
>> +{ (unsigned long) _graph_call, 0 },
>> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>> +
On 3/29/21 6:27 AM, Mark Rutland wrote:
> Hi Madhavan,
>
> Overall this looks pretty good; I have a few comments below.
>
> On Wed, Mar 24, 2021 at 01:46:07PM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>>
>> The
/21 3:24 PM, Madhavan T. Venkataraman wrote:
>
>
> On 3/23/21 1:30 PM, Mark Rutland wrote:
>> On Tue, Mar 23, 2021 at 12:23:34PM -0500, Madhavan T. Venkataraman wrote:
>>> On 3/23/21 12:02 PM, Mark Rutland wrote:
>>
>> [...]
>>
>>> I think tha
On 3/23/21 1:30 PM, Mark Rutland wrote:
> On Tue, Mar 23, 2021 at 12:23:34PM -0500, Madhavan T. Venkataraman wrote:
>> On 3/23/21 12:02 PM, Mark Rutland wrote:
>
> [...]
>
>> I think that I did a bad job of explaining what I wanted to do. It is not
>> for an
On 3/23/21 1:27 PM, Mark Brown wrote:
> On Tue, Mar 23, 2021 at 12:23:34PM -0500, Madhavan T. Venkataraman wrote:
>> On 3/23/21 12:02 PM, Mark Rutland wrote:
>
>>> 3. Figure out exception boundary handling. I'm currently working to
>>>simplify the entry
On 3/23/21 12:23 PM, Madhavan T. Venkataraman wrote:
>
>
> On 3/23/21 12:02 PM, Mark Rutland wrote:
>> On Tue, Mar 23, 2021 at 11:20:44AM -0500, Madhavan T. Venkataraman wrote:
>>> On 3/23/21 10:26 AM, Madhavan T. Venkataraman wrote:
>>>> On 3/23/21 9:57
On 3/23/21 12:02 PM, Mark Rutland wrote:
> On Tue, Mar 23, 2021 at 11:20:44AM -0500, Madhavan T. Venkataraman wrote:
>> On 3/23/21 10:26 AM, Madhavan T. Venkataraman wrote:
>>> On 3/23/21 9:57 AM, Mark Rutland wrote:
>>>> On Tue, Mar 23, 2021 at 09:15:36AM -0500,
On 3/23/21 11:48 AM, Mark Rutland wrote:
> On Tue, Mar 23, 2021 at 10:26:50AM -0500, Madhavan T. Venkataraman wrote:
>> On 3/23/21 9:57 AM, Mark Rutland wrote:
>> Thanks for explaining the nesting. It is now clear to me.
>
> No problem!
>
>> So, my next question
On 3/23/21 10:26 AM, Madhavan T. Venkataraman wrote:
>
>
> On 3/23/21 9:57 AM, Mark Rutland wrote:
>> On Tue, Mar 23, 2021 at 09:15:36AM -0500, Madhavan T. Venkataraman wrote:
>>> Hi Mark,
>>>
>>> I have a general question. When exceptions are nested
On 3/23/21 9:57 AM, Mark Rutland wrote:
> On Tue, Mar 23, 2021 at 09:15:36AM -0500, Madhavan T. Venkataraman wrote:
>> Hi Mark,
>>
>> I have a general question. When exceptions are nested, how does it work? Let
>> us consider 2 cases:
>>
>> 1. E
On 3/23/21 9:33 AM, Mark Rutland wrote:
> On Tue, Mar 23, 2021 at 08:31:50AM -0500, Madhavan T. Venkataraman wrote:
>> On 3/23/21 8:04 AM, Mark Rutland wrote:
>>> On Tue, Mar 23, 2021 at 07:46:10AM -0500, Madhavan T. Venkataraman wrote:
>>>> On 3/23/21 5:42 AM, Ma
Hi Mark,
I have a general question. When exceptions are nested, how does it work? Let us
consider 2 cases:
1. Exception in a page fault handler itself. In this case, I guess one more
pt_regs will get
established in the task stack for the second exception.
2. Exception in an interrupt
On 3/23/21 8:36 AM, Mark Rutland wrote:
> On Tue, Mar 23, 2021 at 07:56:40AM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>> On 3/23/21 5:51 AM, Mark Rutland wrote:
>>> On Mon, Mar 15, 2021 at 11:57:57AM -0500, madve...@linux.microsoft.com
>>> wrot
On 3/23/21 8:04 AM, Mark Rutland wrote:
> On Tue, Mar 23, 2021 at 07:46:10AM -0500, Madhavan T. Venkataraman wrote:
>> On 3/23/21 5:42 AM, Mark Rutland wrote:
>>> On Mon, Mar 15, 2021 at 11:57:56AM -0500, madve...@linux.microsoft.com
>>> wrote:
>>&
On 3/23/21 5:51 AM, Mark Rutland wrote:
> On Mon, Mar 15, 2021 at 11:57:57AM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>>
>> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated
>> for a function
On 3/23/21 5:42 AM, Mark Rutland wrote:
> On Mon, Mar 15, 2021 at 11:57:56AM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>>
>> EL1 exceptions can happen on any instruction including instructions in
>> the frame pointer
On 3/23/21 5:36 AM, Mark Rutland wrote:
> On Thu, Mar 18, 2021 at 03:29:19PM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>> On 3/18/21 1:26 PM, Mark Brown wrote:
>>> On Mon, Mar 15, 2021 at 11:57:55AM -0500, madve...@linux.microsoft.com
>>> wrote:
On 3/23/21 5:24 AM, Mark Rutland wrote:
> On Fri, Mar 19, 2021 at 05:03:09PM -0500, Madhavan T. Venkataraman wrote:
>> I solved this by using existing functions logically instead of inventing a
>> dummy function. I initialize pt_regs->stackframe[1] to an existing function
&g
On 3/19/21 1:19 PM, Madhavan T. Venkataraman wrote:
>
>
> On 3/19/21 9:29 AM, Madhavan T. Venkataraman wrote:
>>
>>
>> On 3/19/21 7:30 AM, Mark Brown wrote:
>>> On Thu, Mar 18, 2021 at 03:26:13PM -0500, Madhavan T. Venkataraman wrote:
>&g
On 3/19/21 9:29 AM, Madhavan T. Venkataraman wrote:
>
>
> On 3/19/21 7:30 AM, Mark Brown wrote:
>> On Thu, Mar 18, 2021 at 03:26:13PM -0500, Madhavan T. Venkataraman wrote:
>>> On 3/18/21 10:09 AM, Mark Brown wrote:
>>
>>>> If we are going to add the
On 3/19/21 11:20 AM, Mark Brown wrote:
> On Fri, Mar 19, 2021 at 10:02:52AM -0500, Madhavan T. Venkataraman wrote:
>> On 3/19/21 9:40 AM, Madhavan T. Venkataraman wrote:
>
>>> Actually now I look again it's just not adding anything on EL2 entries
>>> at all, the
On 3/19/21 9:40 AM, Madhavan T. Venkataraman wrote:
>> Are you referring to ARMv8.1 VHE extension where the kernel can run
>> at EL2? Could you elaborate? I thought that EL2 was basically for
>> Hypervisors.
> KVM is the main case, yes - IIRC otherwise it's mainly error h
On 3/19/21 8:22 AM, Mark Brown wrote:
> On Thu, Mar 18, 2021 at 05:22:49PM -0500, Madhavan T. Venkataraman wrote:
>> On 3/18/21 12:40 PM, Mark Brown wrote:
>
>>> Unless I'm misreading what's going on here this is more trying to set a
>>> type for the stack as a w
On 3/19/21 7:30 AM, Mark Brown wrote:
> On Thu, Mar 18, 2021 at 03:26:13PM -0500, Madhavan T. Venkataraman wrote:
>> On 3/18/21 10:09 AM, Mark Brown wrote:
>
>>> If we are going to add the extra record there would probably be less
>>> potential for confusion if
On 3/18/21 12:40 PM, Mark Brown wrote:
> On Mon, Mar 15, 2021 at 11:57:54AM -0500, madve...@linux.microsoft.com wrote:
>
>> To summarize, pt_regs->stackframe is used (or will be used) as a marker
>> frame in stack traces. To enable the unwinder to detect these frames, tag
>> each
On 3/18/21 1:26 PM, Mark Brown wrote:
> On Mon, Mar 15, 2021 at 11:57:55AM -0500, madve...@linux.microsoft.com wrote:
>
>> +/* Terminal record, nothing to unwind */
>> +if (fp == (unsigned long) regs->stackframe) {
>> +if (regs->frame_type == TASK_FRAME ||
>> +
On 3/18/21 10:09 AM, Mark Brown wrote:
> On Mon, Mar 15, 2021 at 11:57:53AM -0500, madve...@linux.microsoft.com wrote:
>
>> In summary, task pt_regs->stackframe is where a successful stack trace ends.
>
>> .if \el == 0
>> - mov x29, xzr
>> + stp xzr, xzr, [sp,
On 3/15/21 11:57 AM, madve...@linux.microsoft.com wrote:
> Proper termination of the stack trace
> =
>
> In the unwinder, check the following for properly terminating the stack
> trace:
>
> - Check every frame to see if it is
On 2/25/21 5:58 AM, Mark Rutland wrote:
> On Wed, Feb 24, 2021 at 01:34:09PM -0600, Madhavan T. Venkataraman wrote:
>> On 2/24/21 6:17 AM, Mark Rutland wrote:
>>> On Tue, Feb 23, 2021 at 12:12:43PM -0600, madve...@linux.microsoft.com
>>> wrote:
>>&
1 at 12:12:43PM -0600, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>>
>> Unwinder changes
>>
>>
>> Termination
>> ===
>>
>> Currently, the unwinder terminates
On 2/24/21 6:33 AM, Mark Brown wrote:
> On Tue, Feb 23, 2021 at 01:20:49PM -0600, Madhavan T. Venkataraman wrote:
>> On 2/23/21 1:02 PM, Mark Brown wrote:
>>> On Tue, Feb 23, 2021 at 12:12:43PM -0600, madve...@linux.microsoft.com
>>> wrote:
>
>
On 2/23/21 1:02 PM, Mark Brown wrote:
> On Tue, Feb 23, 2021 at 12:12:43PM -0600, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>>
>> Unwinder changes
>>
>
> This is making several different chang
Hi,
I sent this suggestion to linux-arm-kernel in response to the Reliable
Stacktrace RFC from Mark Brown
and Mark Rutland. I am repeating it here for two reasons:
- It involves objtool.
- There are many more recipients in this thread that may be interested in this
topic.
Please let me know
!
On Mon, Jan 25, 2021 at 11:58:47AM -0600, Madhavan T. Venkataraman wrote:
> Some questions below:
I've answered thos below.
If possible, I'd prefer to handle future queries on a public list (so
that others can chime in, and so that it gets archived), so if you could
direct further questi
On 1/22/21 3:43 PM, Ard Biesheuvel wrote:
> On Fri, 22 Jan 2021 at 22:15, Madhavan T. Venkataraman
> wrote:
>>
>>
>>
>> On 1/22/21 11:43 AM, Mark Brown wrote:
>>> On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote:
>>>
>>&g
On 1/22/21 11:43 AM, Mark Brown wrote:
> On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote:
>
>> 2) The shadow stack idea sounds promising -- how hard would it be to
>>make a prototype reliable unwinder?
>
> In theory it doesn't look too hard and I can't see a particular
On 1/22/21 11:43 AM, Mark Brown wrote:
> On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote:
>
>> 2) The shadow stack idea sounds promising -- how hard would it be to
>>make a prototype reliable unwinder?
>
> In theory it doesn't look too hard and I can't see a particular
> Sorry for the late reply. The last RFC for arm64 support in objtool is a bit
> old because it was preferable to split things into smaller series.
>
> I touched it much lately, so I'm picking it back up and will try to get a git
> branch into shape on a recent mainline (a few things need
On 1/15/21 6:33 AM, Mark Rutland wrote:
>> It looks like the most recent work in this area has been from the
>> following folks:
>>
>> Mark Brown and Mark Rutland:
>> Kernel changes to providing reliable stack traces.
>>
>> Julien Thierry:
>> Providing ARM64 support in objtool.
>>
>>
Before I implement the user land solution recommended by reviewers, I just want
an opinion on where the code should reside.
I am thinking glibc. The other choice would be a separate library, say,
libtramp.
What do you recommend?
Madhavan
On 9/26/20 10:55 AM, Arvind Sankar wrote:
> On Fri, Sep 25, 2020 at 05:44:56PM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>> On 9/24/20 6:43 PM, Arvind Sankar wrote:
>>>
>>> The source PC will generally not be available if the compiler dec
On 9/24/20 6:43 PM, Arvind Sankar wrote:
> On Thu, Sep 24, 2020 at 03:23:52PM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>>> Which ISA does not support PIC objects? You mentioned i386 below, but
>>> i386 does support them, it just needs to copy the P
On 9/24/20 3:52 PM, Florian Weimer wrote:
> * Madhavan T. Venkataraman:
>
>> Otherwise, using an ABI quirk or a calling convention side effect to
>> load the PC into a GPR is, IMO, non-standard or non-compliant or
>> non-approved or whatever you want to call it. I
On 9/23/20 2:51 PM, Arvind Sankar wrote:
> On Wed, Sep 23, 2020 at 02:17:30PM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>> On 9/23/20 4:11 AM, Arvind Sankar wrote:
>>> For libffi, I think the proposed standard trampoline won't actually
>>> work
On 9/23/20 9:39 AM, Florian Weimer wrote:
> * Solar Designer:
>
>> While I share my opinion here, I don't mean that to block Madhavan's
>> work. I'd rather defer to people more knowledgeable in current userland
>> and ABI issues/limitations and plans on dealing with those, especially
>> to
On 9/23/20 2:51 PM, Arvind Sankar wrote:
> On Wed, Sep 23, 2020 at 02:17:30PM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>> On 9/23/20 4:11 AM, Arvind Sankar wrote:
>>> For libffi, I think the proposed standard trampoline won't actually
>>> work
On 9/23/20 3:51 PM, Pavel Machek wrote:
> Hi!
>
Scenario 2
--
We know what code we need in advance. User trampolines are a good example
of
this. It is possible to define such code statically with some help from the
kernel.
This RFC
On 9/23/20 4:14 AM, Solar Designer wrote:
>>> The W^X implementation today is not complete. There exist many user level
>>> tricks that can be used to load and execute dynamic code. E.g.,
>>>
>>> - Load the code into a file and map the file with R-X.
>>>
>>> - Load the code in an RW- page.
On 9/23/20 4:11 AM, Arvind Sankar wrote:
> For libffi, I think the proposed standard trampoline won't actually
> work, because not all ABIs have two scratch registers available to use
> as code_reg and data_reg. Eg i386 fastcall only has one, and register
> has zero scratch registers. I believe
On 9/23/20 3:42 AM, Pavel Machek wrote:
> Hi!
>
>> Solution proposed in this RFC
>> =
>>
>> >From this RFC's perspective, there are two scenarios for dynamic code:
>>
>> Scenario 1
>> --
>>
>> We know what code we need only at runtime. For instance, JIT code
...
>> The W^X implementation today is not complete. There exist many user level
>> tricks that can be used to load and execute dynamic code. E.g.,
>>
>> - Load the code into a file and map the file with R-X.
>>
>> - Load the code in an RW- page. Change the permissions to R--. Then,
>> change
I just resent the trampfd v2 RFC. I forgot to CC the reviewers who provided
comments before.
So sorry.
Madhavan
On 9/22/20 4:53 PM, madve...@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman"
>
> Introduction
>
>
> Dynamic code is
On 9/17/20 10:36 AM, Madhavan T. Venkataraman wrote:
>>> libffi
>>> ==
>>>
>>> I have implemented my solution for libffi and provided the changes for
>>> X86 and ARM, 32-bit and 64-bit. Here is the reference patch:
>>>
>>> http:
On 9/16/20 8:04 PM, Florian Weimer wrote:
> * madvenka:
>
>> Examples of trampolines
>> ===
>>
>> libffi (A Portable Foreign Function Interface Library):
>>
>> libffi allows a user to define functions with an arbitrary list of
>> arguments and return value through a feature
On 8/12/20 5:06 AM, Mark Rutland wrote:
> [..]
>>
>> The general principle of the mitigation is W^X. I would argue that
>> the above options are violations of the W^X principle. If they are
>> allowed today, they must be fixed. And they will be. So, we cannot
>> rely on them.
>
> Hold on.
>
>
I am working on version 2 of trampfd. Will send it out soon.
Thanks for all the comments so far!
Madhavan
On 8/10/20 12:34 PM, Madhavan T. Venkataraman wrote:
> Resending because of mailer problems. Some of the recipients did not receive
> my email. I apologize. Sigh.
>
On 8/11/20 8:08 AM, Pavel Machek wrote:
> Hi!
>
Thanks for the lively discussion. I have tried to answer some of the
comments below.
>>>
> There are options today, e.g.
>
> a) If the restriction is only per-alias, you can have distinct aliases
>where one is
On 8/8/20 5:17 PM, Pavel Machek wrote:
> Hi!
>
>> Thanks for the lively discussion. I have tried to answer some of the
>> comments below.
>
>>> There are options today, e.g.
>>>
>>> a) If the restriction is only per-alias, you can have distinct aliases
>>>where one is writable and another
Resending because of mailer problems. Some of the recipients did not receive
my email. I apologize. Sigh.
Here is a redefinition of trampfd based on review comments.
I wanted to address dynamic code in 3 different ways:
Remove the need for dynamic code where possible
Thanks for the lively discussion. I have tried to answer some of the
comments below.
On 8/4/20 9:30 AM, Mark Rutland wrote:
>
>> So, the context is - if security settings in a system disallow a page to have
>> both write and execute permissions, how do you allow the execution of
>> genuine
Aug 03, 2020 at 12:58:04PM -0500, Madhavan T. Venkataraman wrote:
>> On 7/31/20 1:31 PM, Mark Rutland wrote:
>>> On Fri, Jul 31, 2020 at 12:13:49PM -0500, Madhavan T. Venkataraman wrote:
>>>> On 7/30/20 3:54 PM, Andy Lutomirski wrote:
>>>>> On Thu, Jul
On 8/4/20 9:33 AM, David Laight wrote:
>>> If you look at the libffi reference patch I have included, the architecture
>>> specific changes to use trampfd just involve a single C function call to
>>> a common code function.
> No idea what libffi is, but it must surely be simpler to
> rewrite it
On 8/2/20 3:00 PM, Andy Lutomirski wrote:
> I feel like trampfd is too poorly defined at this point to evaluate.
Point taken. It is because I wanted to start with something small
and specific and expand it in the future. So, I did not really describe the big
picture - the overall vision,
On 7/31/20 1:31 PM, Mark Rutland wrote:
> On Fri, Jul 31, 2020 at 12:13:49PM -0500, Madhavan T. Venkataraman wrote:
>> On 7/30/20 3:54 PM, Andy Lutomirski wrote:
>>> On Thu, Jul 30, 2020 at 7:24 AM Madhavan T. Venkataraman
>>> wrote:
>> De
On 8/3/20 11:57 AM, David Laight wrote:
> From: Madhavan T. Venkataraman
>> Sent: 03 August 2020 17:03
>>
>> On 8/3/20 3:27 AM, David Laight wrote:
>>> From: Mark Rutland
>>>> Sent: 31 July 2020 19:32
>>> ...
>>>>>
Responses inline..
On 7/31/20 1:09 PM, Mark Rutland wrote:
> Hi,
>
> On Tue, Jul 28, 2020 at 08:10:46AM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>> Trampoline code is placed either in a data page or in a stack page. In
&
On 8/3/20 3:27 AM, David Laight wrote:
> From: Mark Rutland
>> Sent: 31 July 2020 19:32
> ...
>>> It requires PC-relative data references. I have not worked on all
>>> architectures.
>>> So, I need to study this. But do all ISAs support PC-relative data
>>> references?
>> Not all do, but
On 8/3/20 3:23 AM, David Laight wrote:
> From: Madhavan T. Venkataraman
>> Sent: 02 August 2020 19:55
>> To: Andy Lutomirski
>> Cc: Kernel Hardening ; Linux API
>> ;
>> linux-arm-kernel ; Linux FS Devel
>> > fsde...@vger.kernel.org>; linux-integr
On 8/3/20 3:08 AM, David Laight wrote:
> From: Pavel Machek
>> Sent: 02 August 2020 12:56
>> Hi!
>>
This is quite clever, but now I???m wondering just how much kernel help
is really needed. In your series, the trampoline is an non-executable
page. I can think of at least two
On 8/2/20 3:00 PM, Andy Lutomirski wrote:
> On Sun, Aug 2, 2020 at 11:54 AM Madhavan T. Venkataraman
> wrote:
>> More responses inline..
>>
>> On 7/28/20 12:31 PM, Andy Lutomirski wrote:
>>>> On Jul 28, 2020, at 6:11 AM, madve...@linux.microsoft.com
More responses inline..
On 7/28/20 12:31 PM, Andy Lutomirski wrote:
>> On Jul 28, 2020, at 6:11 AM, madve...@linux.microsoft.com wrote:
>>
>> From: "Madhavan T. Venkataraman"
>>
>
> 2. Use existing kernel functionality. Raise a signal, modify
1 - 100 of 111 matches
Mail list logo
