On Wed, Aug 14, 2019 at 09:17:41PM +, Lendacky, Thomas wrote:
> From: Tom Lendacky
>
> There have been reports of RDRAND issues after resuming from suspend on
> some AMD family 15h and family 16h systems. This issue stems from BIOS
> not performing the proper steps during resume to ensure RDR
On Wed, Aug 14, 2019 at 07:17:07PM +0200, Knut Omang wrote:
> I notice the discussion and your response here:
> http://linux-kernel.2935.n7.nabble.com/debugfs-and-module-unloading-td865175.html
> I assume that means that protection against module unload while a debugfs file
> is open is now safe.
On Thu, 2019-08-15 at 10:49 +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 14, 2019 at 07:17:07PM +0200, Knut Omang wrote:
> > I notice the discussion and your response here:
> > http://linux-kernel.2935.n7.nabble.com/debugfs-and-module-unloading-td865175.html
> > I assume that means that protecti
On Thu, Aug 15, 2019 at 12:35:26PM +0200, Knut Omang wrote:
> On Thu, 2019-08-15 at 10:49 +0200, Greg Kroah-Hartman wrote:
> > > I perfectly agree with you that reducing the hole for a race condition
> > > is generally a bad idea, but from the above mail thread
> > > it seems that's the only avai
On 8/14/19 6:24 PM, Pavel Machek wrote:
> On Wed 2019-08-14 21:17:41, Lendacky, Thomas wrote:
>> From: Tom Lendacky
>>
>> There have been reports of RDRAND issues after resuming from suspend on
>> some AMD family 15h and family 16h systems. This issue stems from BIOS
>> not performing the proper s
On 8/15/19 2:21 AM, Borislav Petkov wrote:
> On Wed, Aug 14, 2019 at 09:17:41PM +, Lendacky, Thomas wrote:
>> From: Tom Lendacky
>>
>> There have been reports of RDRAND issues after resuming from suspend on
>> some AMD family 15h and family 16h systems. This issue stems from BIOS
>> not perfor
list_for_each_entry_rcu now has support to check for RCU reader sections
as well as lock. Just use the support in it, instead of explicitly
checking in the caller.
Acked-by: Tejun Heo
Signed-off-by: Joel Fernandes (Google)
---
v1->v3: Changed lock_is_held() to lockdep_is_held()
kernel/workqueu
On Thu, Aug 15, 2019 at 10:18:42AM -0400, Joel Fernandes (Google) wrote:
> list_for_each_entry_rcu now has support to check for RCU reader sections
> as well as lock. Just use the support in it, instead of explicitly
> checking in the caller.
...
> #define assert_rcu_or_wq_mutex_or_pool_mutex(wq
On Thu, Aug 15, 2019 at 01:24:35AM +0200, Pavel Machek wrote:
> Burn it with fire!
>
> I mean... people were afraid RDRAND would be backdoored, and you now
> confirm ... it indeed _is_ backdoored? /., here's news for you!
To be fair to AMD, I wouldn't call it a backdoor. Hanlon's razor is
applic
On Thu, Aug 15, 2019 at 07:57:49AM -0700, Matthew Wilcox wrote:
> On Thu, Aug 15, 2019 at 10:18:42AM -0400, Joel Fernandes (Google) wrote:
> > list_for_each_entry_rcu now has support to check for RCU reader sections
> > as well as lock. Just use the support in it, instead of explicitly
> > checking
On Thu, Aug 15, 2019 at 01:47:24PM +, Lendacky, Thomas wrote:
> Sure, I can do that. Do we want to tie this into the nordrand option and
> add rdrand=off or keep that separate?
Yeah, I was looking at that this morning and I'd say keep 'em separate
because if you have to tie, you need to export
Hi,
This series contains an update to the arm64 tagged address ABI
documentation posted here (v7):
http://lkml.kernel.org/r/20190807155321.9648-1-catalin.mari...@arm.com
together some adjustments to Andrey's patches (already queued through
different trees) following the discussions on the ABI do
There isn't a good reason to differentiate between the user address
space layout modification syscalls and the other memory
permission/attributes ones (e.g. mprotect, madvise) w.r.t. the tagged
address ABI. Untag the user addresses on entry to these functions.
Signed-off-by: Catalin Marinas
---
First rename the sysctl control to abi.tagged_addr_disabled and make it
default off (zero). When abi.tagged_addr_disabled == 1, only block the
enabling of the TBI ABI via prctl(PR_SET_TAGGED_ADDR_CTRL,
PR_TAGGED_ADDR_ENABLE).
Getting the status of the ABI or disabling it is still allowed.
Signed-
From: Vincenzo Frascino
On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
(EL0) to perform memory accesses through 64-bit pointers with a non-zero
top byte. However, such pointers were not allowed at the user-kernel
syscall ABI boundary.
With the Tagged Address ABI patchset,
From: Vincenzo Frascino
On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
(EL0) to perform memory accesses through 64-bit pointers with a non-zero
top byte. Introduce the document describing the relaxation of the
syscall ABI that allows userspace to pass certain tagged pointer
Require that arg{3,4,5} of the PR_{SET,GET}_TAGGED_ADDR_CTRL prctl and
arg2 of the PR_GET_TAGGED_ADDR_CTRL prctl() are zero rather than ignored
for future extensions.
Signed-off-by: Catalin Marinas
---
kernel/sys.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sys.c b/kernel/sys
On 15/08/2019 16:44, Catalin Marinas wrote:
From: Vincenzo Frascino
On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
(EL0) to perform memory accesses through 64-bit pointers with a non-zero
top byte. Introduce the document describing the relaxation of the
syscall ABI that a
mm_vmscan_{direct_reclaim_begin,wakeup_kswapd,lru_isolate,lru_shrink_active}
changed their output to the point where the script throws warnings and
errors. Update it to be properly in line with those changes.
Signed-off-by: Florian Schmidt
---
.../postprocess/trace-vmscan-postprocess.pl | 23 +
This patch series updates trace-vmscan-postprocess.pl to work without
throwing warnings and errors which stem from updates to several trace
points.
3481c37ffa1d ("mm/vmscan: drop may_writepage and classzone_idx from
direct reclaim begin template") removed "may_writepage" from
mm_vmscan_direct_recl
Fix spacing so that both the headers in themselves, as well as the
output of the two tables related to each other, are properly aligned.
Signed-off-by: Florian Schmidt
---
Documentation/trace/postprocess/trace-vmscan-postprocess.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
dif
On 8/13/19, 1:36 AM, "openbmc on behalf of John Wang"
wrote:
Add the driver to monitor Inspur Power System power supplies
with hwmon over pmbus.
This driver adds sysfs attributes for additional power supply data,
including vendor, model, part_number, serial number,
fi
On Thu, Aug 15, 2019 at 06:43:52PM +, Vijay Khemka wrote:
>
>
> On 8/13/19, 1:36 AM, "openbmc on behalf of John Wang"
> wangz...@inspur.com> wrote:
>
> Add the driver to monitor Inspur Power System power supplies
> with hwmon over pmbus.
>
> This driver adds sysfs attribu
On Thu, 15 Aug 2019, Borislav Petkov wrote:
> On Thu, Aug 15, 2019 at 01:47:24PM +, Lendacky, Thomas wrote:
> > I think this is a clearer indication that the action has taken place.
>
> Yeah, but what does that bring us? You wanna know this now, while
> testing. Once that whole effort is done,
On 14/08/2019 22:17, Lendacky, Thomas wrote:
> +static void init_hide_rdrand(struct cpuinfo_x86 *c)
> +{
> + /*
> + * The nordrand option can clear X86_FEATURE_RDRAND, so check for
> + * RDRAND support using the CPUID function directly.
> + */
> + if (!(cpuid_ecx(1) & BIT(30)
On Thu, 15 Aug 2019, Andrew Cooper wrote:
> On 14/08/2019 22:17, Lendacky, Thomas wrote:
> > +static void init_hide_rdrand(struct cpuinfo_x86 *c)
> > +{
> > + /*
> > +* The nordrand option can clear X86_FEATURE_RDRAND, so check for
> > +* RDRAND support using the CPUID function directly.
On Mon, Aug 05, 2019 at 05:12:44PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Aug 04, 2019 at 02:17:00AM +0200, Jiri Kosina wrote:
> > On Thu, 25 Jul 2019, Greg Kroah-Hartman wrote:
> >
> > > To address the requirements of embargoed hardware issues, like Meltdown,
> > > Spectre, L1TF, etc. it is n
On Thu, Aug 15, 2019 at 09:59:03PM +0100, Andrew Cooper wrote:
> If you're virtualised, the write to MSR_AMD64_CPUID_FN_1 almost
> certainly won't take effect, which means userspace will still be able to
> see the bit.
msr_clear_bit() has a return value. We should check it before
doing anything fu
On Thu, Jul 25, 2019 at 03:13:02PM -0600, Jonathan Corbet wrote:
> On Thu, 25 Jul 2019 15:01:13 +0200
> Greg Kroah-Hartman wrote:
>
> > From: Thomas Gleixner
> >
> > To address the requirements of embargoed hardware issues, like Meltdown,
> > Spectre, L1TF, etc. it is necessary to define and do
On 15/08/2019 22:05, Borislav Petkov wrote:
> On Thu, Aug 15, 2019 at 09:59:03PM +0100, Andrew Cooper wrote:
>> If you're virtualised, the write to MSR_AMD64_CPUID_FN_1 almost
>> certainly won't take effect, which means userspace will still be able to
>> see the bit.
> msr_clear_bit() has a return
From: Thomas Gleixner
To address the requirements of embargoed hardware issues, like Meltdown,
Spectre, L1TF etc. it is necessary to define and document a process for
handling embargoed hardware security issues.
Following the discussion at the maintainer summit 2018 in Edinburgh
(https://lwn.net
On 8/15/19 2:20 PM, Greg Kroah-Hartman wrote:
>>> +The hardware security team will provide a per incident specific encrypted
>> s/per incident specific/incident-specific/
> Fixed. And changed /a/ to /an/
eh? still should be /a per incident/
--
~Randy
On 8/15/19 2:25 PM, Greg Kroah-Hartman wrote:
> v2: updated list of people with document from Jiri as I had the old one
> grammer tweaks based on Jon's review
> moved document to Documentation/process/
If you get to do a v3, you can change the $Subject also.
--
~Randy
On Thu, Aug 15, 2019 at 03:12:34PM -0700, Randy Dunlap wrote:
> On 8/15/19 2:20 PM, Greg Kroah-Hartman wrote:
> >>> +The hardware security team will provide a per incident specific encrypted
> >> s/per incident specific/incident-specific/
> > Fixed. And changed /a/ to /an/
>
> eh? still should b
On Thu, Aug 15, 2019 at 03:15:11PM -0700, Randy Dunlap wrote:
> On 8/15/19 2:25 PM, Greg Kroah-Hartman wrote:
> > v2: updated list of people with document from Jiri as I had the old one
> > grammer tweaks based on Jon's review
> > moved document to Documentation/process/
>
> If you get to
On 8/15/19 3:31 PM, Greg Kroah-Hartman wrote:
> On Thu, Aug 15, 2019 at 03:12:34PM -0700, Randy Dunlap wrote:
>> On 8/15/19 2:20 PM, Greg Kroah-Hartman wrote:
> +The hardware security team will provide a per incident specific encrypted
s/per incident specific/incident-specific/
>>> Fixed.
On Wed, Aug 7, 2019 at 7:06 PM Frank Rowand wrote:
>
> On 7/23/19 5:10 PM, Saravana Kannan wrote:
> > Add device-links after the devices are created (but before they are
> > probed) by looking at common DT bindings like clocks and
> > interconnects.
> >
> > Automatically adding device-links for fu
On Fri, Aug 16, 2019 at 3:41 AM Guenter Roeck wrote:
>
> On Thu, Aug 15, 2019 at 06:43:52PM +, Vijay Khemka wrote:
> >
> >
> > On 8/13/19, 1:36 AM, "openbmc on behalf of John Wang"
> > > wangz...@inspur.com> wrote:
> >
> > Add the driver to monitor Inspur Power System power supplies
> >
On 8/15/19 7:44 PM, John Wang wrote:
On Fri, Aug 16, 2019 at 3:41 AM Guenter Roeck wrote:
On Thu, Aug 15, 2019 at 06:43:52PM +, Vijay Khemka wrote:
On 8/13/19, 1:36 AM, "openbmc on behalf of John Wang"
wrote:
Add the driver to monitor Inspur Power System power supplies
wi
39 matches
Mail list logo
