On Sun, Mar 10, 2019 at 02:10:46PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 08, 2019 at 03:02:09PM -0600, Josh Poimboeuf wrote:
>
> > These gotos make my head spin. Again I would much prefer a small amount
> > of code duplication over this.
>
> something like so then?
Yeah, that looks a lot
On Fri, Mar 08, 2019 at 03:02:09PM -0600, Josh Poimboeuf wrote:
> These gotos make my head spin. Again I would much prefer a small amount
> of code duplication over this.
something like so then?
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1888,6 +1888,23 @@ static inline const
On Fri, Mar 08, 2019 at 10:31:56PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 08, 2019 at 03:02:09PM -0600, Josh Poimboeuf wrote:
> > > +static const char *uaccess_safe_builtin[] = {
> > > + /* KASAN */
> >
> > A short comment would be good here, something describing why a function
> > might be
On Fri, Mar 08, 2019 at 03:02:09PM -0600, Josh Poimboeuf wrote:
> > +static const char *uaccess_safe_builtin[] = {
> > + /* KASAN */
>
> A short comment would be good here, something describing why a function
> might be added to the list.
There is; but I'm thinking it might be too short?
> >
On Thu, Mar 07, 2019 at 12:45:29PM +0100, Peter Zijlstra wrote:
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -369,7 +369,19 @@ int arch_decode_instruction(struct elf *
>
> case 0x0f:
>
> - if (op2 >= 0x80 && op2 <= 0x8f) {
> +
On Fri, Mar 08, 2019 at 09:07:03AM -0600, Josh Poimboeuf wrote:
> On Thu, Mar 07, 2019 at 09:40:21PM +0100, Peter Zijlstra wrote:
> > On Thu, Mar 07, 2019 at 09:23:19PM +0100, Peter Zijlstra wrote:
> > > On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote:
> > > > Another thing I need
On Fri, Mar 08, 2019 at 09:01:11AM -0600, Josh Poimboeuf wrote:
> On Thu, Mar 07, 2019 at 08:03:13PM +0100, Peter Zijlstra wrote:
> > Ah.. how about I feed objtool a text file with all these symbol names;
> > and I have Makefile compose file that from fragments.
> >
> > Then only KASAN builds
On Thu, Mar 07, 2019 at 09:40:21PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 09:23:19PM +0100, Peter Zijlstra wrote:
> > On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote:
> > > Another thing I need to look at is why objtool only found memset_orig
> > > (from __memset)
On Thu, Mar 07, 2019 at 08:03:13PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote:
> > On Thu, Mar 07, 2019 at 09:54:14AM -0800, Linus Torvalds wrote:
> > > On Thu, Mar 7, 2019 at 9:41 AM Peter Zijlstra
> > > wrote:
> > > > >
> > > > > What's the
On Thu, Mar 07, 2019 at 09:33:18PM +0100, Peter Zijlstra wrote:
> Ooh shiny. Clearly my tree still has them; what commit do I need to look
> for?
30be39d1e1dc ("kasan: remove use after scope bugs detection.")
On Thu, Mar 07, 2019 at 09:23:19PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote:
> > Another thing I need to look at is why objtool only found memset_orig
> > (from __memset) but not memset_erms, which if I read the code right, is
> > a possible
On 3/7/19 11:33 PM, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 11:15:42PM +0300, Andrey Ryabinin wrote:
>>
>>
>> On 3/7/19 8:41 PM, Peter Zijlstra wrote:
>>> On Thu, Mar 07, 2019 at 08:33:26AM -0800, Linus Torvalds wrote:
On Thu, Mar 7, 2019 at 3:52 AM Peter Zijlstra wrote:
>
On Thu, Mar 07, 2019 at 11:15:42PM +0300, Andrey Ryabinin wrote:
>
>
> On 3/7/19 8:41 PM, Peter Zijlstra wrote:
> > On Thu, Mar 07, 2019 at 08:33:26AM -0800, Linus Torvalds wrote:
> >> On Thu, Mar 7, 2019 at 3:52 AM Peter Zijlstra wrote:
> >>>
> >>> XXX: are we sure we want __memset marked
On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote:
> Another thing I need to look at is why objtool only found memset_orig
> (from __memset) but not memset_erms, which if I read the code right, is
> a possible alternative there.
Turns out we only look for sibling calls in the
On 3/7/19 8:41 PM, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 08:33:26AM -0800, Linus Torvalds wrote:
>> On Thu, Mar 7, 2019 at 3:52 AM Peter Zijlstra wrote:
>>>
>>> XXX: are we sure we want __memset marked AC-safe?
>>
>> It's certainly one of the safer functions to call with AC set, but
On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 09:54:14AM -0800, Linus Torvalds wrote:
> > On Thu, Mar 7, 2019 at 9:41 AM Peter Zijlstra wrote:
> > > >
> > > > What's the call site that made you go "just add __memset() to the list"?
> > >
> > >
On March 7, 2019 10:48:13 AM PST, Peter Zijlstra wrote:
>On Thu, Mar 07, 2019 at 09:54:14AM -0800, Linus Torvalds wrote:
>> On Thu, Mar 7, 2019 at 9:41 AM Peter Zijlstra
>wrote:
>> > >
>> > > What's the call site that made you go "just add __memset() to the
>list"?
>> >
>> >
On Thu, Mar 07, 2019 at 09:54:14AM -0800, Linus Torvalds wrote:
> On Thu, Mar 7, 2019 at 9:41 AM Peter Zijlstra wrote:
> > >
> > > What's the call site that made you go "just add __memset() to the list"?
> >
> > __asan_{,un}poinson_stack_memory()
> > kasan_{,un}poison_shadow()
> >
On Thu, Mar 7, 2019 at 9:41 AM Peter Zijlstra wrote:
> >
> > What's the call site that made you go "just add __memset() to the list"?
>
> __asan_{,un}poinson_stack_memory()
> kasan_{,un}poison_shadow()
> __memset()
Ugh. I think I almost just agree with your decision to just let that
memset
On Thu, Mar 07, 2019 at 08:33:26AM -0800, Linus Torvalds wrote:
> On Thu, Mar 7, 2019 at 3:52 AM Peter Zijlstra wrote:
> >
> > XXX: are we sure we want __memset marked AC-safe?
>
> It's certainly one of the safer functions to call with AC set, but it
> sounds wrong anyway. It's not like it's
On March 7, 2019 8:33:26 AM PST, Linus Torvalds
wrote:
>On Thu, Mar 7, 2019 at 3:52 AM Peter Zijlstra
>wrote:
>>
>> XXX: are we sure we want __memset marked AC-safe?
>
>It's certainly one of the safer functions to call with AC set, but it
>sounds wrong anyway. It's not like it's likely to leak
On Thu, Mar 7, 2019 at 3:52 AM Peter Zijlstra wrote:
>
> XXX: are we sure we want __memset marked AC-safe?
It's certainly one of the safer functions to call with AC set, but it
sounds wrong anyway. It's not like it's likely to leak kernel data
(most memset's are with 0, and even the non-zero
It is important that UACCESS regions are as small as possible;
furthermore the UACCESS state is not scheduled, so doing anything that
might directly call into the scheduler will cause random code to be
ran with UACCESS enabled.
Teach objtool too track UACCESS state and warn about any CALL made
23 matches
Mail list logo
