[PATCH AUTOSEL 6.9 02/44] scsi: sr: Fix unintentional arithmetic wraparound

2024-06-18 Thread Sasha Levin 
From: Justin Stitt 

[ Upstream commit 9fad9d560af5c654bb38e0b07ee54a4e9acdc5cd ]

Running syzkaller with the newly reintroduced signed integer overflow
sanitizer produces this report:

[   65.194362] [ cut here ]
[   65.197752] UBSAN: signed-integer-overflow in 
../drivers/scsi/sr_ioctl.c:436:9
[   65.203607] -2147483648 * 177 cannot be represented in type 'int'
[   65.207911] CPU: 2 PID: 10416 Comm: syz-executor.1 Not tainted 
6.8.0-rc2-00035-gb3ef86b5a957 #1
[   65.213585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.16.3-debian-1.16.3-2 04/01/2014
[   65.219923] Call Trace:
[   65.221556]  
[   65.223029]  dump_stack_lvl+0x93/0xd0
[   65.225573]  handle_overflow+0x171/0x1b0
[   65.228219]  sr_select_speed+0xeb/0xf0
[   65.230786]  ? __pm_runtime_resume+0xe6/0x130
[   65.233606]  sr_block_ioctl+0x15d/0x1d0
...

Historically, the signed integer overflow sanitizer did not work in the
kernel due to its interaction with `-fwrapv` but this has since been
changed [1] in the newest version of Clang. It was re-enabled in the kernel
with Commit 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer").

Firstly, let's change the type of "speed" to unsigned long as
sr_select_speed()'s only caller passes in an unsigned long anyways.

$ git grep '\.select_speed'
|   drivers/scsi/sr.c:  .select_speed   = sr_select_speed,
...
|   static int cdrom_ioctl_select_speed(struct cdrom_device_info *cdi,
|   unsigned long arg)
|   {
|   ...
|   return cdi->ops->select_speed(cdi, arg);
|   }

Next, let's add an extra check to make sure we don't exceed 0x/177
(350) since 0x is the max speed. This has two benefits: 1) we deal
with integer overflow before it happens and 2) we properly respect the
max speed of 0x. There are some "magic" numbers here but I did not
want to change more than what was necessary.

Link: https://github.com/llvm/llvm-project/pull/82432 [1]
Closes: https://github.com/KSPP/linux/issues/357
Cc: linux-harden...@vger.kernel.org
Signed-off-by: Justin Stitt 
Link: 
https://lore.kernel.org/r/20240508-b4-b4-sio-sr_select_speed-v2-1-00b68f724...@google.com
Reviewed-by: Kees Cook 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 Documentation/cdrom/cdrom-standard.rst | 4 ++--
 drivers/scsi/sr.h  | 2 +-
 drivers/scsi/sr_ioctl.c| 5 -
 include/linux/cdrom.h  | 2 +-
 4 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/cdrom/cdrom-standard.rst 
b/Documentation/cdrom/cdrom-standard.rst
index 7964fe134277b..6c1303cff159e 100644
--- a/Documentation/cdrom/cdrom-standard.rst
+++ b/Documentation/cdrom/cdrom-standard.rst
@@ -217,7 +217,7 @@ current *struct* is::
int (*media_changed)(struct cdrom_device_info *, int);
int (*tray_move)(struct cdrom_device_info *, int);
int (*lock_door)(struct cdrom_device_info *, int);
-   int (*select_speed)(struct cdrom_device_info *, int);
+   int (*select_speed)(struct cdrom_device_info *, unsigned long);
int (*get_last_session) (struct cdrom_device_info *,
 struct cdrom_multisession *);
int (*get_mcn)(struct cdrom_device_info *, struct cdrom_mcn *);
@@ -396,7 +396,7 @@ action need be taken, and the return value should be 0.
 
 ::
 
-   int select_speed(struct cdrom_device_info *cdi, int speed)
+   int select_speed(struct cdrom_device_info *cdi, unsigned long speed)
 
 Some CD-ROM drives are capable of changing their head-speed. There
 are several reasons for changing the speed of a CD-ROM drive. Badly
diff --git a/drivers/scsi/sr.h b/drivers/scsi/sr.h
index 1175f2e213b56..dc899277b3a44 100644
--- a/drivers/scsi/sr.h
+++ b/drivers/scsi/sr.h
@@ -65,7 +65,7 @@ int sr_disk_status(struct cdrom_device_info *);
 int sr_get_last_session(struct cdrom_device_info *, struct cdrom_multisession 
*);
 int sr_get_mcn(struct cdrom_device_info *, struct cdrom_mcn *);
 int sr_reset(struct cdrom_device_info *);
