* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Jiri Kosina @ 2019-01-09 10:08 UTC (permalink / raw)
To: Dave Chinner
Cc: Linus Torvalds, Matthew Wilcox, Jann Horn, Andrew Morton, Greg KH,
Peter Zijlstra, Michal Hocko, Linux-MM, kernel list, Linux API
In-Reply-To: <20190109043906.GF27534@dastard>
On Wed, 9 Jan 2019, Dave Chinner wrote:
> FWIW, I just realised that the easiest, most reliable way to invalidate
> the page cache over a file range is simply to do a O_DIRECT read on it.
Neat, good catch indeed. Still, it's only the invalidation part, but the
residency check is the crucial one.
> > Rationale has been provided by Daniel Gruss in this thread -- if the
> > attacker is left with cache timing as the only available vector, he's
> > going to be much more successful with mounting hardware cache timing
> > attack anyway.
>
> No, he said:
>
> "Restricting mincore() is sufficient to fix the hardware-agnostic
> part."
>
> That's not correct - preadv2(RWF_NOWAIT) is also hardware agnostic and
> provides exactly the same information about the page cache as mincore.
Yeah, preadv2(RWF_NOWAIT) is in the same teritory as mincore(), it has
"just" been overlooked. I can't speak for Daniel, but I believe he might
be ok with rephrasing the above as "Restricting mincore() and RWF_NOWAIT
is sufficient ...".
> Timed read/mmap access loops for cache observation are also hardware
> agnostic, and on fast SSD based storage will only be marginally slower
> bandwidth than preadv2(RWF_NOWAIT).
>
> Attackers will pick whatever leak vector we don't fix, so we either fix
> them all (which I think is probably impossible without removing caching
> altogether)
We can't really fix the fact that it's possible to do the timing on the HW
caches though.
> or we start thinking about how we need to isolate the page cache so that
> information isn't shared across important security boundaries (e.g. page
> cache contents are per-mount namespace).
Umm, sorry for being dense, but how would that help that particular attack
scenario on a system that doesn't really employ any namespacing? (which I
still believe is a majority of the systems out there, but I might have
just missed the containers train long time ago :) ).
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Florian Weimer @ 2019-01-09 12:41 UTC (permalink / raw)
To: Thomas Schöbel-Theuer
Cc: Andy Lutomirski, X86 ML, LKML, Linux API, H. Peter Anvin,
Peter Zijlstra, Borislav Petkov, Mike Frysinger, H. J. Lu,
Rich Felker, x32, Arnd Bergmann, Will Deacon, Catalin Marinas,
Linus Torvalds
In-Reply-To: <6577ac4f-524c-37f4-a4d0-6eb94ec7d9a5@schoebel-theuer.de>
* Thomas Schöbel-Theuer:
> 2) please _announce_ _now_ that after the _next_ LTS kernel (whichever
> you want to declare as such), you will _afterwards_ drop the legacy
> 32bit support for 64 kernels (I am deliberately using "management
> speak" here).
>
> => result: the industry should have to fair chance to deal with such a
> roadmap. Yes, it will hurt some people, but they will have enough time
> for their migration projects.
>
> Example: I know that out of several millions of customers of
> webhosting, a very low number of them have some very old legacy 32bit
> software installed in their webspace. This cannot be supported
> forever. But the number of such cases is very small, and there just
> needs to be enough time for finding a solution for those few
> customers.
>
> 3) the next development kernel _after_ that LTS release can then
> immediately drop the 32bit support. Enterprise users should have
> enough time for planning, and for lots of internal projects
> modernizing their infrastructure. Usually, they will need to do this
> anyway in the long term.
We've already phased out support for all 32-bit architectures except
i386 in our products, and i386 is obviously next. (We never supported
x32 in the first place.)
It becomes increasingly difficult to build a 32-bit userspace that meets
backwards-compatibility needs. We want to use SSE2 (to avoid excess
precision for double) and avoid relying on stack realignment (for
compatibility with applications that use the old i386 ABI which did not
require stack realignment). We also have to build the distribution with
a full complement of hardening flags. This results in a combination of
flags that is poorly tested in upstream GCC. The i386 register file
isn't large enough to support all these features at the same time and
combine them with function arguments passed in registers (which some
programs enable manually via function attributes).
So even if we keep the kernel interface, in the forseeable future, I
expect that it will be difficult to build a full, contemporary 32-bit
userspace on i386.
Thanks,
Florian
^ permalink raw reply
* Re: [RFC PATCH v1 3/5] Yama: Enforces noexec mounts or file executability through O_MAYEXEC
From: Mickaël Salaün @ 2019-01-09 13:41 UTC (permalink / raw)
To: Kees Cook, Al Viro, James Morris
Cc: Jann Horn, Mickaël Salaün, kernel list, Jonathan Corbet,
Matthew Garrett, Michael Kerrisk-manpages, Mimi Zohar,
philippe.trebuchet, Shuah Khan, thibaut.sautereau,
vincent.strubel, Perez Yves-Alexis, Kernel Hardening, Linux API,
linux-security-module, linux-fsdevel@vger.kernel.org,
Andy Lutomirski
In-Reply-To: <CAGXu5jKHPE6WfbXpiwzm=vRbgJ-rCePxsrYmVzZ1+RURp-6nJg@mail.gmail.com>
On 09/01/2019 00:30, Kees Cook wrote:
> On Tue, Jan 8, 2019 at 5:29 AM Mickaël Salaün
> <mickael.salaun@ssi.gouv.fr> wrote:
>>
>>
>> On 03/01/2019 12:17, Jann Horn wrote:
>>> On Thu, Dec 13, 2018 at 3:49 PM Mickaël Salaün
>>> <mickael.salaun@ssi.gouv.fr> wrote:
>>>> On 12/12/2018 18:09, Jann Horn wrote:
>>>>> On Wed, Dec 12, 2018 at 9:18 AM Mickaël Salaün <mic@digikod.net> wrote:
>>>>>> Enable to either propagate the mount options from the underlying VFS
>>>>>> mount to prevent execution, or to propagate the file execute permission.
>>>>>> This may allow a script interpreter to check execution permissions
>>>>>> before reading commands from a file.
>>>>>>
>>>>>> The main goal is to be able to protect the kernel by restricting
>>>>>> arbitrary syscalls that an attacker could perform with a crafted binary
>>>>>> or certain script languages. It also improves multilevel isolation
>>>>>> by reducing the ability of an attacker to use side channels with
>>>>>> specific code. These restrictions can natively be enforced for ELF
>>>>>> binaries (with the noexec mount option) but require this kernel
>>>>>> extension to properly handle scripts (e.g., Python, Perl).
>
> I like this idea, but I think it shouldn't live in Yama (since it is
> currently intended to be a ptrace-policy-only LSM). It was
> _originally_ designed to do various DAC improvements, but the
> agreement was that those should live directly in the VFS instead (i.e.
> the symlink, hardlink and now fifo and regular file defenses).
>
> This should likely go in similarly. (But if not, it could also be its own LSM.)
>
I think that Yama is quite handy and make sense here, but I'm fine
putting this knob elsewhere. However, I was thinking, for a future patch
series, to add another sysctl to lock this choice, i.e. generalizing the
way Yama can lock the ptrace_scope.
What matter here is the ability for an LSM to use this O_MAYEXEC flag.
Yama is a good place to showcase this feature and I think it is cleaner
to leverage the LSM framework to put new (optional) security features. I
can easily create a new LSM but it would be pretty similar to Yama...
What do you think about it James and Al?
Side question: wouldn't it be better to use a 0600 mode (instead of
0644) for this kind of sysctl?
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Rich Felker @ 2019-01-09 16:02 UTC (permalink / raw)
To: Florian Weimer
Cc: Thomas Schöbel-Theuer, Andy Lutomirski, X86 ML, LKML,
Linux API, H. Peter Anvin, Peter Zijlstra, Borislav Petkov,
Mike Frysinger, H. J. Lu, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas, Linus Torvalds
In-Reply-To: <871s5muhp1.fsf@oldenburg2.str.redhat.com>
On Wed, Jan 09, 2019 at 01:41:14PM +0100, Florian Weimer wrote:
> * Thomas Schöbel-Theuer:
>
> > 2) please _announce_ _now_ that after the _next_ LTS kernel (whichever
> > you want to declare as such), you will _afterwards_ drop the legacy
> > 32bit support for 64 kernels (I am deliberately using "management
> > speak" here).
> >
> > => result: the industry should have to fair chance to deal with such a
> > roadmap. Yes, it will hurt some people, but they will have enough time
> > for their migration projects.
> >
> > Example: I know that out of several millions of customers of
> > webhosting, a very low number of them have some very old legacy 32bit
> > software installed in their webspace. This cannot be supported
> > forever. But the number of such cases is very small, and there just
> > needs to be enough time for finding a solution for those few
> > customers.
> >
> > 3) the next development kernel _after_ that LTS release can then
> > immediately drop the 32bit support. Enterprise users should have
> > enough time for planning, and for lots of internal projects
> > modernizing their infrastructure. Usually, they will need to do this
> > anyway in the long term.
>
> We've already phased out support for all 32-bit architectures except
> i386 in our products, and i386 is obviously next. (We never supported
> x32 in the first place.)
>
> It becomes increasingly difficult to build a 32-bit userspace that meets
> backwards-compatibility needs. We want to use SSE2 (to avoid excess
> precision for double) and avoid relying on stack realignment (for
> compatibility with applications that use the old i386 ABI which did not
> require stack realignment). We also have to build the distribution with
> a full complement of hardening flags. This results in a combination of
> flags that is poorly tested in upstream GCC. The i386 register file
> isn't large enough to support all these features at the same time and
> combine them with function arguments passed in registers (which some
> programs enable manually via function attributes).
>
> So even if we keep the kernel interface, in the forseeable future, I
> expect that it will be difficult to build a full, contemporary 32-bit
> userspace on i386.
I guess that's informative of how one company's distro process works,
but it's not representative. Your customers are enterprise and
big-server (probably mostly the former) oriented which is exactly the
domain where 32-bit is of course irrelevant except for running legacy
applications. Where it matters are embedded and other systems striving
for resource efficiency.
For what it's worth, 32-bit archs including i386 and many others are
well-supported in Debian with no forseeable EOL I'm aware of, and most
if not all of the musl-libc-based distros I'm familiar with support
32-bit archs including i386.
I don't think waning relevance of 32-bit is a reasonable argument
against x32 since x32's relevance is in exactly the places where
32-bit is already relevant and preferred for important reasons.
Rich
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Linus Torvalds @ 2019-01-09 18:25 UTC (permalink / raw)
To: Dave Chinner
Cc: Jiri Kosina, Matthew Wilcox, Jann Horn, Andrew Morton, Greg KH,
Peter Zijlstra, Michal Hocko, Linux-MM, kernel list, Linux API
In-Reply-To: <20190109043906.GF27534@dastard>
On Tue, Jan 8, 2019 at 8:39 PM Dave Chinner <david@fromorbit.com> wrote:
>
> FWIW, I just realised that the easiest, most reliable way to
> invalidate the page cache over a file range is simply to do a
> O_DIRECT read on it.
If that's the case, that's actually an O_DIRECT bug.
It should only invalidate the caches on write.
On reads, it wants to either _flush_ any direct caches before the
read, or just take the data from the caches. At no point is
"invalidate" a valid model.
Of course, I'm not in the least bit shocked if O_DIRECT is buggy like
this. But looking at least at the ext4 routine, the read just does
ret = filemap_write_and_wait_range(mapping, iocb->ki_pos,
and I don't see any invalidation.
Having read access to a file absolutely should *not* mean that you can
flush caches on it. That's a write op.
Any filesystem that invalidates the caches on read is utterly buggy.
Can you actually point to such a thing? Let's get that fixed, because
it's completely wrong regardless of this whole mincore issue.
Linus
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Dave Chinner @ 2019-01-10 0:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jiri Kosina, Matthew Wilcox, Jann Horn, Andrew Morton, Greg KH,
Peter Zijlstra, Michal Hocko, Linux-MM, kernel list, Linux API
In-Reply-To: <CAHk-=wic28fSkwmPbBHZcJ3BGbiftprNy861M53k+=OAB9n0=w@mail.gmail.com>
On Wed, Jan 09, 2019 at 10:25:43AM -0800, Linus Torvalds wrote:
> On Tue, Jan 8, 2019 at 8:39 PM Dave Chinner <david@fromorbit.com> wrote:
> >
> > FWIW, I just realised that the easiest, most reliable way to
> > invalidate the page cache over a file range is simply to do a
> > O_DIRECT read on it.
>
> If that's the case, that's actually an O_DIRECT bug.
>
> It should only invalidate the caches on write.
Sounds nice from a theoretical POV, but reality has taught us
very different lessons.
FWIW, a quick check of XFS's history so you understand how long this
behaviour has been around. It was introduced in the linux port in
2001 as direct IO support was being added:
commit e837eac23662afae603aaaef7c94bc839c1b8f67
Author: Steve Lord <lord@sgi.com>
Date: Mon Mar 5 16:47:52 2001 +0000
Add bounds checking for direct I/O, do the cache invalidation for
data coherency on direct I/O.
This was basically a direct port of the flush+invalidation code in
the Irix direct IO path, which was introduced in 1995:
> revision 1.149
> date: 1995/08/11 20:09:44; author: ajs; state: Exp; lines: +70 -2
> 280514 Adding page cache flusing calls to make direct
> I/O coherent with buffered I/O.
IOWs, history tells us that invalidation for direct IO reads has
been done on XFS for almost 25 years. I know for certain that there
have been applications out there that depend on this
invalidation-on-read behaviour (another of those "reality bites"
lessons) so we can't just remove it because you *think* it is a bug.
i.e. we *could* remove the invalidation on read, but this we have a
major behavioural change to the XFS direct IO path. This means we
need to determine if we've just awoken sleeping data corruption
krakens as well as determine if there are any performance
regressions that result from the behavioural change.
Which brings me to validation. If the recent
clone/dedupe/copy_file_range() debacle has taught me anything, it's
that validating a "simple" IO path mechanism is going to take months
worth of machine time before we have any confidence that the change
is not going to expose users to new data corruption problems.
That's the difficulty here - it only takes 5 minutes to change
the code, but there's months of machine time needed to determine if
it's really safe to make that code change. Testing has a nasty habit
of finding invalid assumptions; when those are assumptions about
data coherency and integrity we can't test them on our users.
And, really, this would be just another band-aid over a symptom of
the information leak - it doesn't prevent users from being able to
control page cache invalidation. It just removes one method, just
like hacking mincore only removes one method of observing the page
cache. And, like mincore(), there's every chance it impacts on
userspace in a negative manner and so we need to be very careful
here.
> On reads, it wants to either _flush_ any direct caches before the
> read, or just take the data from the caches. At no point is
> "invalidate" a valid model.
>
> Of course, I'm not in the least bit shocked if O_DIRECT is buggy like
> this. But looking at least at the ext4 routine, the read just does
>
> ret = filemap_write_and_wait_range(mapping, iocb->ki_pos,
>
> and I don't see any invalidation.
I wouldn't look at ext4 as an example of a reliable, problem free
direct IO implementation because, historically speaking, it's been a
series of nasty hacks (*cough* mount -o dioread_nolock *cough*) and
been far worse than XFS from data integrity, performance and
reliability perspectives.
IMO, "because ext4" has been a poor reason for justifying anything
for a long time, not the least when talking about features that
didn't even originate in extN....
> Can you actually point to such a thing? Let's get that fixed, because
> it's completely wrong regardless of this whole mincore issue.
The biggest problem that remains today is that we have no mechanism
for serialising page faults against DIO. If we leave pages cached in
memory while we have a AIO+DIO read (or write!) in progress, we can
dirty the page and run a buffered read before the AIO+DIO read
returns. This now leaves us in the state where where the AIO+DIO
read returns different (stale) data to a buffered read that has
already completed because it hit the dirty page cache. i.e. we
still have nasty page cache vs direct IO coherency problems, and
they are largely unsolvable because of the limitations of the core
kernel infrastructure architecture.
Yes, you can argue that userspace is doing an insane thing, but
every so often we come across coherency issues like this that are
out of a user's control (e.g. backup scan vs app accesses) and we do
our best to ensure that they don't cause problems given the
constraints we have. Invalidating the page cache on dio reads
mostly mitigates these coherency race conditions and that's why it's
still there in the XFS code paths...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Dave Chinner @ 2019-01-10 1:15 UTC (permalink / raw)
To: Jiri Kosina
Cc: Linus Torvalds, Matthew Wilcox, Jann Horn, Andrew Morton, Greg KH,
Peter Zijlstra, Michal Hocko, Linux-MM, kernel list, Linux API
In-Reply-To: <nycvar.YFH.7.76.1901091050560.16954@cbobk.fhfr.pm>
On Wed, Jan 09, 2019 at 11:08:57AM +0100, Jiri Kosina wrote:
> On Wed, 9 Jan 2019, Dave Chinner wrote:
>
> > FWIW, I just realised that the easiest, most reliable way to invalidate
> > the page cache over a file range is simply to do a O_DIRECT read on it.
>
> Neat, good catch indeed. Still, it's only the invalidation part, but the
> residency check is the crucial one.
>
> > > Rationale has been provided by Daniel Gruss in this thread -- if the
> > > attacker is left with cache timing as the only available vector, he's
> > > going to be much more successful with mounting hardware cache timing
> > > attack anyway.
> >
> > No, he said:
> >
> > "Restricting mincore() is sufficient to fix the hardware-agnostic
> > part."
> >
> > That's not correct - preadv2(RWF_NOWAIT) is also hardware agnostic and
> > provides exactly the same information about the page cache as mincore.
>
> Yeah, preadv2(RWF_NOWAIT) is in the same teritory as mincore(), it has
> "just" been overlooked. I can't speak for Daniel, but I believe he might
> be ok with rephrasing the above as "Restricting mincore() and RWF_NOWAIT
> is sufficient ...".
Good luck with restricting RWF_NOWAIT. I eagerly await all the
fstests that exercise both the existing and new behaviours to
demonstrate they work correctly.
> > Timed read/mmap access loops for cache observation are also hardware
> > agnostic, and on fast SSD based storage will only be marginally slower
> > bandwidth than preadv2(RWF_NOWAIT).
> >
> > Attackers will pick whatever leak vector we don't fix, so we either fix
> > them all (which I think is probably impossible without removing caching
> > altogether)
>
> We can't really fix the fact that it's possible to do the timing on the HW
> caches though.
We can't really fix the fact that it's possible to do the timing on
the page cache, either.
> > or we start thinking about how we need to isolate the page cache so that
> > information isn't shared across important security boundaries (e.g. page
> > cache contents are per-mount namespace).
>
> Umm, sorry for being dense, but how would that help that particular attack
> scenario on a system that doesn't really employ any namespacing?
What's your security boundary?
The "detect what code an app is running" exploit is based on
invalidating and then observing how shared, non-user-owned files
mapped with execute privileges change cache residency.
If the security boundary is within the local container, should users
inside that container be allowed to invalidate the cache of
executable files and libraries they don't own? In this case, we
can't stop observation, because that only require read permissions
and high precision timing, hence the only thing that can be done
here is prevent non-owners from invalidating the page cache.
If the security boundary is a namespace or guest VM, then permission
checks don't work - the user may own the file within that container.
This problem now is that the page cache is observable and
controllable from both sides of the fence. Hence the only way to
prevent observation of the code being run in a different namespace
is to prevent the page being shared across both containers.
The exfiltration exploit requires the page cache to be observable
and controllable on both sides of the security boundary. Should
users be able to observe and control the cached pages accessed by a
different container? KSM page deduplication lessons say no. This is
an even harder problem, because page cache residency can be observed
from remote machines....
What scares me is that new features being proposed could make our
exposure a whole lot worse. e.g. the recent virtio-pmem ("fake-dax")
proposal will directly share host page cache pages into guest VMs w/
DAX capability. i.e. the guest directly accesses the host page
cache. This opens up the potential for host page cache timing
attacks from the guest VMs, and potential guest to guest
observation/exploitation is possible if the same files are mapped
into multiple guests....
IOws the two questions here are simply: "What's your security
boundary?" and "Is the page cache visible and controllable on both
sides?".
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Linus Torvalds @ 2019-01-10 1:18 UTC (permalink / raw)
To: Dave Chinner
Cc: Jiri Kosina, Matthew Wilcox, Jann Horn, Andrew Morton, Greg KH,
Peter Zijlstra, Michal Hocko, Linux-MM, kernel list, Linux API
In-Reply-To: <20190110004424.GH27534@dastard>
On Wed, Jan 9, 2019 at 4:44 PM Dave Chinner <david@fromorbit.com> wrote:
>
> I wouldn't look at ext4 as an example of a reliable, problem free
> direct IO implementation because, historically speaking, it's been a
> series of nasty hacks (*cough* mount -o dioread_nolock *cough*) and
> been far worse than XFS from data integrity, performance and
> reliability perspectives.
That's some big words from somebody who just admitted to much worse hacks.
Seriously. XFS is buggy in this regard, ext4 apparently isn't.
Thinking that it's better to just invalidate the cache for direct IO
reads is all kinds of odd.
Linus
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Andy Lutomirski @ 2019-01-10 5:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Chinner, Jiri Kosina, Matthew Wilcox, Jann Horn,
Andrew Morton, Greg KH, Peter Zijlstra, Michal Hocko, Linux-MM,
kernel list, Linux API
In-Reply-To: <CAHk-=wg1jSQ-gq-M3+HeTBbDs1VCjyiwF4gqnnBhHeWizyrigg@mail.gmail.com>
On Wed, Jan 9, 2019 at 5:18 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, Jan 9, 2019 at 4:44 PM Dave Chinner <david@fromorbit.com> wrote:
> >
> > I wouldn't look at ext4 as an example of a reliable, problem free
> > direct IO implementation because, historically speaking, it's been a
> > series of nasty hacks (*cough* mount -o dioread_nolock *cough*) and
> > been far worse than XFS from data integrity, performance and
> > reliability perspectives.
>
> That's some big words from somebody who just admitted to much worse hacks.
>
> Seriously. XFS is buggy in this regard, ext4 apparently isn't.
>
> Thinking that it's better to just invalidate the cache for direct IO
> reads is all kinds of odd.
>
This whole discussion seems to have gone a little bit off the rails...
Linus, I think I agree with Dave's overall sentiment, though, and I
think you should consider reverting your patch. Here's why. The
basic idea behind the attack is that the authors found efficient ways
to do two things: evict a page from page cache and detect, *without
filling the cache*, whether a page is cached. The combination lets an
attacker efficiently tell when another process reads a page. We need
to keep in mind that this attack is a sophisticated attack, and anyone
using it won't have any problem using a nontrivial way to detect
whether a page is in page cache.
So, unless we're going to try for real to make it hard to tell whether
a page is cached without causing that page to become cached, it's not
worth playing whack-a-mole. And, right now, mincore is whacking a
mole. RWF_NOWAIT appears to do essentially the same thing at very
little cost. I haven't really dug in, but I assume that various
prefaulting tricks combined with various pagetable probing tricks can
do similar things, but that's at least a *lot* more complicated.
So unless we're going to lock down RWF_NOWAIT as well, I see no reason
to lock down mincore(). Direct IO is a red herring -- O_DIRECT is
destructive enough that it seems likely to make the attacks a lot less
efficient.
--- begin digression ---
Since direct IO has been brought up, I have a question. I've wondered
for years why direct IO works the way it does. If I were implementing
it from scratch, my first inclination would be to use the page cache
instead of fighting it. To do a single-page direct read, I would look
that page up in the page cache (i.e. i_pages these days). If the page
is there, I would do a normal buffered read. If the page is not
there, I would insert a record into i_pages indicating that direct IO
is in progress and then I would do the IO into the destination page.
If any other read, direct or otherwise, sees a record saying "under
direct IO", it would wait.
To do a single-page direct write, I would look it up in i_pages. If
it's there, I would do a buffered write followed by a sync (because
applications expect a sync). If it's not there, I would again add a
record saying "under direct IO" and do the IO.
The idea is that this works as much like buffered IO as possible,
except that the pages backing the IO aren't normal sharable page cache
pages.
The multi-page case would be just an optimization on top of the
single-page case. The idea would be to somehow mark i_pages with
entire extents under direct IO. It's a radix tree -- this can, at
least in theory, be done efficiently. As long as all direct IO
operations run in increasing order of offset, there shouldn't be lock
ordering problems.
Other than history and possibly performance, is there any reason that
direct IO doesn't work this way?
P.S. What, if anything, prevents direct writes from causing trouble
when the underlying FS or backing store needs stable pages?
Similarly, what, if anything, prevents direct reads from temporarily
exposing unintended data to user code if the fs or underlying device
transforms the data during the read process (e.g. by decrypting
something)?
--- end digression ---
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Dave Chinner @ 2019-01-10 7:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jiri Kosina, Matthew Wilcox, Jann Horn, Andrew Morton, Greg KH,
Peter Zijlstra, Michal Hocko, Linux-MM, kernel list, Linux API
In-Reply-To: <CAHk-=wg1jSQ-gq-M3+HeTBbDs1VCjyiwF4gqnnBhHeWizyrigg@mail.gmail.com>
On Wed, Jan 09, 2019 at 05:18:21PM -0800, Linus Torvalds wrote:
> On Wed, Jan 9, 2019 at 4:44 PM Dave Chinner <david@fromorbit.com> wrote:
> >
> > I wouldn't look at ext4 as an example of a reliable, problem free
> > direct IO implementation because, historically speaking, it's been a
> > series of nasty hacks (*cough* mount -o dioread_nolock *cough*) and
> > been far worse than XFS from data integrity, performance and
> > reliability perspectives.
>
> That's some big words from somebody who just admitted to much worse hacks.
Sorry, what hacks did I just admit to making? This O_DIRECT
behaviour long predates me - I'm just the messenger and you are
shooting from the hip.
Linus, the point I was making is that there are many, many ways to
control page cache invalidation and measure page cache residency,
and that trying to address them one-by-one is just a game of
whack-a-mole.
In future, can you please try not to go off the rails when someone
mentions O_DIRECT? You have a terrible habit of going off on
misdirected rants about O_DIRECT and/or XFS at any opportunity you
can get, and all it does is derail whatever useful conversation was
taking place.
> Seriously. XFS is buggy in this regard, ext4 apparently isn't.
So you keep asserting despite being presented with evidence that it
mitigates other longstanding bugs that are really hard to solve.
Ignoring all the evidence you've been presented with and
re-asserting your original statement doesn't make it correct.
Did you not think to ask "what are those problems, and what can do
to solve them so we can remove the invalidation mitigations that XFS
uses?". That would be a useful contribution, whereas shouting about
how O_DIRECT is broken just pisses off the people working their
asses off to fix the problems you just heard about and are ranting
about.
> Thinking that it's better to just invalidate the cache for direct IO
> reads is all kinds of odd.
No, it's practicality. If we can't fix the problem, we have to
mitigate it. When we fix the underlying problem we can remove the
mitigation code. having you assert that it's broken and demand that
it be removed doesn't change the fact that we haven't fixed the
underlying problems. It's being worked on, but we're not there yet.
-Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Jiri Kosina @ 2019-01-10 7:54 UTC (permalink / raw)
To: Dave Chinner
Cc: Linus Torvalds, Matthew Wilcox, Jann Horn, Andrew Morton, Greg KH,
Peter Zijlstra, Michal Hocko, Linux-MM, kernel list, Linux API
In-Reply-To: <20190110011533.GI27534@dastard>
On Thu, 10 Jan 2019, Dave Chinner wrote:
> > Yeah, preadv2(RWF_NOWAIT) is in the same teritory as mincore(), it has
> > "just" been overlooked. I can't speak for Daniel, but I believe he might
> > be ok with rephrasing the above as "Restricting mincore() and RWF_NOWAIT
> > is sufficient ...".
>
> Good luck with restricting RWF_NOWAIT. I eagerly await all the
> fstests that exercise both the existing and new behaviours to
> demonstrate they work correctly.
Well, we can still resurrect my original aproach of doing this opt-in
based on a sysctl setting, and letting the admin choose his poison.
If 'secure' mode is selected, RWF_NOWAIT will then probably just always
fail wit EAGAIN.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Linus Torvalds @ 2019-01-10 11:47 UTC (permalink / raw)
To: Dave Chinner
Cc: Jiri Kosina, Matthew Wilcox, Jann Horn, Andrew Morton, Greg KH,
Peter Zijlstra, Michal Hocko, Linux-MM, kernel list, Linux API
In-Reply-To: <20190110070355.GJ27534@dastard>
On Wed, Jan 9, 2019 at 11:04 PM Dave Chinner <david@fromorbit.com> wrote:
>
> Sorry, what hacks did I just admit to making? This O_DIRECT
> behaviour long predates me - I'm just the messenger and you are
> shooting from the hip.
Sure, sorry. I find this whole thing annoying.
> Linus, the point I was making is that there are many, many ways to
> control page cache invalidation and measure page cache residency,
> and that trying to address them one-by-one is just a game of
> whack-a-mole.
.. and I agree. But let's a step back.Because there are different issues.
First off, the whole page cache attack is not necessarily something
many people will care about. As has been pointed out, it's often a
matter of convenience and (relative) portability.
And no, we're *never* going to stop all side channel leaks. Some parts
of caching (notably the timing effects of it) are pretty fundamental.
So at no point is this going to be some kind of absolute line in the
sand _anyway_. There is no black-and-white "you're protected", there's
only levels of convenience.
A remote attacker is hopefully going to be limited by the interfaces
to just timing attacks, although who knows what something like JS
might expose. Presumably neither mincore() nor arbitrary O_DIRECT or
pread2() flags.
Anyway, the reason I was trying to plug mincore() is largely that that
code didn't make much sense to begin with, and simply this:
mm/mincore.c | 94 +++++++++---------------------------------------------------
1 file changed, 13 insertions(+), 81 deletions(-)
if we can make people happier by removing lines of code and making the
semantics more clear anyway, it's worth trying.
No?
Is that everything? No. As mentioned, you'll never get to that "ok, we
plugged everything" point anyway. But removing a fairly easy way to
probe the cache that has no real upsides should be fairly
non-controversial.
But I do have to say that in many ways the page cache is *not* a great
attack vector because there's often lots of it, and it's fairly hard
to control. Once something is in the page cache for whatever reason,
it tends to be pretty sticky, and flushing it tends to be fairly hard
to predict.
And a cheap and residency (whether a simple probe like mincore of or a
NOWAIT flag) check is actually important just to try to control the
flushing part. Brute-forcing the flushing is generally very expensive,
but if you can't even see if you flushed it, it's way more so.
If there's a way to control the cache residency directly, that's
actually a much bigger hole than any residency check ever were.
Because once you can flush caches by reading, at that point you can
just flush a particular page and look at the IO stats for the root
partition or something. No residency check even needed.
So I do think that yes, as long as you can do a directed cache flush,
mincore is *entirely* immaterial.
Still, giving mincore clearer semantics and simpler code? Win-win.
(Except, of course, if somebody actually notices outside of tests.
Which may well happen and just force us to revert that commit. But
that's a separate issue entirely).
But I do think that we should strive to *never* invalidate caches on
read accesses. I don't actually see where you are doing that,
honestly: at least dio_complete() only does it for writes.
So I'm actually hoping that you are mis-remembering this and it turns
out that O_DIRECT reads don't invalidate caches.
Linus
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Dominique Martinet @ 2019-01-10 12:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Chinner, Jiri Kosina, Matthew Wilcox, Jann Horn,
Andrew Morton, Greg KH, Peter Zijlstra, Michal Hocko, Linux-MM,
kernel list, Linux API
In-Reply-To: <CAHk-=wigwXV_G-V1VxLs6BAvVkvW5=Oj+xrNHxE_7yxEVwoe3w@mail.gmail.com>
Linus Torvalds wrote on Thu, Jan 10, 2019:
> (Except, of course, if somebody actually notices outside of tests.
> Which may well happen and just force us to revert that commit. But
> that's a separate issue entirely).
Both Dave and I pointed at a couple of utilities that break with
this. nocache can arguably work with the new behaviour but will behave
differently; vmtouch on the other hand is no longer able to display
what's in cache or not - people use that for example to "warm up" a
container in page cache based on how it appears after it had been
running for a while is a pretty valid usecase to me.
>From the list Kevin harvested out of the debian code search, the
postgresql use case is pretty similar - probe what pages of the database
were in cache at shutdown so when you restart it you can preload these
and reach "cruse speed" faster.
Sure that's probably not billions of users but this all looks fairly
valid to me...
--
Dominique
^ permalink raw reply
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Matthew Wilcox @ 2019-01-10 14:47 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Linus Torvalds, Dave Chinner, Jiri Kosina, Jann Horn,
Andrew Morton, Greg KH, Peter Zijlstra, Michal Hocko, Linux-MM,
kernel list, Linux API
In-Reply-To: <CALCETrWxwaBUYMg=aLySJByMgXzuzV4gHS0n6O6Oet2Jm6SAbw@mail.gmail.com>
On Wed, Jan 09, 2019 at 09:26:41PM -0800, Andy Lutomirski wrote:
> Since direct IO has been brought up, I have a question. I've wondered
> for years why direct IO works the way it does. If I were implementing
> it from scratch, my first inclination would be to use the page cache
> instead of fighting it. To do a single-page direct read, I would look
> that page up in the page cache (i.e. i_pages these days). If the page
> is there, I would do a normal buffered read. If the page is not
> there, I would insert a record into i_pages indicating that direct IO
> is in progress and then I would do the IO into the destination page.
> If any other read, direct or otherwise, sees a record saying "under
> direct IO", it would wait.
OK, you're in the same ballpark I am ;-) Kent Overstreet pointed out
that what you want to do here is great for the mixed case, but it's
pretty inefficient for IOs to files which are wholly uncached.
So what I'm currently thinking about is an rwsem which works like this:
O_DIRECT task:
if i_pages is empty, take rwsem for read, recheck i_pages is empty, do IO,
drop rwsem.
if i_pages is not empty, insert XA_LOCK_ENTRY, when IO complete, wake waitqueue for that (mapping, index).
buffered IO:
if i_pages is empty, take rwsem for write, allocate page, insert page, drop rwsem.
if i_pages is not empty, look up index, if entry is XA_LOCK_ENTRY sleep on
waitqueue. otherwise proceed as now.
^ permalink raw reply
* Re: [RESEND PATCH v3 2/2] sysctl: handle overflow for file-max
From: Christian Brauner @ 2019-01-10 14:50 UTC (permalink / raw)
To: Dominik Brodowski
Cc: akpm, keescook, linux-kernel, ebiederm, mcgrof, joe.lawrence,
longman, viro, adobriyan, linux-api
In-Reply-To: <20190108070110.GA7998@light.dominikbrodowski.net>
On Tue, Jan 08, 2019 at 08:01:10AM +0100, Dominik Brodowski wrote:
> On Mon, Jan 07, 2019 at 11:27:00PM +0100, Christian Brauner wrote:
> > @@ -2833,6 +2836,10 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
> > break;
> > if (neg)
> > continue;
> > + if ((max && val > *max) || (min && val < *min)) {
> > + err = -EINVAL;
> > + break;
> > + }
> > val = convmul * val / convdiv;
> > if ((min && val < *min) || (max && val > *max))
> > continue;
>
> This is a generic change which affects all users of
> do_proc_doulongvec_minmax() that have extra1 or extra2 set. In sysctl.c, I
> do not see another user of proc_doulongvec_minmax() that has extra1 or
> extra2 set. However, have you verified whether your patch changes the
> behaviour for other files that make use of proc_doulongvec_minmax() or
> proc_doulongvec_ms_jiffies_minmax(), and not only of the file-max sysctl?
Sorry for the delayed reply. I did look at the callers. The functions
that are of interest afaict are:
proc_doulongvec_ms_jiffies_minmax
proc_doulongvec_minmax
So this could be visible when users write values that would overflow the
type used in the kernel.
I guess your point is whether we are venturing into userspace break
territory. Hm... We should probably make sure that we're not regressing
anyone else! What do you think if instead of the above patch we did:
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ba4d9e85feb8..37727b4c7a97 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1721,7 +1721,7 @@ static struct ctl_table fs_table[] = {
.data = &files_stat.max_files,
.maxlen = sizeof(files_stat.max_files),
.mode = 0644,
- .proc_handler = proc_doulongvec_minmax,
+ .proc_handler = proc_file_max,
},
{
.procname = "nr_open",
@@ -2758,7 +2758,7 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
void __user *buffer,
size_t *lenp, loff_t *ppos,
unsigned long convmul,
- unsigned long convdiv)
+ unsigned long convdiv, bool strict)
{
unsigned long *i, *min, *max;
int vleft, first = 1, err = 0;
@@ -2806,7 +2806,12 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
continue;
val = convmul * val / convdiv;
if ((min && val < *min) || (max && val > *max))
- continue;
+ if (strict) {
+ err = -EINVAL;
+ break;
+ } else {
+ continue;
+ }
*i = val;
} else {
val = convdiv * (*i) / convmul;
@@ -2843,7 +2848,15 @@ static int do_proc_doulongvec_minmax(struct ctl_table *table, int write,
unsigned long convdiv)
{
return __do_proc_doulongvec_minmax(table->data, table, write,
- buffer, lenp, ppos, convmul, convdiv);
+ buffer, lenp, ppos, convmul, convdiv, false);
+}
+
+static int proc_file_max(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp, loff_t *ppos,
+ unsigned long convmul, unsigned long convdiv)
+{
+ return __do_proc_doulongvec_minmax(table->data, table, write, buffer,
+ lenp, ppos, convmul, convdiv, true);
}
/**
@@ -2865,7 +2878,8 @@ static int do_proc_doulongvec_minmax(struct ctl_table *table, int write,
int proc_doulongvec_minmax(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
- return do_proc_doulongvec_minmax(table, write, buffer, lenp, ppos, 1l, 1l);
+ return do_proc_doulongvec_minmax(table, write, buffer, lenp, ppos, 1l,
+ 1l, false);
}
/**
@@ -2890,7 +2904,7 @@ int proc_doulongvec_ms_jiffies_minmax(struct ctl_table *table, int write,
size_t *lenp, loff_t *ppos)
{
return do_proc_doulongvec_minmax(table, write, buffer,
- lenp, ppos, HZ, 1000l);
+ lenp, ppos, HZ, 1000l, false);
}
^ permalink raw reply related
* Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
From: Matthew Wilcox @ 2019-01-10 14:50 UTC (permalink / raw)
To: Dave Chinner
Cc: Linus Torvalds, Jiri Kosina, Jann Horn, Andrew Morton, Greg KH,
Peter Zijlstra, Michal Hocko, Linux-MM, kernel list, Linux API
In-Reply-To: <20190110004424.GH27534@dastard>
On Thu, Jan 10, 2019 at 11:44:24AM +1100, Dave Chinner wrote:
> And, really, this would be just another band-aid over a symptom of
> the information leak - it doesn't prevent users from being able to
> control page cache invalidation. It just removes one method, just
> like hacking mincore only removes one method of observing the page
> cache. And, like mincore(), there's every chance it impacts on
> userspace in a negative manner and so we need to be very careful
> here.
Putting the mincore() / cache timing information leak aside though,
the current behaviour of XFS means that an attacker can screw up the
performance of random applications just by repeatedly doing O_DIRECT
reads of libc.so.
Maybe O_DIRECT reads should be forbidden from files on XFS unless you
also have write access to them? (eg owner).
^ permalink raw reply
* Re: [RESEND PATCH v3 2/2] sysctl: handle overflow for file-max
From: Dominik Brodowski @ 2019-01-10 14:55 UTC (permalink / raw)
To: Christian Brauner
Cc: akpm, keescook, linux-kernel, ebiederm, mcgrof, joe.lawrence,
longman, viro, adobriyan, linux-api
In-Reply-To: <20190110145004.zhc2t42aasni7wnq@brauner.io>
On Thu, Jan 10, 2019 at 03:50:05PM +0100, Christian Brauner wrote:
> On Tue, Jan 08, 2019 at 08:01:10AM +0100, Dominik Brodowski wrote:
> > On Mon, Jan 07, 2019 at 11:27:00PM +0100, Christian Brauner wrote:
> > > @@ -2833,6 +2836,10 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
> > > break;
> > > if (neg)
> > > continue;
> > > + if ((max && val > *max) || (min && val < *min)) {
> > > + err = -EINVAL;
> > > + break;
> > > + }
> > > val = convmul * val / convdiv;
> > > if ((min && val < *min) || (max && val > *max))
> > > continue;
> >
> > This is a generic change which affects all users of
> > do_proc_doulongvec_minmax() that have extra1 or extra2 set. In sysctl.c, I
> > do not see another user of proc_doulongvec_minmax() that has extra1 or
> > extra2 set. However, have you verified whether your patch changes the
> > behaviour for other files that make use of proc_doulongvec_minmax() or
> > proc_doulongvec_ms_jiffies_minmax(), and not only of the file-max sysctl?
>
> Sorry for the delayed reply. I did look at the callers. The functions
> that are of interest afaict are:
>
> proc_doulongvec_ms_jiffies_minmax
> proc_doulongvec_minmax
>
> So this could be visible when users write values that would overflow the
> type used in the kernel.
>
> I guess your point is whether we are venturing into userspace break
> territory. Hm... We should probably make sure that we're not regressing
> anyone else! What do you think if instead of the above patch we did:
Hm, I prefer the original patch -- as the same (valid) reasons which apply
for the file-max sysctl might also apply to other users of this function
where extra1 and/or2 extra2 are set.
If there are no other users of this function where extra1 or extra2 are set,
just add a comment in the commit message:
While this changes the behaviour of __do_proc_doulongvec_minmax(),
no other existing users in the kernel are affected by this change.
If there are other users of this function where extra1 or extra2 are set,
you would need to generalize the commit message overall.
Thanks,
Dominik
^ permalink raw reply
* Re: [RESEND PATCH v3 2/2] sysctl: handle overflow for file-max
From: Christian Brauner @ 2019-01-10 15:00 UTC (permalink / raw)
To: Dominik Brodowski
Cc: akpm, keescook, linux-kernel, ebiederm, mcgrof, joe.lawrence,
longman, viro, adobriyan, linux-api
In-Reply-To: <20190110145559.relfx37ocq5xu4by@isilmar-4.linta.de>
On Thu, Jan 10, 2019 at 03:55:59PM +0100, Dominik Brodowski wrote:
> On Thu, Jan 10, 2019 at 03:50:05PM +0100, Christian Brauner wrote:
> > On Tue, Jan 08, 2019 at 08:01:10AM +0100, Dominik Brodowski wrote:
> > > On Mon, Jan 07, 2019 at 11:27:00PM +0100, Christian Brauner wrote:
> > > > @@ -2833,6 +2836,10 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
> > > > break;
> > > > if (neg)
> > > > continue;
> > > > + if ((max && val > *max) || (min && val < *min)) {
> > > > + err = -EINVAL;
> > > > + break;
> > > > + }
> > > > val = convmul * val / convdiv;
> > > > if ((min && val < *min) || (max && val > *max))
> > > > continue;
> > >
> > > This is a generic change which affects all users of
> > > do_proc_doulongvec_minmax() that have extra1 or extra2 set. In sysctl.c, I
> > > do not see another user of proc_doulongvec_minmax() that has extra1 or
> > > extra2 set. However, have you verified whether your patch changes the
> > > behaviour for other files that make use of proc_doulongvec_minmax() or
> > > proc_doulongvec_ms_jiffies_minmax(), and not only of the file-max sysctl?
> >
> > Sorry for the delayed reply. I did look at the callers. The functions
> > that are of interest afaict are:
> >
> > proc_doulongvec_ms_jiffies_minmax
> > proc_doulongvec_minmax
> >
> > So this could be visible when users write values that would overflow the
> > type used in the kernel.
> >
> > I guess your point is whether we are venturing into userspace break
> > territory. Hm... We should probably make sure that we're not regressing
> > anyone else! What do you think if instead of the above patch we did:
>
> Hm, I prefer the original patch -- as the same (valid) reasons which apply
> for the file-max sysctl might also apply to other users of this function
> where extra1 and/or2 extra2 are set.
In that case we should erorr out on:
val = convmul * val / convdiv;
if ((min && val < *min) || (max && val > *max)) {
err = -EINVAL;
break;
}
I fear that erroring out before might break *_jiffies since they are the
only caller that request a convmul/convdiv value that is not 1l.
Christian
^ permalink raw reply
* [PATCH 00/15] arch: synchronize syscall tables in preparation for y2038
From: Arnd Bergmann @ 2019-01-10 16:24 UTC (permalink / raw)
To: y2038, linux-api, linux-kernel
Cc: Arnd Bergmann, ink, mattst88, linux, catalin.marinas, will.deacon,
tony.luck, fenghua.yu, geert, monstr, paul.burton, deller, mpe,
schwidefsky, heiko.carstens, dalias, davem, luto, tglx, mingo,
hpa, x86, jcmvbkbc, firoz.khan, ebiederm, deepa.kernel, linux,
akpm, dave, linux-alpha, linux-arm-kernel, linux-ia64, linux-m68k,
linux-mips, linux-paris
The system call tables have diverged a bit over the years, and a number
of the recent additions never made it into all architectures, for one
reason or another.
This is an attempt to clean it up as far as we can without breaking
compatibility, doing a number of steps:
- Add system calls that have not yet been integrated into all
architectures but that we definitely want there.
- Add the separate ipc syscalls on all architectures that
traditionally only had sys_ipc(). This version is done without
support for IPC_OLD that is we have in sys_ipc. The
new semtimedop_time64 syscall will only be added here, not
in sys_ipc
- Add syscall numbers for a couple of syscalls that we probably
don't need everywhere, in particular pkey_* and rseq,
for the purpose of symmetry: if it's in asm-generic/unistd.h,
it makes sense to have it everywhere.
- Prepare for having the same system call numbers for any future
calls. In combination with the generated tables, this hopefully
makes it easier to add new calls across all architectures
together.
Most of the contents of this series are unrelated to the actual
y2038 work, but for the moment, that second series is based on
this one. If there are any concerns about changes here, I
can drop or rewrite any individual patch in this series.
My plan is to merge any patches in this series that are found
to be good together with the y2038 patches for linux-5.1, so
please review and provide Acks for merging through my tree,
or pick them up for 5.0 if they seem urgent enough.
Arnd
Arnd Bergmann (15):
ia64: add __NR_umount2 definition
ia64: add statx and io_pgetevents syscalls
ia64: assign syscall numbers for perf and seccomp
alpha: wire up io_pgetevents system call
alpha: update syscall macro definitions
ARM: add migrate_pages() system call
ARM: add kexec_file_load system call number
m68k: assign syscall number for seccomp
sh: remove duplicate unistd_32.h file
sh: add statx system call
mips: fix n32 compat_ipc_parse_version
sparc64: fix sparc_ipc type conversion
ipc: rename old-style shmctl/semctl/msgctl syscalls
arch: add split IPC system calls where needed
arch: add pkey and rseq syscall numbers everywhere
arch/alpha/include/asm/unistd.h | 10 -
arch/alpha/include/uapi/asm/unistd.h | 5 +
arch/alpha/kernel/syscalls/syscall.tbl | 15 +-
arch/arm/include/asm/unistd.h | 1 -
arch/arm/tools/syscall.tbl | 8 +-
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 10 +-
arch/ia64/include/asm/unistd.h | 14 -
arch/ia64/include/uapi/asm/unistd.h | 2 +
arch/ia64/kernel/syscalls/syscall.tbl | 10 +-
arch/m68k/kernel/syscalls/syscall.tbl | 16 +
arch/microblaze/kernel/syscalls/syscall.tbl | 6 +-
arch/mips/Kconfig | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 6 +-
arch/mips/kernel/syscalls/syscall_n64.tbl | 6 +-
arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +
arch/parisc/include/asm/unistd.h | 3 -
arch/parisc/kernel/syscalls/syscall.tbl | 4 +
arch/powerpc/kernel/syscalls/syscall.tbl | 12 +
arch/s390/include/asm/unistd.h | 3 -
arch/s390/kernel/syscalls/syscall.tbl | 15 +
arch/sh/include/uapi/asm/unistd_32.h | 403 --------------------
arch/sh/kernel/syscalls/syscall.tbl | 16 +
arch/sparc/include/asm/unistd.h | 5 -
arch/sparc/kernel/sys_sparc_64.c | 2 +-
arch/sparc/kernel/syscalls/syscall.tbl | 16 +
arch/x86/entry/syscalls/syscall_32.tbl | 11 +
arch/xtensa/kernel/syscalls/syscall.tbl | 7 +-
include/linux/syscalls.h | 3 +
ipc/msg.c | 39 +-
ipc/sem.c | 39 +-
ipc/shm.c | 40 +-
ipc/syscall.c | 12 +-
ipc/util.h | 21 +-
kernel/sys_ni.c | 3 +
35 files changed, 271 insertions(+), 506 deletions(-)
delete mode 100644 arch/sh/include/uapi/asm/unistd_32.h
--
2.20.0
Cc: ink@jurassic.park.msu.ru
Cc: mattst88@gmail.com
Cc: linux@armlinux.org.uk
Cc: catalin.marinas@arm.com
Cc: will.deacon@arm.com
Cc: tony.luck@intel.com
Cc: fenghua.yu@intel.com
Cc: geert@linux-m68k.org
Cc: monstr@monstr.eu
Cc: paul.burton@mips.com
Cc: deller@gmx.de
Cc: mpe@ellerman.id.au
Cc: schwidefsky@de.ibm.com
Cc: heiko.carstens@de.ibm.com
Cc: dalias@libc.org
Cc: davem@davemloft.net
Cc: luto@kernel.org
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: x86@kernel.org
Cc: jcmvbkbc@gmail.com
Cc: arnd@arndb.de
Cc: firoz.khan@linaro.org
Cc: ebiederm@xmission.com
Cc: deepa.kernel@gmail.com
Cc: linux@dominikbrodowski.net
Cc: akpm@linux-foundation.org
Cc: dave@stgolabs.net
Cc: linux-alpha@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-ia64@vger.kernel.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-mips@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: linux-api@vger.kernel.org
CC: y2038@lists.linaro.org
^ permalink raw reply
* [PATCH 01/15] ia64: add __NR_umount2 definition
From: Arnd Bergmann @ 2019-01-10 16:24 UTC (permalink / raw)
To: y2038, linux-api, linux-kernel
Cc: dalias, linux-ia64, linux-sh, catalin.marinas, will.deacon, linux,
jcmvbkbc, deepa.kernel, hpa, sparclinux, linux-s390, dave, mpe,
deller, x86, linux, mingo, geert, firoz.khan, mattst88,
fenghua.yu, Arnd Bergmann, heiko.carstens, linux-m68k, ink, luto,
tglx, linux-arm-kernel, monstr, tony.luck, linux-parisc,
linux-mips, paul.burton, ebiederm, linux-alpha, schwidefsky, akpm,
linuxppc-dev
In-Reply-To: <20190110162435.309262-1-arnd@arndb.de>
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
The __IGNORE_* lines are now all obsolete and can be removed as
a side-effect.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/ia64/include/asm/unistd.h | 14 --------------
arch/ia64/include/uapi/asm/unistd.h | 2 ++
arch/ia64/kernel/syscalls/syscall.tbl | 2 +-
3 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/arch/ia64/include/asm/unistd.h b/arch/ia64/include/asm/unistd.h
index 0b08ebd2dfde..9ba6110b10b9 100644
--- a/arch/ia64/include/asm/unistd.h
+++ b/arch/ia64/include/asm/unistd.h
@@ -12,20 +12,6 @@
#define NR_syscalls __NR_syscalls /* length of syscall table */
-/*
- * The following defines stop scripts/checksyscalls.sh from complaining about
- * unimplemented system calls. Glibc provides for each of these by using
- * more modern equivalent system calls.
- */
-#define __IGNORE_fork /* clone() */
-#define __IGNORE_time /* gettimeofday() */
-#define __IGNORE_alarm /* setitimer(ITIMER_REAL, ... */
-#define __IGNORE_pause /* rt_sigprocmask(), rt_sigsuspend() */
-#define __IGNORE_utime /* utimes() */
-#define __IGNORE_getpgrp /* getpgid() */
-#define __IGNORE_vfork /* clone() */
-#define __IGNORE_umount2 /* umount() */
-
#define __ARCH_WANT_NEW_STAT
#define __ARCH_WANT_SYS_UTIME
diff --git a/arch/ia64/include/uapi/asm/unistd.h b/arch/ia64/include/uapi/asm/unistd.h
index b2513922dcb5..013e0bcacc39 100644
--- a/arch/ia64/include/uapi/asm/unistd.h
+++ b/arch/ia64/include/uapi/asm/unistd.h
@@ -15,6 +15,8 @@
#define __NR_Linux 1024
+#define __NR_umount __NR_umount2
+
#include <asm/unistd_64.h>
#endif /* _UAPI_ASM_IA64_UNISTD_H */
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl b/arch/ia64/kernel/syscalls/syscall.tbl
index b22203b40bfe..e97caf51be42 100644
--- a/arch/ia64/kernel/syscalls/syscall.tbl
+++ b/arch/ia64/kernel/syscalls/syscall.tbl
@@ -29,7 +29,7 @@
17 common getpid sys_getpid
18 common getppid sys_getppid
19 common mount sys_mount
-20 common umount sys_umount
+20 common umount2 sys_umount
21 common setuid sys_setuid
22 common getuid sys_getuid
23 common geteuid sys_geteuid
--
2.20.0
^ permalink raw reply related
* [PATCH 02/15] ia64: add statx and io_pgetevents syscalls
From: Arnd Bergmann @ 2019-01-10 16:24 UTC (permalink / raw)
To: y2038, linux-api, linux-kernel
Cc: dalias, linux-ia64, linux-sh, catalin.marinas, will.deacon, linux,
jcmvbkbc, deepa.kernel, hpa, sparclinux, linux-s390, dave, mpe,
deller, x86, linux, mingo, geert, firoz.khan, mattst88,
fenghua.yu, Arnd Bergmann, heiko.carstens, linux-m68k, ink, luto,
tglx, linux-arm-kernel, monstr, tony.luck, linux-parisc,
linux-mips, paul.burton, ebiederm, linux-alpha, schwidefsky, akpm,
linuxppc-dev
In-Reply-To: <20190110162435.309262-1-arnd@arndb.de>
All architectures should implement these two, so assign numbers
and hook them up on ia64.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/ia64/kernel/syscalls/syscall.tbl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl b/arch/ia64/kernel/syscalls/syscall.tbl
index e97caf51be42..52585281205b 100644
--- a/arch/ia64/kernel/syscalls/syscall.tbl
+++ b/arch/ia64/kernel/syscalls/syscall.tbl
@@ -335,3 +335,5 @@
323 common copy_file_range sys_copy_file_range
324 common preadv2 sys_preadv2
325 common pwritev2 sys_pwritev2
+326 common statx sys_statx
+327 common io_pgetevents sys_io_pgetevents
--
2.20.0
^ permalink raw reply related
* [PATCH 03/15] ia64: assign syscall numbers for perf and seccomp
From: Arnd Bergmann @ 2019-01-10 16:24 UTC (permalink / raw)
To: y2038, linux-api, linux-kernel
Cc: dalias, linux-ia64, linux-sh, catalin.marinas, will.deacon, linux,
jcmvbkbc, deepa.kernel, hpa, sparclinux, linux-s390, dave, mpe,
deller, x86, linux, mingo, geert, firoz.khan, mattst88,
fenghua.yu, Arnd Bergmann, heiko.carstens, linux-m68k, ink, luto,
tglx, linux-arm-kernel, monstr, tony.luck, linux-parisc,
linux-mips, paul.burton, ebiederm, linux-alpha, schwidefsky, akpm,
linuxppc-dev
In-Reply-To: <20190110162435.309262-1-arnd@arndb.de>
Most architectures have assigned numbers for both seccomp and
perf_event_open, even when they do not implement either.
ia64 is an exception here, so for consistency lets add numbers for both
of them. Unless CONFIG_PERF_EVENTS and CONFIG_SECCOMP are implemented,
the system calls just return -ENOSYS.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/ia64/kernel/syscalls/syscall.tbl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl b/arch/ia64/kernel/syscalls/syscall.tbl
index 52585281205b..2e93dbdcdb80 100644
--- a/arch/ia64/kernel/syscalls/syscall.tbl
+++ b/arch/ia64/kernel/syscalls/syscall.tbl
@@ -337,3 +337,5 @@
325 common pwritev2 sys_pwritev2
326 common statx sys_statx
327 common io_pgetevents sys_io_pgetevents
+328 common perf_event_open sys_perf_event_open
+329 common seccomp sys_seccomp
--
2.20.0
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply related
* [PATCH 04/15] alpha: wire up io_pgetevents system call
From: Arnd Bergmann @ 2019-01-10 16:24 UTC (permalink / raw)
To: y2038, linux-api, linux-kernel
Cc: Arnd Bergmann, ink, mattst88, linux, catalin.marinas, will.deacon,
tony.luck, fenghua.yu, geert, monstr, paul.burton, deller, mpe,
schwidefsky, heiko.carstens, dalias, davem, luto, tglx, mingo,
hpa, x86, jcmvbkbc, firoz.khan, ebiederm, deepa.kernel, linux,
akpm, dave, linux-alpha, linux-arm-kernel, linux-ia64, linux-m68k,
linux-mips, linux-paris
In-Reply-To: <20190110162435.309262-1-arnd@arndb.de>
The io_pgetevents system call was added in linux-4.18 but has
no entry for alpha:
warning: #warning syscall io_pgetevents not implemented [-Wcpp]
Assign a the next system call number here.
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl
index 7b56a53be5e3..e09558edae73 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -451,3 +451,4 @@
520 common preadv2 sys_preadv2
521 common pwritev2 sys_pwritev2
522 common statx sys_statx
+523 common io_pgetevents sys_io_pgetevents
--
2.20.0
^ permalink raw reply related
* [PATCH 05/15] alpha: update syscall macro definitions
From: Arnd Bergmann @ 2019-01-10 16:24 UTC (permalink / raw)
To: y2038, linux-api, linux-kernel
Cc: Arnd Bergmann, ink, mattst88, linux, catalin.marinas, will.deacon,
tony.luck, fenghua.yu, geert, monstr, paul.burton, deller, mpe,
schwidefsky, heiko.carstens, dalias, davem, luto, tglx, mingo,
hpa, x86, jcmvbkbc, firoz.khan, ebiederm, deepa.kernel, linux,
akpm, dave, linux-alpha, linux-arm-kernel, linux-ia64, linux-m68k,
linux-mips, linux-paris
In-Reply-To: <20190110162435.309262-1-arnd@arndb.de>
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
For shmat, alpha uses the osf_shmat name, we can do the same thing
here, which means we don't have to add an entry in the __IGNORE
list now that shmat is mandatory everywhere
alarm, creat, pause, time, and utime are optional everywhere
these days, no need to list them here any more.
I considered also adding the regular versions of the get*id system
calls that have different names and calling conventions on alpha,
which would further help unify the syscall ABI, but for now
I decided against that.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/alpha/include/asm/unistd.h | 6 ------
arch/alpha/include/uapi/asm/unistd.h | 5 +++++
arch/alpha/kernel/syscalls/syscall.tbl | 4 ++--
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/alpha/include/asm/unistd.h b/arch/alpha/include/asm/unistd.h
index 21b706a5b772..564ba87bdc38 100644
--- a/arch/alpha/include/asm/unistd.h
+++ b/arch/alpha/include/asm/unistd.h
@@ -22,18 +22,12 @@
/*
* Ignore legacy syscalls that we don't use.
*/
-#define __IGNORE_alarm
-#define __IGNORE_creat
#define __IGNORE_getegid
#define __IGNORE_geteuid
#define __IGNORE_getgid
#define __IGNORE_getpid
#define __IGNORE_getppid
#define __IGNORE_getuid
-#define __IGNORE_pause
-#define __IGNORE_time
-#define __IGNORE_utime
-#define __IGNORE_umount2
/* Alpha doesn't have protection keys. */
#define __IGNORE_pkey_mprotect
diff --git a/arch/alpha/include/uapi/asm/unistd.h b/arch/alpha/include/uapi/asm/unistd.h
index 9ba724f116f1..4507071f995f 100644
--- a/arch/alpha/include/uapi/asm/unistd.h
+++ b/arch/alpha/include/uapi/asm/unistd.h
@@ -2,6 +2,11 @@
#ifndef _UAPI_ALPHA_UNISTD_H
#define _UAPI_ALPHA_UNISTD_H
+/* These are traditionally the names linux-alpha uses for
+ * the two otherwise generic system calls */
+#define __NR_umount __NR_umount2
+#define __NR_osf_shmat __NR_shmat
+
#include <asm/unistd_32.h>
#endif /* _UAPI_ALPHA_UNISTD_H */
diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl
index e09558edae73..f920b65e8c49 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -29,7 +29,7 @@
19 common lseek sys_lseek
20 common getxpid sys_getxpid
21 common osf_mount sys_osf_mount
-22 common umount sys_umount
+22 common umount2 sys_umount
23 common setuid sys_setuid
24 common getxuid sys_getxuid
25 common exec_with_loader sys_ni_syscall
@@ -183,7 +183,7 @@
206 common semop sys_semop
207 common osf_utsname sys_osf_utsname
208 common lchown sys_lchown
-209 common osf_shmat sys_shmat
+209 common shmat sys_shmat
210 common shmctl sys_shmctl
211 common shmdt sys_shmdt
212 common shmget sys_shmget
--
2.20.0
^ permalink raw reply related
* [PATCH 06/15] ARM: add migrate_pages() system call
From: Arnd Bergmann @ 2019-01-10 16:24 UTC (permalink / raw)
To: y2038, linux-api, linux-kernel
Cc: dalias, linux-ia64, linux-sh, catalin.marinas, will.deacon, linux,
jcmvbkbc, deepa.kernel, hpa, sparclinux, linux-s390, dave, mpe,
deller, x86, linux, mingo, geert, firoz.khan, mattst88,
fenghua.yu, Arnd Bergmann, heiko.carstens, linux-m68k, ink, luto,
tglx, linux-arm-kernel, monstr, tony.luck, linux-parisc,
linux-mips, paul.burton, ebiederm, linux-alpha, schwidefsky, akpm,
linuxppc-dev
In-Reply-To: <20190110162435.309262-1-arnd@arndb.de>
The migrate_pages system call has an assigned number on all architectures
except ARM. When it got added initially in commit d80ade7b3231 ("ARM:
Fix warning: #warning syscall migrate_pages not implemented"), it was
intentionally left out based on the observation that there are no 32-bit
ARM NUMA systems.
However, there are now arm64 NUMA machines that can in theory run 32-bit
kernels (actually enabling NUMA there would require additional work)
as well as 32-bit user space on 64-bit kernels, so that argument is no
longer very strong.
Assigning the number lets us use the system call on 64-bit kernels as well
as providing a more consistent set of syscalls across architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/include/asm/unistd.h | 1 -
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 ++
4 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/unistd.h b/arch/arm/include/asm/unistd.h
index 88ef2ce1f69a..d713587dfcf4 100644
--- a/arch/arm/include/asm/unistd.h
+++ b/arch/arm/include/asm/unistd.h
@@ -45,7 +45,6 @@
* Unimplemented (or alternatively implemented) syscalls
*/
#define __IGNORE_fadvise64_64
-#define __IGNORE_migrate_pages
#ifdef __ARM_EABI__
/*
diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
index 8edf93b4490f..86de9eb34296 100644
--- a/arch/arm/tools/syscall.tbl
+++ b/arch/arm/tools/syscall.tbl
@@ -414,3 +414,4 @@
397 common statx sys_statx
398 common rseq sys_rseq
399 common io_pgetevents sys_io_pgetevents
+400 common migrate_pages sys_migrate_pages
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index a7b1fc58ffdf..261216c3336e 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -44,7 +44,7 @@
#define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE + 5)
#define __ARM_NR_COMPAT_END (__ARM_NR_COMPAT_BASE + 0x800)
-#define __NR_compat_syscalls 400
+#define __NR_compat_syscalls 401
#endif
#define __ARCH_WANT_SYS_CLONE
diff --git a/arch/arm64/include/asm/unistd32.h b/arch/arm64/include/asm/unistd32.h
index 04ee190b90fe..355fe2bc035b 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -821,6 +821,8 @@ __SYSCALL(__NR_statx, sys_statx)
__SYSCALL(__NR_rseq, sys_rseq)
#define __NR_io_pgetevents 399
__SYSCALL(__NR_io_pgetevents, compat_sys_io_pgetevents)
+#define __NR_migrate_pages 400
+__SYSCALL(__NR_migrate_pages, sys_migrate_pages)
/*
* Please add new compat syscalls above this comment and update
--
2.20.0
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox