On Tue, Nov 07, 2017 at 11:37:07AM +0100, Roberto Sassu wrote:
> Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters")
> moved the call of ima_file_check() from may_open() to do_filp_open() at a
> point where the file descriptor is already opened.
>
> This breaks the assumption m
On Tue, Nov 07, 2017 at 11:37:01AM +0100, Roberto Sassu wrote:
> from a predefined position (/etc/ima/digest_lists/metadata), when rootfs
> becomes available. Digest lists must be loaded before IMA appraisal is in
> enforcing mode.
I'm sure there's a good reason for it, but this seems weird to me.
Hello,
This series introduces support for the MAX31785 intelligent fan controller, a
PMBus device providing closed-loop fan control among a number of other
features. Along the way the series adds support to control fans and create
virtual pages to the PMBus core, the latter to support some of the
The dual tachometer feature is implemented in hardware with a TACHSEL
input to indicate the rotor under measurement, and exposed on the device
by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need
to read the non-standard four-byte response leads to a cut-down
implementation of i2c
The implementation makes use of the new fan control virtual registers exposed
by the pmbus core. It mixes use of the default implementations with some
overrides via the read/write handlers to handle FAN_COMMAND_1 on the MAX31785,
whose definition breaks the value range into various control bands de
Some circumstances call for virtual pages, to expose multiple values
packed into an extended PMBus register in a manner non-compliant with
the PMBus standard. An example of this is the Maxim MAX31785 controller, which
extends the READ_FAN_SPEED_1 PMBus register from two to four bytes to support
tac
Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.
Fans in a PMBus device are driven by the configuration of two registers,
FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
and the tacho operate (if installed), while FAN_COMMAND_x sets the
desired fan rate. The u
Currently, the cannonlake family of Intel processors support the
branch monitoring feature. Intel's Branch monitoring feature is trying
to utilize heuristics to detect the occurrence of an ROP (Return
Oriented Programming) attack.
A perf-based kernel driver has been used to monitor the occurrence
This patch adds the Documentation/x86/intel_bm.txt file with some
information about Intel Branch monitoring.
Signed-off-by: Megha Dey
---
Documentation/x86/intel_bm.txt | 216 +
1 file changed, 216 insertions(+)
create mode 100644 Documentation/x86/intel_
This patchset adds support for Intel's branch monitoring feature. This
feature uses heuristics to detect the occurrence of an ROP(Return Oriented
Programming) or ROP like(JOP: Jump oriented programming) attack. These
heuristics are based off certain performance monitoring statistics,
measured dynam
Add CPUID of Cannonlake (CNL) processors to Intel family list.
Signed-off-by: Megha Dey
---
arch/x86/include/asm/intel-family.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/intel-family.h
b/arch/x86/include/asm/intel-family.h
index 35a6bc4..056bd41 100644
--- a/arc
On Sat, Nov 18, 2017 at 12:34:33AM +0100, Thomas Gleixner wrote:
> On Fri, 17 Nov 2017, Darren Hart wrote:
>
> @intel: I removed intel-sgx-kernel-...@lists.01.org from CC because I can
> do without the silly moderation spam of that list. Please disable that
> nonsense.
>
> > On Mon, Nov 13, 2017
On Fri, 17 Nov 2017, Darren Hart wrote:
@intel: I removed intel-sgx-kernel-...@lists.01.org from CC because I can
do without the silly moderation spam of that list. Please disable that
nonsense.
> On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote:
> Is SGX considered architectural o
On Thu, 16 Nov 2017 14:23:09 +0100
Greg Kroah-Hartman wrote:
> Sometimes a single patch is the result of multiple authors. As git only
> can have one "author" of a patch, it is still good to properly give
> credit to the other developers of a commit. To address this, document
> the "Co-Develope
On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote:
Please do not submit patches to LKML without a commit message. There is
*always* something you can provide to give the review additional context
to aid in their review of your code.
As Thomas has noted, the various maintainers have
On 11/17/2017 08:53 AM, Stephen Boyd wrote:
> It isn't clear if this function of_node_put()s the 'from'
> argument, or the node it searches. Clearly indicate which
> variable is touched. Fold in some more fixes from Randy too
> because we're in the area.
>
> Cc: Randy Dunlap
> Signed-off-by: Step
It isn't clear if this function of_node_put()s the 'from'
argument, or the node it searches. Clearly indicate which
variable is touched. Fold in some more fixes from Randy too
because we're in the area.
Cc: Randy Dunlap
Signed-off-by: Stephen Boyd
---
Changes from v1:
* Fold in Randy's fixes
On 17 November 2017 at 15:31, Rafael J. Wysocki wrote:
> On Fri, Nov 17, 2017 at 2:49 PM, Ulf Hansson wrote:
>> [...]
>>
>> Second, have you considered setting the default value of
>> dev->power.may_skip_resume to true?
>
> Yes.
>
>> That would means the subsystem
>>>
On Fri, Nov 17, 2017 at 2:49 PM, Ulf Hansson wrote:
> [...]
>
>>>
> Second, have you considered setting the default value of
> dev->power.may_skip_resume to true?
Yes.
> That would means the subsystem
> instead need to implement an opt-out method. I am thinking that
On Thu, Nov 16, 2017 at 8:44 PM, Stephen Boyd wrote:
> On 11/10, Randy Dunlap wrote:
>> On 11/10/2017 05:45 PM, Stephen Boyd wrote:
>> > It isn't clear if this function of_node_put()s the 'from'
>> > argument, or the node it finds in the search. Clearly indicate
>> > which variable is touched.
>>
[...]
>>
Second, have you considered setting the default value of
dev->power.may_skip_resume to true?
>>>
>>> Yes.
>>>
That would means the subsystem
instead need to implement an opt-out method. I am thinking that it may
not be an issue, since we anyway at this point, don'
On Fri, Nov 17, 2017 at 7:11 AM, Ulf Hansson wrote:
> [...]
>
>>> > +++ linux-pm/include/linux/pm.h
>>> > @@ -559,6 +559,7 @@ struct pm_subsys_data {
>>> > * NEVER_SKIP: Do not skip system suspend/resume callbacks for the
>>> > device.
>>> > * SMART_PREPARE: Check the return value of the driv
On Fri, Nov 17, 2017 at 12:07 AM, Rafael J. Wysocki wrote:
> On Thursday, November 16, 2017 4:10:16 PM CET Ulf Hansson wrote:
>> On 12 November 2017 at 01:37, Rafael J. Wysocki wrote:
>> > From: Rafael J. Wysocki
>> >
>> > Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
>> >
On 2017-11-17 19:36, Thomas Gleixner wrote:
On Fri, 17 Nov 2017, Quan Xu wrote:
On 2017-11-16 17:53, Thomas Gleixner wrote:
That's just plain wrong. We don't want to see any of this PARAVIRT crap in
anything outside the architecture/hypervisor interfacing code which really
needs it.
The prob
On Fri, 2017-11-17 at 09:55 +0100, Roberto Sassu wrote:
> On 11/17/2017 2:08 AM, Kees Cook wrote:
> > On Tue, Nov 7, 2017 at 8:45 AM, Roberto Sassu
> > wrote:
> >> On 11/7/2017 2:37 PM, Mimi Zohar wrote:
> >>> Normally, the protection of kernel memory is out of scope for IMA.
> >>> This patch set
On Fri, 17 Nov 2017, Quan Xu wrote:
> On 2017-11-16 17:53, Thomas Gleixner wrote:
> > That's just plain wrong. We don't want to see any of this PARAVIRT crap in
> > anything outside the architecture/hypervisor interfacing code which really
> > needs it.
> >
> > The problem can and must be solved a
On 2017-11-16 17:53, Thomas Gleixner wrote:
On Thu, 16 Nov 2017, Quan Xu wrote:
On 2017-11-16 06:03, Thomas Gleixner wrote:
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -210,6 +210,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
On Thu, Nov 16, 2017 at 02:23:09PM +0100, Greg Kroah-Hartman wrote:
> Sometimes a single patch is the result of multiple authors. As git only
> can have one "author" of a patch, it is still good to properly give
> credit to the other developers of a commit. To address this, document
> the "Co-Dev
On Thu, 16 Nov 2017, Greg Kroah-Hartman wrote:
> Sometimes a single patch is the result of multiple authors. As git only
> can have one "author" of a patch, it is still good to properly give
> credit to the other developers of a commit. To address this, document
> the "Co-Developed-by:" tag whic
I realize the Cc: list for the cover letter probably should have included all
the relevant maintainers for this set, sorry about that!
For convenience I also put up a more reader friendly copy of the doc after
patch 7 here:
http://heim.ifi.uio.no/~knuto/kernel/4.14/dev-tools/run-checkpatch.html
On 11/17/2017 2:08 AM, Kees Cook wrote:
On Tue, Nov 7, 2017 at 8:45 AM, Roberto Sassu wrote:
On 11/7/2017 2:37 PM, Mimi Zohar wrote:
Normally, the protection of kernel memory is out of scope for IMA.
This patch set introduces an in kernel white list, which would be a
prime target for attackers
Hi Kees,
Thank you for the proof reading. I will fix the typos/language, but
see the comments on bigger things inside.
> On Tue, Nov 14, 2017 at 11:55 PM, Elena Reshetova
> wrote:
> > Some functions from refcount_t API provide different
> > memory ordering guarantees that their atomic counterp
32 matches
Mail list logo