-int sr_select_speed(struct cdrom_device_info *cdi, int speed);
+int sr_select_speed(struct cdrom_device_info *cdi, unsigned long speed);
 int sr_audio_ioctl(struct cdrom_device_info *, unsigned int, void *);
 
 int sr_is_xa(Scsi_CD *);
diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c
index 5b0b35e60e61f..a0d2556a27bba 100644
--- a/drivers/scsi/sr_ioctl.c
+++ b/drivers/scsi/sr_ioctl.c
@@ -425,11 +425,14 @@ int sr_reset(struct cdrom_device_info *cdi)
return 0;
 }
 
-int sr_select_speed(struct cdrom_device_info *cdi, int speed)
+int sr_select_speed(struct cdrom_device_info *cdi, unsigned long speed)
 {
Scsi_CD *cd = cdi->handle;
struct packet_command cgc;
 
+   /* avoid exceeding the max speed or overflowing integer bounds */
+   speed = clamp(0, speed, 0x / 177);
+
if (spee

[PATCH AUTOSEL 6.6 02/35] scsi: sr: Fix unintentional arithmetic wraparound

2024-06-18 Thread Sasha Levin 
From: Justin Stitt 

[ Upstream commit 9fad9d560af5c654bb38e0b07ee54a4e9acdc5cd ]

Running syzkaller with the newly reintroduced signed integer overflow
sanitizer produces this report:

[   65.194362] [ cut here ]
[   65.197752] UBSAN: signed-integer-overflow in 
../drivers/scsi/sr_ioctl.c:436:9
[   65.203607] -2147483648 * 177 cannot be represented in type 'int'
[   65.207911] CPU: 2 PID: 10416 Comm: syz-executor.1 Not tainted 
6.8.0-rc2-00035-gb3ef86b5a957 #1
[   65.213585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.16.3-debian-1.16.3-2 04/01/2014
[   65.219923] Call Trace:
[   65.221556]  
[   65.223029]  dump_stack_lvl+0x93/0xd0
[   65.225573]  handle_overflow+0x171/0x1b0
[   65.228219]  sr_select_speed+0xeb/0xf0
[   65.230786]  ? __pm_runtime_resume+0xe6/0x130
[   65.233606]  sr_block_ioctl+0x15d/0x1d0
...

Historically, the signed integer overflow sanitizer did not work in the
kernel due to its interaction with `-fwrapv` but this has since been
changed [1] in the newest version of Clang. It was re-enabled in the kernel
with Commit 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer").

Firstly, let's change the type of "speed" to unsigned long as
sr_select_speed()'s only caller passes in an unsigned long anyways.

$ git grep '\.select_speed'
|   drivers/scsi/sr.c:  .select_speed   = sr_select_speed,
...
|   static int cdrom_ioctl_select_speed(struct cdrom_device_info *cdi,
|   unsigned long arg)
|   {
|   ...
|   return cdi->ops->select_speed(cdi, arg);
|   }

Next, let's add an extra check to make sure we don't exceed 0x/177
(350) since 0x is the max speed. This has two benefits: 1) we deal
with integer overflow before it happens and 2) we properly respect the
max speed of 0x. There are some "magic" numbers here but I did not
want to change more than what was necessary.

Link: https://github.com/llvm/llvm-project/pull/82432 [1]
Closes: https://github.com/KSPP/linux/issues/357
Cc: linux-harden...@vger.kernel.org
Signed-off-by: Justin Stitt 
Link: 
https://lore.kernel.org/r/20240508-b4-b4-sio-sr_select_speed-v2-1-00b68f724...@google.com
Reviewed-by: Kees Cook 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 Documentation/cdrom/cdrom-standard.rst | 4 ++--
 drivers/scsi/sr.h  | 2 +-
 drivers/scsi/sr_ioctl.c| 5 -
 include/linux/cdrom.h  | 2 +-
 4 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/cdrom/cdrom-standard.rst 
b/Documentation/cdrom/cdrom-standard.rst
index 7964fe134277b..6c1303cff159e 100644
--- a/Documentation/cdrom/cdrom-standard.rst
+++ b/Documentation/cdrom/cdrom-standard.rst
@@ -217,7 +217,7 @@ current *struct* is::
int (*media_changed)(struct cdrom_device_info *, int);
int (*tray_move)(struct cdrom_device_info *, int);
int (*lock_door)(struct cdrom_device_info *, int);
-   int (*select_speed)(struct cdrom_device_info *, int);
+   int (*select_speed)(struct cdrom_device_info *, unsigned long);
int (*get_last_session) (struct cdrom_device_info *,
 struct cdrom_multisession *);
int (*get_mcn)(struct cdrom_device_info *, struct cdrom_mcn *);
@@ -396,7 +396,7 @@ action need be taken, and the return value should be 0.
 
 ::
 
-   int select_speed(struct cdrom_device_info *cdi, int speed)
+   int select_speed(struct cdrom_device_info *cdi, unsigned long speed)
 
 Some CD-ROM drives are capable of changing their head-speed. There
 are several reasons for changing the speed of a CD-ROM drive. Badly
diff --git a/drivers/scsi/sr.h b/drivers/scsi/sr.h
index 1175f2e213b56..dc899277b3a44 100644
--- a/drivers/scsi/sr.h
+++ b/drivers/scsi/sr.h
@@ -65,7 +65,7 @@ int sr_disk_status(struct cdrom_device_info *);
 int sr_get_last_session(struct cdrom_device_info *, struct cdrom_multisession 
*);
 int sr_get_mcn(struct cdrom_device_info *, struct cdrom_mcn *);
 int sr_reset(struct cdrom_device_info *);
-int sr_select_speed(struct cdrom_device_info *cdi, int speed);
+int sr_select_speed(struct cdrom_device_info *cdi, unsigned long speed);
 int sr_audio_ioctl(struct cdrom_device_info *, unsigned int, void *);
 
 int sr_is_xa(Scsi_CD *);
diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c
index 5b0b35e60e61f..a0d2556a27bba 100644
--- a/drivers/scsi/sr_ioctl.c
+++ b/drivers/scsi/sr_ioctl.c
@@ -425,11 +425,14 @@ int sr_reset(struct cdrom_device_info *cdi)
return 0;
 }
 
-int sr_select_speed(struct cdrom_device_info *cdi, int speed)
+int sr_select_speed(struct cdrom_device_info *cdi, unsigned long speed)
 {
Scsi_CD *cd = cdi->handle;
struct packet_command cgc;
 
+   /* avoid exceeding the max speed or overflowing integer bounds */
+   speed = clamp(0, speed, 0x / 177);
+
if (spee

[PATCH AUTOSEL 6.1 02/29] scsi: sr: Fix unintentional arithmetic wraparound

2024-06-18 Thread Sasha Levin 
From: Justin Stitt 

[ Upstream commit 9fad9d560af5c654bb38e0b07ee54a4e9acdc5cd ]

Running syzkaller with the newly reintroduced signed integer overflow
sanitizer produces this report:

[   65.194362] [ cut here ]
[   65.197752] UBSAN: signed-integer-overflow in 
../drivers/scsi/sr_ioctl.c:436:9
[   65.203607] -2147483648 * 177 cannot be represented in type 'int'
[   65.207911] CPU: 2 PID: 10416 Comm: syz-executor.1 Not tainted 
6.8.0-rc2-00035-gb3ef86b5a957 #1
[   65.213585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.16.3-debian-1.16.3-2 04/01/2014
[   65.219923] Call Trace:
[   65.221556]  
[   65.223029]  dump_stack_lvl+0x93/0xd0
[   65.225573]  handle_overflow+0x171/0x1b0
[   65.228219]  sr_select_speed+0xeb/0xf0
[   65.230786]  ? __pm_runtime_resume+0xe6/0x130
[   65.233606]  sr_block_ioctl+0x15d/0x1d0
...

Historically, the signed integer overflow sanitizer did not work in the
kernel due to its interaction with `-fwrapv` but this has since been
changed [1] in the newest version of Clang. It was re-enabled in the kernel
with Commit 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer").

Firstly, let's change the type of "speed" to unsigned long as
sr_select_speed()'s only caller passes in an unsigned long anyways.

$ git grep '\.select_speed'
|   drivers/scsi/sr.c:  .select_speed   = sr_select_speed,
...
|   static int cdrom_ioctl_select_speed(struct cdrom_device_info *cdi,
|   unsigned long arg)
|   {
|   ...
|   return cdi->ops->select_speed(cdi, arg);
|   }

Next, let's add an extra check to make sure we don't exceed 0x/177
(350) since 0x is the max speed. This has two benefits: 1) we deal
with integer overflow before it happens and 2) we properly respect the
max speed of 0x. There are some "magic" numbers here but I did not
want to change more than what was necessary.

Link: https://github.com/llvm/llvm-project/pull/82432 [1]
Closes: https://github.com/KSPP/linux/issues/357
Cc: linux-harden...@vger.kernel.org
Signed-off-by: Justin Stitt 
Link: 
https://lore.kernel.org/r/20240508-b4-b4-sio-sr_select_speed-v2-1-00b68f724...@google.com
Reviewed-by: Kees Cook 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 Documentation/cdrom/cdrom-standard.rst | 4 ++--
 drivers/scsi/sr.h  | 2 +-
 drivers/scsi/sr_ioctl.c| 5 -
 include/linux/cdrom.h  | 2 +-
 4 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/cdrom/cdrom-standard.rst 
b/Documentation/cdrom/cdrom-standard.rst
index 7964fe134277b..6c1303cff159e 100644
--- a/Documentation/cdrom/cdrom-standard.rst
+++ b/Documentation/cdrom/cdrom-standard.rst
@@ -217,7 +217,7 @@ current *struct* is::
int (*media_changed)(struct cdrom_device_info *, int);
int (*tray_move)(struct cdrom_device_info *, int);
int (*lock_door)(struct cdrom_device_info *, int);
-   int (*select_speed)(struct cdrom_device_info *, int);
+   int (*select_speed)(struct cdrom_device_info *, unsigned long);
int (*get_last_session) (struct cdrom_device_info *,
 struct cdrom_multisession *);
int (*get_mcn)(struct cdrom_device_info *, struct cdrom_mcn *);
@@ -396,7 +396,7 @@ action need be taken, and the return value should be 0.
 
 ::
 
-   int select_speed(struct cdrom_device_info *cdi, int speed)
+   int select_speed(struct cdrom_device_info *cdi, unsigned long speed)
 
 Some CD-ROM drives are capable of changing their head-speed. There
 are several reasons for changing the speed of a CD-ROM drive. Badly
diff --git a/drivers/scsi/sr.h b/drivers/scsi/sr.h
index 1175f2e213b56..dc899277b3a44 100644
--- a/drivers/scsi/sr.h
+++ b/drivers/scsi/sr.h
@@ -65,7 +65,7 @@ int sr_disk_status(struct cdrom_device_info *);
 int sr_get_last_session(struct cdrom_device_info *, struct cdrom_multisession 
*);
 int sr_get_mcn(struct cdrom_device_info *, struct cdrom_mcn *);
 int sr_reset(struct cdrom_device_info *);
-int sr_select_speed(struct cdrom_device_info *cdi, int speed);
+int sr_select_speed(struct cdrom_device_info *cdi, unsigned long speed);
 int sr_audio_ioctl(struct cdrom_device_info *, unsigned int, void *);
 
 int sr_is_xa(Scsi_CD *);
diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c
index fbdb5124d7f7d..7034b4126d421 100644
--- a/drivers/scsi/sr_ioctl.c
+++ b/drivers/scsi/sr_ioctl.c
@@ -422,11 +422,14 @@ int sr_reset(struct cdrom_device_info *cdi)
return 0;
 }
 
-int sr_select_speed(struct cdrom_device_info *cdi, int speed)
+int sr_select_speed(struct cdrom_device_info *cdi, unsigned long speed)
 {
Scsi_CD *cd = cdi->handle;
struct packet_command cgc;
 
+   /* avoid exceeding the max speed or overflowing integer bounds */
+   speed = clamp(0, speed, 0x / 177);
+
if (spee

[PATCH 0/2] Documentation: update information for mailing lists

2024-06-18 Thread Konstantin Ryabitsev 
There have been some important changes to the mailing lists hosted at
kernel.org, most importantly that vger.kernel.org was migrated from
majordomo+zmailer to mlmmj and is now being served from the unified
mailing list platform called "subspace" [1].

This series updates many links pointing at obsolete locations, but also
makes the following changes:

- drops the recommendation to use /r/ subpaths in lore.kernel.org links
(it has been unnecessary for a number of years)
- adds some detail on how to reference specific Link trailers from
inside the commit message

Some of these changes are the result of discussions on the ksummit
mailing list [2].

Link: https://subspace.kernel.org # [1]
Link: 
https://lore.kernel.org/20240617-arboreal-industrious-hedgehog-5b84ae@meerkat/ 
# [2]
Signed-off-by: Konstantin Ryabitsev 
---
Konstantin Ryabitsev (2):
  Documentation: fix links to mailing list services
  Documentation: best practices for using Link trailers

 Documentation/process/2.Process.rst  |  8 
 Documentation/process/howto.rst  | 10 +-
 Documentation/process/kernel-docs.rst|  5 ++---
 Documentation/process/maintainer-netdev.rst  |  5 ++---
 Documentation/process/maintainer-tip.rst | 24 ++--
 Documentation/process/submitting-patches.rst | 15 +--
 6 files changed, 36 insertions(+), 31 deletions(-)
---
base-commit: 6ba59ff4227927d3a8530fc2973b80e94b54d58f
change-id: 20240618-docs-patch-msgid-link-6961045516e0

Best regards,
-- 
Konstantin Ryabitsev

[PATCH 2/2] Documentation: best practices for using Link trailers

2024-06-18 Thread Konstantin Ryabitsev 
Based on multiple conversations, most recently on the ksummit mailing
list [1], add some best practices for using the Link trailer, such as:

- how to use markdown-like bracketed numbers in the commit message to
indicate the corresponding link
- when to use lore.kernel.org vs patch.msgid.link domains

Cc: ksum...@lists.linux.dev
Link: 
https://lore.kernel.org/20240617-arboreal-industrious-hedgehog-5b84ae@meerkat # 
[1]
Signed-off-by: Konstantin Ryabitsev 
---
 Documentation/process/maintainer-tip.rst | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/Documentation/process/maintainer-tip.rst 
b/Documentation/process/maintainer-tip.rst
index 64739968afa6..57ffa553c21e 100644
--- a/Documentation/process/maintainer-tip.rst
+++ b/Documentation/process/maintainer-tip.rst
@@ -375,14 +375,26 @@ following tag ordering scheme:
For referring to an email on LKML or other kernel mailing lists,
please use the lore.kernel.org redirector URL::
 
- https://lore.kernel.org/r/email-message@id
+ Link: https://lore.kernel.org/email-message@id
 
-   The kernel.org redirector is considered a stable URL, unlike other email
-   archives.
+   This URL should be used when referring to relevant mailing list
+   resources, related patch sets, or other notable discussion threads.
+   A convenient way to associate Link trailers with the accompanying
+   message is to use markdown-like bracketed notation, for example::
 
-   Maintainers will add a Link tag referencing the email of the patch
-   submission when they apply a patch to the tip tree. This tag is useful
-   for later reference and is also used for commit notifications.
+ A similar approach was attempted before as part of a different
+ effort [1], but the initial implementation caused too many
+ regressions [2], so it was backed out and reimplemented.
+
+ Link: https://lore.kernel.org/some-msgid@here # [1]
+ Link: https://bugzilla.example.org/bug/12345  # [2]
+
+   When using the ``Link:`` trailer to indicate the provenance of the
+   patch, you should use the dedicated ``patch.msgid.link`` domain. This
+   makes it possible for automated tooling to establish which link leads
+   to the original patch submission. For example::
+
+ Link: https://patch.msgid.link/patch-source-msgid@here
 
 Please do not use combined tags, e.g. ``Reported-and-tested-by``, as
 they just complicate automated extraction of tags.

-- 
2.45.2

[PATCH 1/2] Documentation: fix links to mailing list services

2024-06-18 Thread Konstantin Ryabitsev 
There have been some changes to the way mailing lists are hosted at
kernel.org, so fix the links that are pointing at the outdated
resources.

Signed-off-by: Konstantin Ryabitsev 
---
 Documentation/process/2.Process.rst  |  8 
 Documentation/process/howto.rst  | 10 +-
 Documentation/process/kernel-docs.rst|  5 ++---
 Documentation/process/maintainer-netdev.rst  |  5 ++---
 Documentation/process/submitting-patches.rst | 15 +--
 5 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/Documentation/process/2.Process.rst 
b/Documentation/process/2.Process.rst
index 613a01da4717..ef3b116492df 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -392,13 +392,13 @@ represent a potential hazard to developers, who risk 
getting buried under a
 load of electronic mail, running afoul of the conventions used on the Linux
 lists, or both.
 
-Most kernel mailing lists are run on vger.kernel.org; the master list can
+Most kernel mailing lists are hosted at kernel.org; the master list can
 be found at:
 
-   http://vger.kernel.org/vger-lists.html
+   https://subspace.kernel.org
 
-There are lists hosted elsewhere, though; a number of them are at
-redhat.com/mailman/listinfo.
+There are lists hosted elsewhere; please check the MAINTAINERS file for
+the list relevant for any particular subsystem.
 
 The core mailing list for kernel development is, of course, linux-kernel.
 This list is an intimidating place to be; volume can reach 500 messages per
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index eebda4910a88..9438e03d6f50 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -331,7 +331,7 @@ they need to be integration-tested.  For this purpose, a 
special
 testing repository exists into which virtually all subsystem trees are
 pulled on an almost daily basis:
 
-   https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
+   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
 
 This way, the linux-next gives a summary outlook onto what will be
 expected to go into the mainline kernel at the next merge period.
@@ -373,12 +373,12 @@ As some of the above documents describe, the majority of 
the core kernel
 developers participate on the Linux Kernel Mailing list.  Details on how
 to subscribe and unsubscribe from the list can be found at:
 
-   http://vger.kernel.org/vger-lists.html#linux-kernel
+   https://subspace.kernel.org/subscribing.html
 
 There are archives of the mailing list on the web in many different
 places.  Use a search engine to find these archives.  For example:
 
-   https://lore.kernel.org/lkml/
+   https://lore.kernel.org/linux-kernel/
 
 It is highly recommended that you search the archives about the topic
 you want to bring up, before you post it to the list. A lot of things
@@ -393,13 +393,13 @@ groups.
 Many of the lists are hosted on kernel.org. Information on them can be
 found at:
 
-   http://vger.kernel.org/vger-lists.html
+   https://subspace.kernel.org
 
 Please remember to follow good behavioral habits when using the lists.
 Though a bit cheesy, the following URL has some simple guidelines for
 interacting with the list (or any list):
 
-   http://www.albion.com/netiquette/
+   https://subspace.kernel.org/etiquette.html
 
 If multiple people respond to your mail, the CC: list of recipients may
 get pretty large. Don't remove anybody from the CC: list without a good
diff --git a/Documentation/process/kernel-docs.rst 
b/Documentation/process/kernel-docs.rst
index 8660493b91d0..3476fb854c7a 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -194,9 +194,8 @@ Miscellaneous
 
 * Name: **linux-kernel mailing list archives and search engines**
 
-  :URL: http://vger.kernel.org/vger-lists.html
-  :URL: http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html
-  :URL: http://groups.google.com/group/mlist.linux.kernel
+  :URL: https://subspace.kernel.org
+  :URL: https://lore.kernel.org
   :Keywords: linux-kernel, archives, search.
   :Description: Some of the linux-kernel mailing list archivers. If
 you have a better/another one, please let me know.
diff --git a/Documentation/process/maintainer-netdev.rst 
b/Documentation/process/maintainer-netdev.rst
index 5e1fcfad1c4c..fe8616397d63 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -25,9 +25,8 @@ drivers/net (i.e. hardware specific drivers) in the Linux 
source tree.
 Note that some subsystems (e.g. wireless drivers) which have a high
 volume of traffic have their own specific mailing lists and trees.
 
-The netdev list is managed (like many other Linux mailing lists) through
-VGER (http://vger.kernel.org/) with archives available at
-https://lore.kernel.org/net

[PATCH v2 1/1] Documentation: hyperv: Add overview of Confidential Computing VM support

2024-06-18 Thread mhkelley58 
From: Michael Kelley 

Add documentation topic for Confidential Computing (CoCo) VM support
in Linux guests on Hyper-V.

Signed-off-by: Michael Kelley 
---
Changes in v2:
* Added hyperlink to Coconut github project

 Documentation/virt/hyperv/coco.rst  | 260 
 Documentation/virt/hyperv/index.rst |   1 +
 2 files changed, 261 insertions(+)
 create mode 100644 Documentation/virt/hyperv/coco.rst

diff --git a/Documentation/virt/hyperv/coco.rst 
b/Documentation/virt/hyperv/coco.rst
new file mode 100644
index ..c15d6fe34b4e
--- /dev/null
+++ b/Documentation/virt/hyperv/coco.rst
@@ -0,0 +1,260 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Confidential Computing VMs
+==
+Hyper-V can create and run Linux guests that are Confidential Computing
+(CoCo) VMs. Such VMs cooperate with the physical processor to better protect
+the confidentiality and integrity of data in the VM's memory, even in the
+face of a hypervisor/VMM that has been compromised and may behave maliciously.
+CoCo VMs on Hyper-V share the generic CoCo VM threat model and security
+objectives described in Documentation/security/snp-tdx-threat-model.rst. Note
+that Hyper-V specific code in Linux refers to CoCo VMs as "isolated VMs" or
+"isolation VMs".
+
+A Linux CoCo VM on Hyper-V requires the cooperation and interaction of the
+following:
+
+* Physical hardware with a processor that supports CoCo VMs
+
+* The hardware runs a version of Windows/Hyper-V with support for CoCo VMs
+
+* The VM runs a version of Linux that supports being a CoCo VM
+
+The physical hardware requirements are as follows:
+
+* AMD processor with SEV-SNP. Hyper-V does not run guest VMs with AMD SME,
+  SEV, or SEV-ES encryption, and such encryption is not sufficient for a CoCo
+  VM on Hyper-V.
+
+* Intel processor with TDX
+
+To create a CoCo VM, the "Isolated VM" attribute must be specified to Hyper-V
+when the VM is created. A VM cannot be changed from a CoCo VM to a normal VM,
+or vice versa, after it is created.
+
+Operational Modes
+-
+Hyper-V CoCo VMs can run in two modes. The mode is selected when the VM is
+created and cannot be changed during the life of the VM.
+
+* Fully-enlightened mode. In this mode, the guest operating system is
+  enlightened to understand and manage all aspects of running as a CoCo VM.
+
+* Paravisor mode. In this mode, a paravisor layer between the guest and the
+  host provides some operations needed to run as a CoCo VM. The guest operating
+  system can have fewer CoCo enlightenments than is required in the
+  fully-enlightened case.
+
+Conceptually, fully-enlightened mode and paravisor mode may be treated as
+points on a spectrum spanning the degree of guest enlightenment needed to run
+as a CoCo VM. Fully-enlightened mode is one end of the spectrum. A full
+implementation of paravisor mode is the other end of the spectrum, where all
+aspects of running as a CoCo VM are handled by the paravisor, and a normal
+guest OS with no knowledge of memory encryption or other aspects of CoCo VMs
+can run successfully. However, the Hyper-V implementation of paravisor mode
+does not go this far, and is somewhere in the middle of the spectrum. Some
+aspects of CoCo VMs are handled by the Hyper-V paravisor while the guest OS
+must be enlightened for other aspects. Unfortunately, there is no
+standardized enumeration of feature/functions that might be provided in the
+paravisor, and there is no standardized mechanism for a guest OS to query the
+paravisor for the feature/functions it provides. The understanding of what
+the paravisor provides is hard-coded in the guest OS.
+
+Paravisor mode has similarities to the `Coconut project`_, which aims to 
provide
+a limited paravisor to provide services to the guest such as a virtual TPM.
+However, the Hyper-V paravisor generally handles more aspects of CoCo VMs
+than is currently envisioned for Coconut, and so is further toward the "no
+guest enlightenments required" end of the spectrum.
+
+.. _Coconut project: https://github.com/coconut-svsm/svsm
+
+In the CoCo VM threat model, the paravisor is in the guest security domain
+and must be trusted by the guest OS. By implication, the hypervisor/VMM must
+protect itself against a potentially malicious paravisor just like it
+protects against a potentially malicious guest.
+
+The hardware architectural approach to fully-enlightened vs. paravisor mode
+varies depending on the underlying processor.
+
+* With AMD SEV-SNP processors, in fully-enlightened mode the guest OS runs in
+  VMPL 0 and has full control of the guest context. In paravisor mode, the
+  guest OS runs in VMPL 2 and the paravisor runs in VMPL 0. The paravisor
+  running in VMPL 0 has privileges that the guest OS in VMPL 2 does not have.
+  Certain operations require the guest to invoke the paravisor. Furthermore, in
+  paravisor mode the guest OS operates in "virtual Top Of Memory" (vTOM) mode
+  as defined by the SEV-SNP archit

Re: [PATCH v2 1/1] Documentation: hyperv: Add overview of Confidential Computing VM support

2024-06-18 Thread Easwar Hariharan 
On 6/18/2024 9:50 AM, mhkelle...@gmail.com wrote:
> From: Michael Kelley 
> 
> Add documentation topic for Confidential Computing (CoCo) VM support
> in Linux guests on Hyper-V.
> 
> Signed-off-by: Michael Kelley 
> ---
> Changes in v2:
> * Added hyperlink to Coconut github project
> 
>  Documentation/virt/hyperv/coco.rst  | 260 
>  Documentation/virt/hyperv/index.rst |   1 +
>  2 files changed, 261 insertions(+)
>  create mode 100644 Documentation/virt/hyperv/coco.rst
>

Looks good to me.

Reviewed-by: Easwar Hariharan

Re: [PATCH 1/2] Documentation: fix links to mailing list services

2024-06-18 Thread Dan Williams 
Konstantin Ryabitsev wrote:
> There have been some changes to the way mailing lists are hosted at
> kernel.org, so fix the links that are pointing at the outdated
> resources.

The change to the documented policy about patch-bombs probably deserves
a mention here even though it has been effectively ignored for a while.

Otherwise,

Acked-by: Dan Williams 

[..]
> diff --git a/Documentation/process/maintainer-netdev.rst 
> b/Documentation/process/maintainer-netdev.rst
> index 5e1fcfad1c4c..fe8616397d63 100644
> --- a/Documentation/process/maintainer-netdev.rst
> +++ b/Documentation/process/maintainer-netdev.rst
[..]
> @@ -243,11 +243,9 @@ linux-ker...@vger.kernel.org should be used by default 
> for all patches, but the
>  volume on that list has caused a number of developers to tune it out.  Please
>  do not spam unrelated lists and unrelated people, though.
>  
> -Many kernel-related lists are hosted on vger.kernel.org; you can find a
> -list of them at http://vger.kernel.org/vger-lists.html.  There are
> -kernel-related lists hosted elsewhere as well, though.
> -
> -Do not send more than 15 patches at once to the vger mailing lists!!!
> +Many kernel-related lists are hosted at kernel.org; you can find a list
> +of them at https://subspace.kernel.org.  There are kernel-related lists
> +hosted elsewhere as well, though.
>  
>  Linus Torvalds is the final arbiter of all changes accepted into the
>  Linux kernel.  His e-mail address is .
> @@ -866,9 +864,6 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem 
> maintainer".
>  
>
>  
> -NO No more huge patch bombs to linux-ker...@vger.kernel.org people!
> -  
> -
>  Kernel Documentation/process/coding-style.rst
>  
>  Linus Torvalds's mail on the canonical patch format:
> 
> -- 
> 2.45.2
> 
>

Re: [PATCH v6 2/2] proc: restrict /proc/pid/mem

2024-06-18 Thread Jeff Xu 
Hi

Thanks for the patch !

On Thu, Jun 13, 2024 at 6:40 AM Adrian Ratiu  wrote:
>
> Prior to v2.6.39 write access to /proc//mem was restricted,
> after which it got allowed in commit 198214a7ee50 ("proc: enable
> writing to /proc/pid/mem"). Famous last words from that patch:
> "no longer a security hazard". :)
>
> Afterwards exploits started causing drama like [1]. The exploits
> using /proc/*/mem can be rather sophisticated like [2] which
> installed an arbitrary payload from noexec storage into a running
> process then exec'd it, which itself could include an ELF loader
> to run arbitrary code off noexec storage.
>
> One of the well-known problems with /proc/*/mem writes is they
> ignore page permissions via FOLL_FORCE, as opposed to writes via
> process_vm_writev which respect page permissions. These writes can
> also be used to bypass mode bits.
>
> To harden against these types of attacks, distrbutions might want
> to restrict /proc/pid/mem accesses, either entirely or partially,
> for eg. to restrict FOLL_FORCE usage.
>
> Known valid use-cases which still need these accesses are:
>
> * Debuggers which also have ptrace permissions, so they can access
> memory anyway via PTRACE_POKEDATA & co. Some debuggers like GDB
> are designed to write /proc/pid/mem for basic functionality.
>
> * Container supervisors using the seccomp notifier to intercept
> syscalls and rewrite memory of calling processes by passing
> around /proc/pid/mem file descriptors.
>
> There might be more, that's why these params default to disabled.
>
> Regarding other mechanisms which can block these accesses:
>
> * seccomp filters can be used to block mmap/mprotect calls with W|X
> perms, but they often can't block open calls as daemons want to
> read/write their runtime state and seccomp filters cannot check
> file paths, so plain write calls can't be easily blocked.
>
> * Since the mem file is part of the dynamic /proc// space, we
> can't run chmod once at boot to restrict it (and trying to react
> to every process and run chmod doesn't scale, and the kernel no
> longer allows chmod on any of these paths).
>
> * SELinux could be used with a rule to cover all /proc/*/mem files,
> but even then having multiple ways to deny an attack is useful in
> case one layer fails.
>
> Thus we introduce four kernel parameters to restrict /proc/*/mem
> access: open-read, open-write, write and foll_force. All these can
> be independently set to the following values:
>
> all => restrict all access unconditionally.
> ptracer => restrict all access except for ptracer processes.
>
> If left unset, the existing behaviour is preserved, i.e. access
> is governed by basic file permissions.
>
> Examples which can be passed by bootloaders:
>
> proc_mem.restrict_foll_force=all
> proc_mem.restrict_open_write=ptracer
> proc_mem.restrict_open_read=ptracer
> proc_mem.restrict_write=all
>
> These knobs can also be enabled via Kconfig like for eg:
>
> CONFIG_PROC_MEM_RESTRICT_WRITE_PTRACE_DEFAULT=y
> CONFIG_PROC_MEM_RESTRICT_FOLL_FORCE_PTRACE_DEFAULT=y
>
> Each distribution needs to decide what restrictions to apply,
> depending on its use-cases. Embedded systems might want to do
> more, while general-purpouse distros might want a more relaxed
> policy, because for e.g. foll_force=all and write=all both break
> break GDB, so it might be a bit excessive.
>
> Based on an initial patch by Mike Frysinger .
>
It is noteworthy that ChromeOS has benefited from blocking
/proc/pid/mem write since 2017 [1], owing to the patch implemented by
Mike Frysinger.

It is great that upstream can consider this patch, ChromeOS will use
the solution once it is accepted.

> Link: https://lwn.net/Articles/476947/ [1]
> Link: https://issues.chromium.org/issues/40089045 [2]
> Cc: Guenter Roeck 
> Cc: Doug Anderson 
> Cc: Kees Cook 
> Cc: Jann Horn 
> Cc: Andrew Morton 
> Cc: Randy Dunlap 
> Cc: Christian Brauner 
> Cc: Jeff Xu 
> Co-developed-by: Mike Frysinger 
> Signed-off-by: Mike Frysinger 
> Signed-off-by: Adrian Ratiu 

Reviewed-by: Jeff Xu 
Tested-by: Jeff Xu 
[1] 
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/764773

-Jeff Xu


-Jeff