Re: [PATCH 4/7] x86/vsyscall: Setup vsyscall to compromise LASS protection

[Sohil Mehta]

> > The existing documentation here is incorrect. The default vsyscall 
> > mode is actually xonly. This has been so since:
> > commit 625b7b7f79c6 (x86/vsyscall: Change the default vsyscall mode to 
> > xonly)
> Yes, you are right. but this patch can overwrite and correct existing 
> one. I am assuming we don't need to correct the existing document first 
> before update it for LASS.

We should fix this independent of the LASS enabling. I sent a patch 
earlier today to address it. I apologize, I missed cc'ing you.

https://lore.kernel.org/lkml/20230111193211.1987047-1-sohil.mehta@xxxxxxxxx/

> > > +            In newer versions of Intel platforms that come with
> >
> > Words such as "newer" in the kernel start losing meaning very quickly. 
> > Also, this comment looks out of place in between the vsyscall 
> > sub-options.
> >
> > > +            LASS(Linear Address Space separation) protection,
> > > +            vsyscall is disabled by default. Enabling vsyscall
> > > +            via the parameter overrides LASS protection.
> > > +
> Sure, I will take out this part change.

Actually, having some text here might be ok. I mistook it to be placed 
between the sub-options. But avoid merging it with the previous 
paragraph as is the case right now.

> > Instead of doing this dance, can we provide a simplified behavior to 
> > the user/admin and move the decision making to compile time?
> Current strategy is to disable vsyscall by default only for LASS capable 
> platforms. So that the dynamic decision is likely a necessary.

Making this dynamic and platform dependent would make things hard to 
debug and isolate. It would be a perfect recipe for "But, it works on my 
system!" type of issues.

Let's see what others have to say.

-Sohil